3 ms·

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there

by axaxs 12y ago

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I know Rust isn't 'released' yet. But if you are defending it, I feel like it should be at a very learnable state. Do you have plans for a 'tour', for a play by play like Go offers that can bring others up to speed? Further(and this is really reaching while I got you)... my favorite part is cross compilation and being able to deploy a single binary anywhere. I tried to compile something in rustc once, but when I moved it to an older box, it failed to run. Will rust offer such stable static compilation in the future?

coldtea 12y ago
>Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. It's 2014 already. Angle brackets, arrows, and pattern matching are 1990 level language technology. Heck, even a dynamic front-end language like Coffescript has these kind of things nowadays.
- axaxs 12y ago
  I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...
  - coldtea 12y ago
    While some of it can come to taste, I think having higher abstractions (as long as they don't leak) is beneficial to reading/using a language. Like, objectively. And foreach vs for is not a leaky abstraction. Nor is pattern matching vs traditional checking and extracting the values. So their value is not geting lost on having corner cases that the equivalent "based on primitives" code wouldn't have. If anything they make the operation even more explicit. So I think a lot of it comes down to getting familiar with them. While something made of "first principles" might be more instantly familiar, it will be harder to reason about because of its low-level ness as the code size increases. Case in point, assembly. It's quite primitive language with very few constructs, so it's easy to learn to use. But an actual high level "if" or function call is much easier to grasp at once than checking 10-20 lines that implement the same thing in assembly (even if you have trained yourself to see the assembly "pattern" for a function call, etc).
    - coldtea 12y ago
      To expand on this: isn't what Go does with built-in channel and parallelism primitives similar to that? They sure didn't exist in C. But people see the value of having this higher level abstractions. So, why draw the line on Channels and Goroutines, and not add pattern matching in there? Just because Go already came out offering the former? If anything, pattern matching is even more applicable to the work we do day-to-day, than channels and goroutines are. Millions of people write programs without parallelism/concurrency every day, but nobody writes programs without pattern matching. They just do it by hand with lots of if/else and various manual extraction techniques, if their language doesn't offer it.
steveklabnik 12y ago
> the docs aren't the best. This week is week two of my being contracted by Mozilla to write docs full time. First up, a new tutorial. You can see my work from last week http://doc.rust-lang.org/guide.html http://doc.rust-lang.org/guide.html , and my first task after I finish breakfast is to clean up https://github.com/rust-lang/rust/pull/15229 https://github.com/rust-lang/rust/pull/15229 , which got some review over the weekend. So, you're right (at least about the docs) but I'm on it.
- axaxs 12y ago
  Steve - thanks for your reply and work on the docs. Is there currently a place - or will there be one, that describes precisely build/deployment options? This really in the end is the most important thing to me. I've searched unsuccessfully for this wrt Rust. It seems that as it sits, items built on a newer machine won't run on an older machine due to libc library mismatches. Will this always be a potential issue? Or will I be able to generate a single binary a la go?
  - steveklabnik 12y ago
    Well, first of all, I'd point to you http://arewewebyet.com/ http://arewewebyet.com/ ;) Different linking options are found here: http://static.rust-lang.org/doc/master/rust.html#linkage http://static.rust-lang.org/doc/master/rust.html#linkage Basically, as of right now, when you link statically, Rust will not build in glibc (and jemalloc, IIRC). So, you'll need to make sure that your glibc versions line up. My understanding is that glibc isn't able to be statically linked in without breaking things. You can use `objdump -T` to see these dependencies. On my system, compiling 'Hello world,' I get symbols for glibc and gcc. (Go gets away with this by reimplementing the world, rather than relying on glibc. The benefit is a wholly-contained binary, as you've seen. The downside is compatibility bugs, like https://code.google.com/p/go/issues/detail?id=1435 https://code.google.com/p/go/issues/detail?id=1435)

by axaxs 12y ago

coldtea 12y ago

>Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. It's 2014 already. Angle brackets, arrows, and pattern matching are 1990 level language technology. Heck, even a dynamic front-end language like Coffescript has these kind of things nowadays.

axaxs 12y ago
I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...
- coldtea 12y ago
  While some of it can come to taste, I think having higher abstractions (as long as they don't leak) is beneficial to reading/using a language. Like, objectively. And foreach vs for is not a leaky abstraction. Nor is pattern matching vs traditional checking and extracting the values. So their value is not geting lost on having corner cases that the equivalent "based on primitives" code wouldn't have. If anything they make the operation even more explicit. So I think a lot of it comes down to getting familiar with them. While something made of "first principles" might be more instantly familiar, it will be harder to reason about because of its low-level ness as the code size increases. Case in point, assembly. It's quite primitive language with very few constructs, so it's easy to learn to use. But an actual high level "if" or function call is much easier to grasp at once than checking 10-20 lines that implement the same thing in assembly (even if you have trained yourself to see the assembly "pattern" for a function call, etc).
  - coldtea 12y ago
    To expand on this: isn't what Go does with built-in channel and parallelism primitives similar to that? They sure didn't exist in C. But people see the value of having this higher level abstractions. So, why draw the line on Channels and Goroutines, and not add pattern matching in there? Just because Go already came out offering the former? If anything, pattern matching is even more applicable to the work we do day-to-day, than channels and goroutines are. Millions of people write programs without parallelism/concurrency every day, but nobody writes programs without pattern matching. They just do it by hand with lots of if/else and various manual extraction techniques, if their language doesn't offer it.

steveklabnik 12y ago

> the docs aren't the best. This week is week two of my being contracted by Mozilla to write docs full time. First up, a new tutorial. You can see my work from last week http://doc.rust-lang.org/guide.html http://doc.rust-lang.org/guide.html , and my first task after I finish breakfast is to clean up https://github.com/rust-lang/rust/pull/15229 https://github.com/rust-lang/rust/pull/15229 , which got some review over the weekend. So, you're right (at least about the docs) but I'm on it.

axaxs 12y ago
Steve - thanks for your reply and work on the docs. Is there currently a place - or will there be one, that describes precisely build/deployment options? This really in the end is the most important thing to me. I've searched unsuccessfully for this wrt Rust. It seems that as it sits, items built on a newer machine won't run on an older machine due to libc library mismatches. Will this always be a potential issue? Or will I be able to generate a single binary a la go?
- steveklabnik 12y ago
  Well, first of all, I'd point to you http://arewewebyet.com/ http://arewewebyet.com/ ;) Different linking options are found here: http://static.rust-lang.org/doc/master/rust.html#linkage http://static.rust-lang.org/doc/master/rust.html#linkage Basically, as of right now, when you link statically, Rust will not build in glibc (and jemalloc, IIRC). So, you'll need to make sure that your glibc versions line up. My understanding is that glibc isn't able to be statically linked in without breaking things. You can use `objdump -T` to see these dependencies. On my system, compiling 'Hello world,' I get symbols for glibc and gcc. (Go gets away with this by reimplementing the world, rather than relying on glibc. The benefit is a wholly-contained binary, as you've seen. The downside is compatibility bugs, like https://code.google.com/p/go/issues/detail?id=1435 https://code.google.com/p/go/issues/detail?id=1435)