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

[DaMattster]

I thought that null pointers are necessary in order to terminate a linked list. What you want to avoid doing is dereferencing a null pointer as this is a very bad thing. At least, this what I rememebr from Comp Sci 102. How else can one terminate a linked list other than creating a tag labeled "end" ?

Re:No null pionters

[warrax_666]

type Maybe a = Just a
                                                              | Nothing

Simple and doesn't infect every fucking variable access with the possibility of null.

Re:No null pionters

[JasterBobaMereel]

A Value that explicitly shows no object, no one that can be interpreted as an object at an address..

The real question is do you want a high level language, or a low level one

C is a low level language, it can directly access memory, has to have libraries to do anything, and you have to manually allocate memory (libraries often do this for you) - This gives you the power to to anything (if you can work out how to do it), but at the cost that you can easily do the wrong thing...

C# is a high level language you have no direct access to memory (or even the machine), and you work with objects not memory, this means you lose some power being one step away from the machine, but you gain security in that the system will stop you doing most stupid things ...

C++ tries to be the best of both worlds and but is really the worst of both worlds ...

Re:No null pionters

[somersault]

Sounds less like a stream and more like a water processing plant.

Re:No null pionters

[mcavic]

Null±1 is really no different than null itself. It's a special value that's not a memory location. And a tag labeled "end" doesn't make sense. There would be no good way to differentiate the "end" tag from real data.

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

[sawatts]

C++ is what you make of it.

Re:No null pionters

[Artraze]

When it comes down to it, NULL is just a sentinel... and a red herring. You can really replace it with anything; Python does it with "None", for instance.

In the case of a linked list, it could be an agreed upon singleton or an empty value/link which, depending on the language/design, either link to themselves, or throw an exception when you try to access their next. Another option is to just link it circularly and have the sentinel be the 'start' of the list. But, you may say, that causes exceptions, infinite loops, or silent failures (e.g. passing around a sentinel)! Exactly.

NULL is one of the greatest red-herrings in programming. People dream of eliminating it because it causes so many problems, but the reality is that they're just shooting the messenger. The real problems are the conditions that brought the NULL about in the first place... Bad data, missing value, computer on fire, etc. I suppose that one could argue (as I'm sure Mozilla does), that NULL presents a security risk, and, yes, it does but no more than arrays or pointers in general. That's why we have 'managed' languages these days, which is, as best as I can tell, what Rust is: yet another 'managed' programming language. I guess it could be interesting, but I'll won't be holding my breath until it's used outside Mozilla.

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:No null pionters

[Anonymous Coward]

I guess none of you have ever heard of sentinels? The list itself is a valid node that is used a both the head and tail of the list.
if (list == list->next) // you are at the head/tail

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

[DragonWriter]

An "empty list" in lisp is usually implemented as a null pointer.

Maybe, but that's irrelevant.

Lisp knows where lists end because the cdr field of a pair is null. So lisp has null pointers, they just hide it behind some S-expression terminology.

No, Lisp, the language, doesn't have null pointers (or pointers, per se, at all). A Lisp implementation in another language may implement some lisp features using pointers, including null pointers, in the host language, but that's very different than Lisp having null pointers

Re:No null pionters

[lambent]

The graceful way is to actually write code properly. But apparently, it's far simpler to just spend five years creating a new language that nobody else is ever going to use.

Re:No null pionters

[somersault]

Actually, we were talking about how to write linked lists in a brand new language. If nobody implements linked lists in that language, then nobody will be able to use them.

Also, what if you want to write a variant of a linked list, so it's more of a tree? What happens if you want to create a completely arbitrary and complex network comprised of multiple classes of object? What happens when someone is just wanting to learn, and all they get in reply is people complaining?

These problems have all been solved before, yes, but people should understand the solutions and be able to recreate the solutions from scratch if necessary, rather than relying on books and libraries. The OP talked about linked lists as if they were baked into a language, but really they're just a pleasant side effect of being able to use references, and any programmer should be able to recreate them.

Re:No null pionters

[DragonWriter]

Pointers, references, whatever.

Uh, no, there are meaningful differences.

Lisp still has a null value, like Java and most other languages.

Yes, Lisp -- like many other languages -- has a special null value. This is very different from a null pointer.

If you run (cdr '()), you get an error.

Yes, that's one of the common differences between a null value and a null pointer; manipulations involving a null pointer can often produce incorrect results rather than a proper failure.

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.

Re:No null pionters

[Waffle Iron]

We're not discussing C-style segfaults in this case.

The main meaningful difference between references and pointers is that pointers allow pointer arithmetic, and references don't. As far as I can tell (the spec seems rather vague), this Rust language doesn't allow pointer arithmetic, so it's using "references" (unless explicit unsafe constructs are used).

From what I gather skimming the spec, unlike languages like Java or Lisp, Rust doesn't allow the creation of null references; this is an attempt to avoid errors like (cdr '()) or "java.lang.String foo = null; foo.length();". This is a significantly stronger restriction than most other languages.

Re:No null pionters

[MtHuurne]

Making it explicit is a very important difference with Java, where every reference can be null. In Rust you can check the formal interface to see whether you can pass a null argument, while in Java you have to check the informal JavaDoc and hope the author documented whether the argument is allowed to be null. Also the Rust compiler will check both the caller (type error if you potentially pass null where it is not allowed) and the callee (pointer must be unpacked explicitly), while in Java the check is only done at run time.

Re:No null pionters

[anonymov]

That's where +- part comes from. For x86 it's just CMP reg, imm32, for x64 you could probably spare one of 16 general registers to hold it for the loop, etc etc etc.

Anyways, it's a moot point. Using linked lists for performance critical parts is already bad idea and a few dozens cycles won't make difference in other cases.

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

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

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?

Re:ultimately as fast as C++

[GreyWolf3000]

C with a struct/macro based object oriented framework. See Linux.

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.

Re:Another compiler? Seriously?

[TheDarkMaster]

And a interesting detail... Every "new and shiny" language I see emerging in these years are slower and more resources-hungry than than the previous ones. To do the same work

Re:Another compiler? Seriously?

[Grishnakh]

What I want to know is why did they go to all the effort of creating a whole-new language, instead of just using some other one if they're that dissatisfied with C++. There's tons of newer, lesser-used languages out there that address deficiencies in C/C++, such as Objective-C and D, which are already in existence, have been worked on for years, have compilers available, etc. I'm not a programming language whore, so I don't really know exactly how these other minor languages compare, but it seems like one of them should have fit the bill. This seems like a case of reinventing the wheel to me.

Re:Another compiler? Seriously?

[DragonWriter]

What I want to know is why did they go to all the effort of creating a whole-new language, instead of just using some other one if they're that dissatisfied with C++.

Because the people involved are dissatisfied with the alternatives to C++, as well.

There's tons of newer, lesser-used languages out there that address deficiencies in C/C++, such as Objective-C and D

The concerns they have with languages in the same abstraction/efficiency neighborhood as C++ (per the project FAQ) are:

1. Insufficient concern for safety,
2. Poor concurrency support, and
3. Lack of pragmatism due to overly dogmatic adherence to an arbitrary paradigm.

Implicitly, as the long-term goal is something you could rewrite Firefox in incrementally, the ease of interfacing with C++ is also important.

I don't think either Objective-C or D address these concerns particularly well.

I'm not a programming language whore, so I don't really know exactly how these other minor languages compare, but it seems like one of them should have fit the bill.

The people that actually worked on Rust have quite a lot of experience with the alternatives (many of which are specific called out as inspirations for some of the design choices in Rust), and have found that they don't fit the bill.

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:They no longer need developers, it seems..

[K. S. Kyosuke]

get proficient in a new, complex programming language just to contribute to a project?

...as opposed to getting proficient in the incredibly easy and definitely-not-treacherous language called C++? Uhm, where do I sign in?

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

[Samantha Wright]

1. Feel free to back up some or all of those claims about "constant refusal".

2. The migration to Rust will be gradual, and although it uses some new syntax and permits new paradigms, the code's not that hard to read.

I could now go on about how a developer not interested in facing new challenges, such as a change in language or project, does not have the right mindset to be a good programmer, but that may be a bit harsh.

Re:Sure way to attract developers

[beelsebob]

They're thinking that any good programmer can pick up a new language within a week or two, so this has a two fold benifit: one - getting rid of the crap programmers who can't think in more than one way; and two - helping their good programmers to write better code.

A tag labeled "end"

[tepples]

So what's the difference between a tag labeled "end" and a null? Or what's the difference between a type that can hold either an element reference or a tag labeled "end" on the one hand and a type that can hold either a reference or a null on the other hand?

Re:A tag labeled "end"

[Laxori666]

A 'null pointer' is not a type - it's just a possible *value* for a pointer. Dereferencing a pointer is type-safe. Dereferencing a pointer whose value is null causes a run-time crash.

The idea with the 'end' is that 'end' would be a type. Your list elements would be U(T, end) - union of type T, and end. You won't be able to use a U(T, end) just like a T, cause you'll get type errors (as 'end' is not a subtype of any other type). You'll have to do some checking which the type-checker will verify. So you check for end, and in the True branch, the type is 'end', and in the False branch, the type is 'T'. It will be impossible (if a program passes type-checking and the type-checker is type-safe) to dereference an 'end' value.

See Haskell, which has no 'null', and to have a 'None' value you have to explicitly encode it with the Maybe monad.

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

[0123456]

There are roughly a bazillion C++ programmers in the world that they can hire. How many Rust programmers are there?

As others have said, it's just another dumb idea to add to the recent history of dumb ideas coming out of Mozilla.

I like the shortened names

[Vektuz]

Because every time I see someone abbreviate "Function" as "Fn" I read it as "effing"

C# has null pointers

[tepples]

C# is a high level language you have no direct access to memory (or even the machine), and you work with objects not memory, this means you lose some power being one step away from the machine, but you gain security in that the system will stop you doing most stupid things ...

But even C# allows reference variables to be set to null. The type of a C# reference variable is just as much of a maybe as the type of a C++ pointer variable. Null-reference exceptions are just a special case of wrong-type exceptions from a tagged union.

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:Wash it in some alkali

[TheDarkMaster]

Is just more "shiny" to create a new language to solve all problems of the universe(tm) and for awesomeness than focus on correct bugs into the existent (and working) system.

No big rewrite necessary

[DragonWriter]

The Firefox codebase definitely has some huge issues, but does anyone remember the big Netscape rewrite for version 6?

Presumably, the whole point of Rust's C++ compatibility is that you don't need to do a big rewrite if you have an existing C++ codebase, you do module-by-module rewrites as is convenient.

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:They no longer need developers, it seems..

[somersault]

Who cares? How many of those "bazillion" C++ programmers would you entrust the security of your computer to, ideally?

I am not one to hop onto a new language simply because it's there, but when the language is actually being designed by a bunch of guys to get shit done in a production environment rather than just as a lab project, that IMO seems like a good start. Maybe it's just because I've almost run out of stuff to do at work and am looking for new things to work on/with, but this seems interesting to me.

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.

Null pointers do exist, but checking is enforced

[pavon]

They are handling this the same way that many other languages which "don't allow null" do.

By default, references are not allowed to hold null pointers, and the compiler enforces this by ensuring that a valid object is assigned when the variable is created. This is nice for the majority of references which should never be null.

When a reference can be null, it has to be defined using special syntax (like adding a question mark to the type). In this case, the compiler forces to always check for null before dereferencing the variable. Which is also nice.

Those who look at the language as it's grammar will say they have been removed. But those who look at the language as what you can do with in realizes the concept still exists, just with different syntax. Either way the language strictly limits the way you use them to eliminate nearly all of their problems.

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

[K. S. Kyosuke]

Reducing your choice of programmers to hire to those who think that writing a new language to write your application is is a good business plan... does not sound like a good business plan.

It worked for ITA (Common Lisp), Fog Creek Software (Wasabi), GNU (Emacs Lisp), and I'm pretty sure there are more examples.

Re:As Fast As Cee

[tepples]

So in other words, once they optimize the [expletive] out of their maybe types, they'll be back where they started.

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.

Implicit

[tepples]

Null inhabits every single (non-primitive) type in the C# language.

What's the difference between null inhabiting a type and the type being an implicit tagged union?

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"

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:They no longer need developers, it seems..

[Grishnakh]

C# had legions of Microsoft developers that were willing to follow MS wherever they led for their paycheck.
Mozilla doesn't have that kind of power.

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

[Jonner]

C++ is horrifically complex and difficult to use safely. As a high level programmer, I'd be much more inclined to learn Rust, which is almost certainly simpler and easier to use safely.

Re:As Fast As Cee

[K. S. Kyosuke]

So in other words, once they optimize the [expletive] out of their maybe types, they'll be back where they started.

That's pretty much it, except that they will have statically proven that null pointer exceptions can't be thrown in their code, which is probably the purpose of the whole thing.

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

[Desler]

And being a good programmer also means you don'tÂstop using mature and battle-tested technology for something immature without good reason. Both C and C++ have plenty of issues but they have decades of experimentation and real-world experience backing them up while Rust is nothing more than a pet project with no real-world history and unknown number of issues and potential bugs. The good programmer will stick with the tried-and-true not jump to the flavor-of-the-week language just to look hip and cool. To the cargo cult programmers this is looked down on but their toy projects are meaningless tripe.

Re:5 years?

[unixisc]

Given that this is Mozilla, this should have been version 1. A bug fix they issue next week should rev it up to version 2, and so on

Looks good, at first glance

[Animats]

It's interesting. The language has a lot of features I've suggested for years, such as language support for single-ownership and reference-counted pointers. One of the two basic problems with C is that programming requires obsessing over who owns what, and the language provides zero help in dealing with that problem. (C++ papers the problem over with collection classes, but the mold always seeps through the wallpaper when a raw pointer is needed.)

The immutable-by-default concept and local scoping with "let" is a win. It moves the language in the direction of single-assignment programming, which has most of the advantages of functional programming without the heavy nesting.

The declaration syntax is better. With name : type the syntax can be context-independent, which means you can reliably parse program text without reading include files to get the names of all types first. You can't parse C or C++ reliably without knowing what's a type name, which requires reading all the include files. This makes it much easier to write tools which take in source code and do useful analysis or cleanup.

Downsides include the typical negatives of the open source world - the name "Rust" is lame, and the Windows version has to be built by the end user.

Not again.

[slasho81]

First, an actual link to the language's site.

Second, isn't it time we stop reinventing the same language over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Are We There Yet?.

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!

Re:how do you test code to handle hardware faults?

[anonymov]

Aaaaand here we go from general case to an unrelated corner case.

"How would you trigger a run-away truck breaking through your datacenter? What, catching NPEs ain't helping you now, buddy?"

We were discussing software and catching exceptions, and here you go with hardware and catching faults.

Anyways, if you're testing software detecting and reacting to ECC faults, you do it on a test rig with ECC error injection, no need to keep broken DRAM around. Don't you notice the oxymoron in "Untested fault-tolerant software"?

But as we were not talking about software detection of hardware faults, your argument is invalid.

Re:Rewriting Would Be a Mistake

[Animats]

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.

OS X is a hack on NeXT's OS, which is a hack on Mach, which is a CMU hack on BSD, which is a hack on UNIX 32V (AT&T's VAX UNIX), which is a hack on UNIX System 7 for the PDP-11.

There are original, new operating systems, but they're rare, IBM VM, QNX, AT&T Plan 9, and PenPoint come to mind. Windows NT really was a fresh start, but it wasn't backwards compatible with the DOS/Windows 3/Windows 95 sequence. Those were merged, painfully, in Windows NT 4, 2000 and XP. I can't think of any recent, successful examples.