This Week in Rust – Static linking, Win64
cmr.github.io
cmr.github.io
For me it's interesting partly because I hope to get a language where managed memory is non-idiomatic and largely unnecessary while manual memory management is quite safe, i.e. no GC needed.
This combined with what I've seen so far with regards to other language design choices makes me hope for something that can also approach C/C++ speeds together with broad portability - uc's (where a GC obviously is a no-no) to big iron nixes to OSX/Win to Android/iOS.
Also, skipping things like GC I hope to be able to write drop-in replacements for C-libraries in Rust, with the application using the library being none the wiser.
These are just a few reasons. If I am wrong to harbour any of these hopes, please correct me. Basically, I hope for good performance, portability and productivity. If I stalked the Rust github page any more often, they'd probably block my IP for DOSing...
EDIT: Forgot to mention that I also hope for a large and supportive community - something I think we can already see the beginning of. People in #rust are very friendly and interesting 3rd party libraries are being produced as we speak despite the language and stdlib still being in a bit of flux. Community is so important. Also, Mozilla backing it is a big plus for me.
Go and Rust offer GC. Rust allows you to choose when you use it. Rust also makes it explicit when you're allocating memory whatsoever.
Go and Rust offer M:N threading. Rust provides separate heaps per "task" and a data ownership system which means you never end up sharing state between "tasks" (ala Erlang). Go only provides a global shared heap. This means Rust can prevent a class of bugs (concurrent mutation of shared state) which Go can't. It also means Rust's GC is easier to run in parallel, since state is isolated to particular tasks so you can GC a task while it's idle ignorant of the rest of what's going on in the system.
Go and Rust both offer structural typing (like duck typing with static typechecking). Rust also implements Hindley-Milner, which is the same type inference algorithm used in Haskell. So Rust provides Go-like typing when you want it, and a "real" type system when you need it.
Rust is immutable by default. I think the benefits of immutable state go without saying, but Rust also lets you opt into mutable state if you want it.
Rust is memory-safe by default, meaning that mistakes made by programmers won't corrupt memory or cause the program to crash. However, Rust also offers an unsafe mode that provides C-like memory access, making Rust suitable for things like kernel development, bootloaders, microcontrollers, and other device firmware that still needs to do C-like things in order to function.
Rust can be used for "bare metal" low-level development, to the point that you can boot directly to Rust without ever starting its runtime, and even use Rust directly on microcontrollers. See "Rust on bare metal" (lolpun): https://mail.mozilla.org/pipermail/rust-dev/2013-July/004841...
Finally, Rust provides a task linking/fault-tolerance model similar to Erlang where if one task exits, tasks it's linked to are automatically notified about an exit event and can take action accordingly.
Rust is a weird platypus of a language with a lot of the features you see in fancy functional languages but working in more or less the same realm as C/C++. I've heard it described as "if C++, ML, and Erlang had a kid"
Rust is talking about getting read of N:M threading and returning to 1:1, I'm not 100% sure that's landed or was fully decided yet.
That said, this is a great description.
And getting rid of N:M threading and returning to 1:1 seems rather unlikely to happen. More likely is simply work to ensure that Rust can run well under both N:M and 1:1 threading models.
@ is being removed, but GC will still be there - implemented properly as a library with language hooks (via traits) to make it nice and safe to work with. You will be able to create your own memory management strategies using those traits.
fn main() {
// we can't introduce synchronization for this example, so print repeatedly on the main task and check the output for ordering
do spawn {
fail!("child task failure");
}
for i in range(0u, 50) {
println!("print line {}", i);
}
}
If you want to reintroduce linked task failure with current master, you can do so explicitly using `std::task::TaskBuilder.future_result()`. It's a bit awkward though. And you can probably do better than what I have here, it's just a quick sample:
fn main() {
let mut builder = std::task::task();
let future = builder.future_result();
do builder.spawn() {
fail!("child task failure");
}
// check for failure before each of our prints
for i in range(0u, 50) {
if future.peek() && future.recv().is_err() {
fail!("parent task failing because of child failure");
}
println!("print line {}", i);
}
// and block on the result in the end
if future.try_recv().map_default(false, |r| r.is_err()) {
fail!("parent task failing because of child failure");
}
}EDIT: Gack, ignore this. Missed that another reply hit the 1:1 threading point. (only read the bit where they were talking about the @-pointer going away)
Nitpick: This isn't actually true. Rather Rust ensures at compile time that if you share memory you can't race on it (either you share only immutable data, or you take a lock whenever you mutate). This is one of the things that makes Rust unique among industry languages: you get shared memory and data race freedom.
It also seems to have a good mix of other features that I like, which others have already listed.
Basically, rust has the potential be an actual C++ replacement; a real one that actually gives you control over memory.
A language that starts over, with the same or similar semantics, and cleans up everything else, seems like a great idea. Hopefully they resist the temptation to throw in too much unproven but cool-sounding experimental stuff. (Maybe it's just me, but a couple of years ago, it seemed every new language had to throw in STM willy-nilly...)