> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!)
Why is Rust too complicated to allow you to do low-level hacking?
Why is Rust too complicated to allow you to do low-level hacking?
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.
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).
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.
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 , and my first task after I finish breakfast is to clean up 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.
Different linking options are found here: 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)
I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.
...
And can I get in on some of that? ;-)
Just a very concurrent browser engine ;) One that does everything in parallel. Basically every task that can be parallelized becomes parallel (rendering, JS execution, CSS matcher, etc.).
Also you can, there is Github for Servo (said parallel browser engine project by Mozilla).
- https://github.com/rust-lang/rust/
- https://github.com/mozilla/servo/
(The 'contributors' graphs suggest that pcwalton has added/removed more than 1 million lines of code in those two repos combined.)