Today, we’re excited to release the alpha version of Rust 1.0, a systems programming language with a focus on safety, performance and concurrency.
This release marks a huge milestone for Rust and its community.
It’s feature-complete now (hence the 1.0).
But not yet API-frozen.
In fact, the I/O and path-manipulation modules are unstable-gated in non-nightly builds at the moment, pending a big pre-1.0-final rewrite.
It’s an incredibly well-designed language that competes with Go. Same performance, same feature set, similar goals (systems programming), but vastly different syntax details. Once the tooling is in place, Rust could go somewhere (a programming language without a really great IDE is just sad.)
Go is not a systems programming language, whatever its advocates might say: no easy direct memory access, only GC, etc; Rust is. The feature set is also anything but the same: Go doesn’t have pattern matching, safe/unsafe code blocks, operator overloading or a proper type system (again, etc). People seem to think they are alike because both are new languages and both are compiled, but that is about it.
Yes, Go is a systems programming language (http://en.wikipedia.org/wiki/System_programming_language) and most people agree it is.
Other than that: Can’t believe how badly you missed the point.
Ain’t it that one of the founders of Go publicly admitted that it was a mistake to call Go a systems programming language in the first place?
No
I’m suspicious of any language with a runtime library that claims to be a systems language. I note with interest that the Wikipedia page provides examples; Go has been used for “Minor Google systems” and Rust for “Servo layout engine”, neither of which are systems tasks.
They explicitly state that the runtime is not strictly required and that rust is also suitable for kernel-level code:
http://doc.rust-lang.org/0.12.0/guide-runtime.html
You mean, like C?
Well count me as one of the other group I guess… Go is an awesome language, I think its great, honestly I do. But I simply don’t see how anyone can claim it is a “system programming language” without slapping some serious asterisks on that statement. I know Google calls it one, but that doesn’t cut it for me…
It uses a GC. There is no option to not use a GC. The language simply doesn’t work without a GC…
To me, that simply disqualifies it for quite a number of things people consider “systems programming”. I’m not saying you can’t use it for some things, maybe its even great for most things, but certainly not all things.
Rust, on the other hand (straight out of their docs):
I could not have said it better myself. Rust (hopefully) will grow up into a legitimate C/C++ alternative – usable in any scenario where those languages are commonly employed. Go simply is never going to do that – it can’t do that…
btw, this is coming from someone who honestly prefers Go to Rust, having toyed with both. But I’m not a systems programmer…
Why is garbage collection a disqualifier for systems programming?
Embedded and Realtime… Embedded because of memory constraints (see disclaimer below) and realtime because of non-deterministic behavior. Go has an excellent GC, its very fast and introduces minimal performance overhead. But it is still not deterministic. There is such a thing as a fully deterministic GC, but Go doesn’t have one (at least not at this time).
Now you may argue that embedded and realtime are not really “systems programming”. I think those two disciplines are subsets of system programming, but whatever – the argument isn’t about nomenclature…
C/C++ are both commonly (almost universally) used for both embedded and realtime. If you want to say your creating a language to replace them, it has to be able to do the same things they can do. Rust can (at least it is intended to), Go can’t.
Disclaimer:
I readily admit that many modern platforms that we consider “embedded” have more than enough memory to afford a full GC, and in those cases the tradeoff is probably fine. But then again there are others (small 8-bit MCs) that might only have 2KB to work with – on those kinds of systems you not only don’t want a GC, you probably don’t even want heap memory at all – your going to do pretty much everything on the stack (i.e. no dynamic allocations at all).
Go is simply not designed to allow this. Rust, on the other hand, was designed to do this from the get go. No, you can’t use a GC in Rust when doing this, and you have to actually disable certain heap specific features of the language when doing this, but it was designed to allow it.
Again, I am not criticizing Go itself, I think it is great for tons of stuff. But I do criticize them calling it a “Systems Programming” language – because it makes people automatically think “C/C++ replacement”. Sometimes it may be a suitable replacement, but certainly not universally.
I see, thanks for the reply and it makes sense of where you were coming from.
I was simply asking, because I have dealt with many people who seem to think that “systems programming” is equivalent to kernel/OS programming. Which is not necessarily the case.
I don’t see it as direct Go’s competitor. Same as for example C++ doesn’t directly compete with Java.
Meaning that there are clear use cases where neither Go nor Java are really good choices unlike Rust or C++.
Rust, the programming language for people who think C++ is a bit too clear, verbose and easy to follow — mixed with appeal for the Twitter generation that’s too lazy to type anything — The IOCCC is gonna LOVE this one.
Of course, if it’s “feature complete” why is it an ALPHA? doesn’t that mean “Beta”? :/
Of course with most developers calling their BETA a “final” release this surprises who exactly?
Laundry list of everything WRONG with developers today — but what can one expect from the types of dipshits who think 1.3k of plaintext needs to be pissed all over with bootcrap and scripttardery… Am I really supposed to trust a programming language built by people too stupid to even use HTML and CSS properly?
You must have had a bad day, sorry. I’m not trying to convince you to change your opinion on Rust, but I think I should comment on the points you’ve made.
Modern C++ clearly has it’s advantages and is quite an improvement over the early days. Fair enough. The motivation behind Rust hasn’t been that C++ is hard to read. It’s that C++ allows the developers to do all kinds of crazy stuff from good old C that leads to serious security flaws. Rusts goal is to generally prevent you from many types of errors a developer could make while still offering good performance and the features a systems programming language needs.
On top of that it offers unique and modern approaches in the area of programming languages in general.
I’m not quite sure what you mean, but Rust is far from a minimal language. It has many language constructs and is quite verbose with the goal of correctness and memory safety.
“Feature complete” regarding language expressiveness. Most importantly, several APIs aren’t finished and there may be some renaming going on. Thus, calling it alpha is right imho.
That’s not a fair description of the people involved in Rust. There are many experts involved, with decades of programming in different languages. Well, also Mozilla has a sophisticated JS engine and they write a lot of C/C++ code. They know what they are doing.
Edited 2015-01-10 18:36 UTC
Would someone mind explaining what advantages Rust has over Haskell? The final feature set looks very similar to Haskell, and the language syntax is ugly (compared to Haskell), right up there with (some) C++ and Perl, IMO. That alone makes me want to avoid it.
In the past I’ve gone through the guide and have had some discussions with developers on GitHub and to me they felt kind of snoody, so I know this has jaded me some.
Haskell compiler is just too inefficient. I saw lots of discussions about how it can be “as fast as C” popping up once and a while over the years, but so far, it didn’t delivered it, not even by a long shot. Crafting Haskell code that goes near C usually requires that you bend the functional rules using quite absurd techniques and has a mind map of all compiler’s pitfalls.
Rust is quite the first (somewhat) functional programming language that can be realistically used in systems software without tradeoffs with performance.
I agree with you about the syntax. It’s far from elegant and clean.
Huh? LISP is ancient and has been used to build a bunch of systems. No?
I personally find Rust’s syntax atrocious, so out of curiosity what actual advantages do you think it has over its competitors?
tylerdurden,
My first thought is that I’m not a big fan of the syntax either. Maybe my mind is tainted by preconceptions, “let mut X = Y” reminds me of basic and seems like it might get old quickly.
Nevertheless I can definitely see that Rust does a great job incorporating compile time safety constructs into the language. It’s something that’s long bugged me with C & friends. “GIGO” is a common saying for traditional devs, and that will never completely go away. Yet it’s always bugged me when a language would happily compile binary code that a static analysis would prove is logically incorrect, like overflow errors or concurrency problems, etc. It’s much nicer to have the compiler emit an error at compile time than to (maybe) get a run time error or crash. I absolutely see the value in this, and getting this at compile time is even better since they’ve eliminated many of the safety vs performance gaps that lead to compromises in other languages.
Admittedly I’m rather tired of new languages in general (the concept of a new language gets old), but I think Rust just might be compelling enough for me to justify learning yet another.
Edited 2015-01-11 23:12 UTC