“Today Mozilla and the Rust community are releasing version 0.1 of the Rust compiler and associated tools. Rust is a strongly-typed systems programming language with a focus on memory safety and concurrency. This is the initial release of the compiler after a multi-year development cycle focusing on self-hosting, implementation of major features, and solidifying the syntax. Version 0.1 should be considered an alpha release, suitable for early adopters and language enthusiasts. It’s nifty, but it will still eat your laundry.”
It’s like they’ve taken all the good bits from Haskell and thrown them into a C-like language making them not hurt your (my) brain so much. The new interfaces they’ve added is especially cool.
See http://doc.rust-lang.org/doc/tutorial.html for a overview of the language.
Edit: Also the fact that the authors are dogfooding the language by writing the compiler in it speaks volumes to me.
Edited 2012-01-23 23:07 UTC
Interesting, they are using generics as well. Unlike Java which ignored it until later, which resulted in convoluted and limited generics design and implementation.
Agreed.
At first I thought that Go is everything Rust is, but when you take a closer look you see that they both serve different purposes.
Go is a full on relaunch of what a systems language should be and do, while Rust seems to be a migration target for C++ projects and programmers. If they really eventually write parts of Firefox in Rust it could earn its laurels and prove that it is production ready. And it might even pick up steam.
You need lighthouse/beacon projects that can propel a language into mainstream. You also need a major backing. Mozilla (like Google) can provide that. (Crack, Clay, D etc will have a much harder time convincing people)
I personally really wish Qt would get something more modern than C++, GTK has Vala, but for Qt it is either slow Python or hard-to-learn C++.
Side note, OSnews is a great website, because here people see the potential in new technologies. On Slashdot everybody seems to act like whining little bitch each time something new comes along that might encompass change.(OSnews has those too, but they aren’t the majority it seems)
Edited 2012-01-24 18:25 UTC
kragil,
“You need lighthouse/beacon projects that can propel a language into mainstream. You also need a major backing.”
I agree one needs major backing to push a new language into the mainstream. These days, the modern language market is so crowded & fragmented, with no compelling advantages over the other, that they all hurt each other’s chances at displacing the incumbent languages regardless of merit. I think this is the main reason why older languages have lasted so long in spite of being rough around the edges and falling behind feature-wise.
“On Slashdot everybody seems to act like whining little bitch each time something new comes along that might encompass change.(OSnews has those too, but they aren’t the majority it seems)”
At the risk of being so labeled, we are often subjected to technologies that are merely superficially new without contributing anything substantial to the state of the art.
I would like to see new languages becoming unified to gain momentum and overtake older languages, but I’m not counting on that happening.
There are quite a few other bindings such as QtAda.
Now, the question is how good are these bindings?
I don’t know..
It would be very interesting, if something like Qt Rust would emerge.
Where is the design document? Do they have any goal and/or justification of features? It seems like an attempt for a modern “safe C”, which in itself is not so bad. But then why not Go?
Here is a good talk about it:
http://www.aminutewithbrendan.com/pages/20101206
Rust was actually started before Go, so the question “why not Go” isn’t really correct.
Edited 2012-01-24 00:39 UTC
Thanks for sharing this.
Because Rust appeared in 2006 and as such is older than Go.
Second because Go in its current form is too simple, leaving behind decades of computer science research, along with features that most mainstream languages offer.
Anyway I find difficult to introduce new systems programming languages as long as an OS vendor does not pick them up.
For the business application development area there are already many languages available, reducing system programming languages to the use cases where close interaction with the OS and hardware is required.
Unless new systems programming languages get somehow a spotlight in a specific OS, they will never replace existing ones.
I am still hoping that it will happen though.
Last week clay announced version .1 as well. In my opinion it’s a much better systems language. rust has to compete with ‘d’ and ‘go’ and all other garbage collected languages.
From what I saw, rust isn’t garbage collected.
Garbage collection is optional there.
Rust does do include garbage collection. it’s just that reference counting is “preferred” (clay only supplies explicit reference count semantics).
http://lambda-the-ultimate.org/deca
The Deca programming language is “a language designed to provide the advanced features of sophisticated, high-level programming languages while still programming as close as possible to the bare metal. It brings in the functional, object-oriented, and generic programming paradigms without requiring a garbage collector or a threading system, so programmers really only pay in performance for the features they use.”
Edited 2012-01-24 08:53 UTC
deca is still more vapor than something like clay. there’s papers and work on BNF, etc for deca, but no known implementation. the clay guys are the other side of the coin. I asked a few time (on irc) if they had any BNF, etc and was explicitly ignored. There’s something to be said for an inbetween approach (move forward with experimentation, back fill BNF to check for stupid mistakes, etc).
Vapor? It should not be hard to click the link.
http://code.google.com/p/decac/source/checkout
okay not fully vapor but not functional either. Read the recent updates. I’m sure its in production now just like rust and clay are (not).
http://code.google.com/p/decac/updates/list
… because there are people out there for whom C isn’t cryptic enough; which is akin to the Puritans coming to Boston in 1630 because the CoE was a bit too warm and fuzzy for their tastes.
“aggressive abbreviation in the keywords” being geekspeak for “how much more difficult can we artificially make this language” — treading into the territory of the old joke about Unix and C being a hoax.
http://www.elsop.com/wrc/humor/unixhoax.htm
I know, I know… Wirth elitist checking in… as if verbose code is somehow the ultimate evil. But as I’ve said a dozen times I’d sooner hand compile 8k of Z80 assembly than have to deal with 1k of C source… as if it needs an obfuscation contest given what the code looks like when NOT trying to be unnecessarily vague.
Programming languages like this seem to exist for the sole purpose of making programming difficult.
Yes, I didn’t understand the need for aggressive abbreviation there. Does it really help anyone?
1) In earliest days of UNIX it was probably harmless when APIs (let alone commandline utilities) where few and hence collisions were unlikely. But things have grown since then, making it a necessity to avoid abbreviations for the sake of avoiding collisions…at least.
2) “Everything should be made as simple as possible, but no simpler.” -Albert Einstein
3) “Give me a pot, i don’t feel well!” -My mind
Edited 2012-01-25 15:51 UTC
While their flagship products support only the cygwin+cl build system on windows this time they use pc-mingw32.
It seems that their flagship products are intentionally crippled against clang/gcc on windows.
Please re-consider your position. Clang/GCC are strong on windows and there is no excuse to avoid them
More importantly the mingw cross-compile from linux is out of the question and building on ReactOS is also impossible.
Last night I decided to give a spin on my msys/mingw system (half of my OS 🙂 actually )
I found out that they depend on LLVM. While running the configure script I decided to take a more careful look at their web-page. In this page they hope that one day parts of Firefox could be written in the future in Rust.
That made me wonder. Why D is not suitable? Why they do not back LDC2?
In D they could start immediately replacing parts of FF with minimal to moderate performance lost. They could port their wrappers from Rust to D and have a better environment.
Moreover D has ide support and syntax highlighting support. And it seems that it does exactly what they need.
Google Go also has these features in a smaller degree but it could also offer simplified concurrent programming facilities.
But D has been tested in real apps (like Entice/Poseidon/Bud-build) and other projects. Personally I have used Go to port a network frame grabber from C++. I reached the same speed with one file that compiled on windows and a minimally modified counterpart for Ubuntu. It was a very fun / painless experience. I can recommend it but I do not have GUI experience in Go. It seems not mature. OTOH, D also supports conditional compilation. It is a killer feature.
IMO, LDC2 is an effort that Mozilla should back.
I might be wrong about this, but aren’t there some convoluted licensing issues around D that would cause problems for them? I was under the impression that, while version 1 of the D language specification is open (though the official compiler is not), version 2 wasn’t. I could be wrong about this. I researched it once and I remember getting a headache trying to wrap my brain around the licensing. Anyone more knowledgeable than me on this care to clarify or correct me, please?
I’m not sure what you mean by an “open” specification. People use the term in so many ways anymore.
If by “official” compiler you mean the digitalmars one, the frontend is available under a dual license, Artistic and GPL. The source for the digitalmars backend remains proprietary afaik but how that would affect the Mozilla foundation I have no idea. There are also GCC and LLVM backends available under GPL and BSD respectively.
All those issues are long gone. There are three implementations available:
– DMD – Official one from Digital Mars
– GDC – D implementation for GCC. It will be made part of GCC official languages in the 4.7 or 4.8 release.
– LDC – LLVM backend implementation
Please note that nowadays D means D2. D1 will no longer be supported by end of 2012.
I am also on the D bandwagon but the lack of momentum or interest for ARM support is problematic.
When the documentation of a language starts by showing all the cool stuff you can do which isn’t possible in other languages (like mixing up stataments/expressions so wildly) the language usually sucks. Stuff such as:
let x = if the_stars_align() { 4 }
else if something_else() { 3 }
else { 0 };
Is not useful, it’s unreadable language programmer ego masturbation.
I’d rather a language intentionally AVOIDS from allowing you to do all this stuff and forces you to write more code, that is more to the point and readable. After all, programmers don’t spend most time writing code but thinking what to write.
Edited 2012-01-25 16:52 UTC
I am not sure what your problem is. That if expression is nearly identical to the equivalent OCaml, which makes sense for a language trying to discourage the use of mutable variables.