Linked by Thom Holwerda on Fri 9th Jan 2015 23:22 UTC
General Development

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).

Order by: Score:
Comment by ssokolow
by ssokolow on Sat 10th Jan 2015 00:35 UTC
ssokolow
Member since:
2010-01-21

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.

Reply Score: 4

Good
by krakal on Sat 10th Jan 2015 11:56 UTC
krakal
Member since:
2015-01-03

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.)

Reply Score: 3

RE: Good
by Savior on Sat 10th Jan 2015 13:47 UTC in reply to "Good"
Savior Member since:
2006-09-02

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.

Reply Score: 8

RE[2]: Good
by krakal on Sat 10th Jan 2015 22:11 UTC in reply to "RE: Good"
krakal Member since:
2015-01-03

Go is not a systems programming language[,...] 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.

Reply Score: 2

RE[3]: Good
by wargum on Sun 11th Jan 2015 00:47 UTC in reply to "RE[2]: Good"
wargum Member since:
2006-12-15

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?

Reply Score: 3

RE[4]: Good
by krakal on Sun 11th Jan 2015 10:32 UTC in reply to "RE[3]: Good"
krakal Member since:
2015-01-03

No

Reply Score: 1

RE[3]: Good
by Vanders on Sun 11th Jan 2015 13:06 UTC in reply to "RE[2]: Good"
Vanders Member since:
2005-07-06

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.

Reply Score: 3

RE[4]: Good
by Kensei on Mon 12th Jan 2015 11:49 UTC in reply to "RE[3]: Good"
Kensei Member since:
2015-01-12

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

Reply Score: 2

RE[4]: Good
by tylerdurden on Mon 12th Jan 2015 23:21 UTC in reply to "RE[3]: Good"
tylerdurden Member since:
2009-03-17

I'm suspicious of any language with a runtime library that claims to be a systems language.


You mean, like C?

Reply Score: 2

RE[3]: Good
by galvanash on Tue 13th Jan 2015 08:37 UTC in reply to "RE[2]: Good"
galvanash Member since:
2006-01-25

Yes, Go is a systems programming language (http://en.wikipedia.org/wiki/System_programming_language) and most people agree it is.


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):

A language that requires a GC is a language that opts into a larger, more complex runtime than Rust cares for. Rust is usable on bare metal with no extra runtime. Additionally, garbage collection is frequently a source of non-deterministic behavior. Rust provides the tools to make using a GC possible and even pleasant, but it should not be a requirement for implementing the language.


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...

Reply Score: 2

RE[4]: Good
by tylerdurden on Tue 13th Jan 2015 23:58 UTC in reply to "RE[3]: Good"
tylerdurden Member since:
2009-03-17

Why is garbage collection a disqualifier for systems programming?

Reply Score: 2

RE[5]: Good
by galvanash on Wed 14th Jan 2015 00:40 UTC in reply to "RE[4]: Good"
galvanash Member since:
2006-01-25

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.

Reply Score: 2

RE[6]: Good
by tylerdurden on Wed 14th Jan 2015 20:29 UTC in reply to "RE[5]: Good"
tylerdurden Member since:
2009-03-17

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.

Reply Score: 2

RE: Good
by shmerl on Sun 11th Jan 2015 02:09 UTC in reply to "Good"
shmerl Member since:
2010-06-08

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++.

Reply Score: 1

v Ah yes...
by deathshadow on Sat 10th Jan 2015 17:36 UTC
RE: Ah yes...
by wargum on Sat 10th Jan 2015 18:34 UTC in reply to "Ah yes..."
wargum Member since:
2006-12-15

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.

Rust, the programming language for people who think C++ is a bit too clear, verbose and easy to follow


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.

mixed with appeal for the Twitter generation that's too lazy to type anything -- The IOCCC is gonna LOVE this one.


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.

Of course, if it's "feature complete" why is it an ALPHA? doesn't that mean "Beta"? :/


"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.

Am I really supposed to trust a programming language built by people too stupid to even use HTML and CSS properly?


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

Reply Score: 7

What's the advantage over Haskell?
by draugen on Sun 11th Jan 2015 05:44 UTC
draugen
Member since:
2014-06-28

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.

Reply Score: 2

CapEnt Member since:
2005-12-18

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.

Reply Score: 3

tylerdurden Member since:
2009-03-17


Rust is quite the first (somewhat) functional programming language that can be realistically used in systems software without tradeoffs with performance.


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?

Reply Score: 1

Alfman Member since:
2011-01-28

tylerdurden,

I personally find Rust's syntax atrocious, so out of curiosity what actual advantages do you think it has over its competitors?


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

Reply Score: 3