Slashdot Mirror
Rust Programming Language Reaches 1.0 Alpha
c0d3g33k writes: Rust, a new a systems programming language with a focus on safety, performance and concurrency, has released the 1.0 alpha version of the language. This means that the language and core libraries are feature-complete for the 1.0 release. In practical terms, this means that the rate of change experienced by early adopters will slow down dramatically and major breaking changes should be very rare (during the alpha cycle some major changes may still occur if considered necessary). The language will stabilize further when the beta stage is reached (planned for six weeks from now).
Everyone uses "golang" due to this. It works fine.
Maw! Fire up the karma burner!
A safety systems programming language sounds great but they had to ruin it by putting a garbage collector in it. This makes it useless for systems programming.
No they didn't: http://doc.rust-lang.org/compl...
It'd be "just type io::stdin().read_line()" only if you don't care about error handling, and not caring about error handling is pretty much the opposite of their design goals.
Actual analog of that expression wouldn't be "io::stdin().read_line()", it'd be more like
try {
input = io::stdin.read_line();
} catch(exception &e) {
cerr<<"Failed to read line";
terminate();
}
In C it would be even uglier, with manual checking of error codes and all.
http://zinc.rs/
Mada mada dane.
> Overall to me the language looks primarily based on C++, an attempt to smooth out the rough spots of C++,
It's like C++, but where segfaults are impossible. In C++ (and C) you might try to return a pointer to a stack-allocated object:
X * foo() {
X x;
return
}
Any decent compiler will warn you that this is buggy. But that's only because it's a blatant bug. It's possible to write much more subtle bugs, which lead to the same problems, but which modern C and C++ compilers will miss. As well as accessing stack variables after their valid lifetime, you might free some heap memory twice, or not at all, and so on.
(Disclaimer: I have essentially no real experience with Rust, but have followed it's development a little.)
Rust will not allow you to compile the program until it can prove that your program is safe, that you are not abusing the lifetime of anything. This allows us to have performance and safety without compromising on either. The language also limits at most one variable at a time to have write access to a given object, this is good for concurrency also (well, even single threaded code would benefit from this). Basically, you just write C++-style code, but instead of having to convince a code review commitee of the safety of your code, you can just say "the compiler accepted it, therefore certain safety guarantees can now be assumed".
For example,
Circle * foo() {
Circle c1(5);
Circle c2(10);
return biggestCircle(&c1,&c2);
}
We know that would be invalid, but a C++ compiler wouldn't see any problem. The Rust compiler, on the other hand, can see that the lifetime of the return object of biggestCircle can be no longer than the lifetime of either parameter.
I am gradually becoming incredibly excited about this feature. But it's going to be interesting watching the future of the language. This kind of feature isn't appreciated unless you're an experienced C++ developer. So we might find that lots of important software, from rocket ship code to web browser code, is written in Rust in future but we might find that most people don't understand why! It will be kind of like C++ for many people, they dismiss it when they are new to software, but ultimately everyone goes to C++ (or, in future, Rust) instead! :-)
[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]