Mozilla Releases Rust 0.1

MrSeb writes "After more than five years in the pipeline, Mozilla Labs and the Rust community have released the first alpha of the Rust programming language compiler. The Rust language emphasizes concurrency and memory safety, and — if everything goes to plan — is ultimately being groomed to replace C++ as Mozilla's compiled language of choice, with Firefox (or parts of it) eventually being re-written in Rust."

ultimately as fast as C++

[epine]

When people say "ultimately as fast as C++" they always mean "for the idiom/paradigm we wish to carry forward". There's no language out there "as fast as C++" across the board for everything you can write in C++.

The implied retort: Well of course not, nobody would invent such a stupid language from scratch, combining such a disgusting mishmash of paradigms.

C++ syntactic morass: tired
underlying C++ conceptual model: pretty good, accounting for dog years
Racial purity: MIA

Survival's Ick Factor [nytimes.com]

At the end of the day, C++ keeps us united.

Another compiler? Seriously?

[qrwe]

So, Mozilla has kindly given the Open Source community yet another language to read about, learn, try out and (after some time) eventually master. And this just to handle a web browser? Sweet Moses.. What's the fuss all about? Can't Mozilla just give us the real favor and stick to a robust industry standard (C++) which has loads of talented and skilled contributors?

Wash it in some alkali

[unixisc]

Oh great - just what we need - yet another programming language. Never mind that there ain't enough people to teach kids and adults the languages we already have. Instead of training people to hone their skills in C, C++, Obj-C, Obj-C++, Java, Python, et al, what better than to come up w/ a new language that one would have to learn from scratch, and whose only contribution would be 'hey, GCC supports this as well!'. That too w/ such an inspiring name as 'Rust'. And 0.1, meaning it's currently unusable. Why not wait until 1.0 is ready before announcing it?

Re:They no longer need developers, it seems..

[Anonymous Coward]

how many will be willing to learn and get proficient in a new, complex programming language just to contribute to a project?

Probably the same number of developers that are willing to put in months of time to learn the Mozilla code base.
Learning a new programming language is simple compared to reading millions of lines of a complex software project

Re:Rewriting Would Be a Mistake

[fremen]

I remember reading this back in the day, but this article has not aged well. Joel is a smart guy, but this advice is frankly ludicrous.

In Joel's world, Apple would have never scrapped Mac OS Classic and launched OS X. And Microsoft would have never scrapped the old DOS underpinnings and started over with the NT kernel.

Starting over happens all the time in software projects, and I'll admit that in many cases it's a waste of time. But quite often, it's an excellent idea. The world changes, and despite what Joel thinks, software really does age.

In the case of Netscape, I would say that their rewrite worked out pretty well. Mozilla was a big jump forward in browser technology, and then Firefox (which itself was a rewrite of Mozilla) has become a truly successful browser.

Re:No null pionters

[Anonymous Coward]

But if my program tries to dereference null, I WANT it to crash and burn. I don't want some silly automatic no-error-ever scenario that makes bugs in my code harder to find.

Re:Rewriting Would Be a Mistake

[gbjbaanb]

the big issue with rewrites is that people doing the rewrite often think they can do a better job that their predecessors,and invariably find that their predecessors weren't as crappy as they thought they were.

It also beats me why they thought a new language is the solution (looking for a problem perhaps) instead of a solid class library to do all the stuff they need help doing. The existing C++ community might get something out of it too then.

Re:Sure way to attract developers

[gbjbaanb]

then why aren't they thinking that codifying their common code problems in the existing language won't help? A refactoring using C++ would fix all their problems as surely as a rewrite, only it'll be a lot quicker and wouldn't introduce so many new bugs. It might also give rise to some nice libraries that can be used too.

A rewrite in Rust helps no-one, just you see. They might as well rewrite in node.js

Re:Wonderful!

[Svartalf]

Actually...the problem can be solved by re-thinking their codebase rather than coming up with a tailor-made language that may/may not really fix things. Coming up with a new language for the problem they're seeing is...a bit foolish... Now...if it's the same problem in other places, perhaps it's time to come up with a new one; but they're not facing anything that a proper clean-up, refactor, and rethink wouldn't fix in C++. Seriously.

It's not properly multi-threaded. A stall in an HTTP fetch somewhere or a rogue plugin (Flash...sigh...) can wedge the entire browser application up tighter than a drum.
It's over designed with an Object-Heavy Microsoft COM-like object framework on top of the other sins in their over-engineering.
It leaks memory out the wazoo- not because of the language, but because of sloppy coding and poorly thought out designs. A language might help "prevent" the problems after a fashion, but so far, there's not very many useful, high-performance answers there that don't have some idiot loophole somewhere- even Java has ways of hosing it up.

A new language won't fix those problems. Sitting down and re-thinking some of this would.

Re:No null pionters

[0123456]

"and your thread probably throws a null pointer exception ... and you catch it and do a graceful shutdown."

Yeah, right. Show me all the Java programs which do that.

Not to mention that if one thread just threw an unexpected exception you have no idea what the state of the system is and a 'graceful shutdown' is just as likely to irretrievably corrupt your data as to preserve it. Assuming it can manage to shut down at all when the failed thread may be required in order to do so.

Sometimes 'just crash' is the correct answer to 'what should I do if this happens?'

Re:No null pionters

[anonymov]

The problem is you still think in terms of pointers, pointer arithmetic and C++.

Here, have a snippet from Rust's list implementation:

enum list<T> {
/* Variant: cons */
    cons(T, @list<T>),
/* Variant: nil */
    nil,
}
 
/*
Function: has
 
Returns true if a list contains an element with the given value
*/
fn has<T: copy>(ls: list<T>, elt: T) -> bool {
    let ls = ls;
    while true {
        alt ls {
          cons(hd, tl) { if elt == hd { ret true; } else { ls = *tl; } }
          nil { break; }
        }
    }
    ret false;
}

Notice the "alt ls { }" statement (which is Rust's equivalent "case ls of Cons x xs ... ; Nil ... ; end") - that's where the tagged union magic breaks in. Compiler knows there's exactly two variants in type "list" - cons(x,xs) and nil. If you omit one of them from alt statement, it's an incomplete match error. If you try to write "let cons(x,xs) = ls" - it's a type error, as you forgot about null again.

But if you omit "if(ls == NULL)" - it's not even a warning, and that's how you get a run time exception where you could have had a compile time error.