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

Comments

No null pionters

[tepples]

From the article: "null pointers are not allowed". So what better type is there to represent what amounts to a tagged union between a reference to an object and a value representing the lack of an object?

Re:No null pionters

[Samantha Wright]

I looked it up. Instead of using a null pointer they have an explicit "optional" type. I believe the compiler then checks to make sure you're using them correctly, like Java does with everything, instead of letting you burn yourself on the stove by trying to dereference a null. When you get down to it, it's not that exciting or surprising.

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.

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?

Re:Another compiler? Seriously?

[Anonymous Coward]

They need a special compiler that doesn't use minor version numbers so they can catch up to Chrome by the end of the year.

Wonderful!

[Chemisor]

Yet another solution in search of a problem.

Re:Wonderful!

[DragonWriter]

Yet another solution in search of a problem.

Since this comes from the people who have identified a problem in a codebase they own that this is intended to address, I don't think that that's the case. It may not be a problem you have, and it may not be the solution you'd prefer in their place, but that's not the same thing as it being a solution in search of a problem.

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:ultimately as fast as C++

[jbeaupre]

There's no language out there "as fast as C++" across the board for everything you can write in C++.

Assembly?

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

[anonymov]

Proper tagged union has to be explicitly "de-unionized" before trying to do something with it - that's when you can catch stray nulls/Nones/Nothings.

Basically, proper type system _forces_ you to go from Option[Sometype]/Maybe Sometype to Sometype before you can do anything with it, null, on the other hand, pretends to be a part of Sometype - when type union "Sometype + null" should be a separate type, so compiler doesn't know if you properly checked for it or not.

There is type systems with explicit "nullable" type attribute, this is closer to Option type.

And with proper optimization "Option[Type]" should yield approximately same code as "nullable Type"

could the summary be less accurate?

[fusiongyro]

From the Rust Project FAQ:

Are you going to use this to suddenly rewrite the browser and change everything? Is the Mozilla Corporation trying to force the community to use a new language?
No. The Mozilla Corporation's involvement is at the labs level: the group concerned with doing experiments. The point is to explore ideas. There is currently no plan to incorporate any Rust-based technology into Firefox.
...
What are some non-goals?
...To cover the complete feature-set of C++, or any other language. It should provide majority-case features.

The absolutely brazen, bald-faced misinterpretation of what's going on here is stunning. They could not miss the point by more!