Mozilla Releases Rust 0.1 232
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."
No null pionters (Score:5, Interesting)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re:No null pionters (Score:5, Informative)
Re: (Score:3)
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 onl
Re: (Score:2)
What, comparison operations (the way you'd distinguish a null pointer) don't work on special values that don't happen to be null pointers? There may be some languages where that is true (though they wouldn't be much good), but Rust doesn't appear to be one of them.
Re: (Score:2)
What is the problem with marking a list element as the end element, or perhaps having an element that specifically denotes the end of your list?
You could always create an element with a name like NullListElement that you assign as the end of all lists if you're that fussed about the terminology (as long as you don't expect to be able to go backwards from that, hehe).
Re: (Score:3)
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 b
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
Sounds less like a stream and more like a water processing plant.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
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. // you are at the head/tail
if (list == list->next)
Re: (Score:2)
A distinct value that it is distinguishable from a valid link is necessary to terminate a linked list; the use of a null pointer as the conventional manner of doing this is just what happens to be convenient in certain languages.
A tag labelled "end" doesn't have to be a null pointer; using the former for the latter is convenient in languages which do
Re: (Score:3)
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, inf
Re: (Score:2)
"That's why we have 'managed' languages these days"
Managed languages are no solution; in fact they may be worse. Dereference a null pointer in C++ and your program crashes. Dereference it in a managed language and your thread probably throws a null pointer exception and stops running, but the rest of the program stays up. So it's still running, but just doesn't work.
Re: (Score:2)
> and your thread probably throws a null pointer exception ... and you catch it and do a graceful shutdown. Just like you can do with C++, though.
Anyways, properly typed languages won't even compile if there's a possibility of uncaught null pointer dereferencing. null is just a remnant of dark ages.
Re:No null pionters (Score:4, Insightful)
"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: (Score:2)
You overgeneralize.
Yeah, right. Show me all the Java programs which do that.
Why, they do. "Not all programs do that" != "nobody does that".
Furthermore, "caught an unexpected exception" is nonsense, as well as "no idea what the state of the system is". It is caught because it was expected - except for generic catch-all top level exception handler, which indeed has no idea and is just there for post-mortem actions, like possible dump/log.
Yes, sometimes "just crash" is a proper way to go. And many other times correct answer is "do a cold restart" or "try to recover
Re: (Score:2)
I don't think I could possibly disagree with this more. Arguing that a null-free language doesn't buy you any safety is like arguing that type checking doesn't buy you anything; you are correct that you can still make the exact same mistakes, but the difference is that the compiler will catch most of them. And having the compiler catch most of your mistakes before they become hard-to-find bugs in your runtime is exactly why most serious development is done in type-safe languages. Null is really the last
Re: (Score:2)
"Arguing that a null-free language doesn't buy you any safety is like arguing that type checking doesn't buy you anything; you are correct that you can still make the exact same mistakes, but the difference is that the compiler will catch most of them."
While that's somewhat true, I also disagree. Sure, the compiler will force you to add a null pointer check in a function wihch never expects to receive a null pointer.
But then what?
You write some code to deal with the case that you never expect to happen. The
Re: (Score:3)
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 so
Re:No null pionters (Score:5, Insightful)
The problem is you still think in terms of pointers, pointer arithmetic and C++.
Here, have a snippet from Rust's list implementation:
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: (Score:2)
Re: (Score:2)
An "empty list" in lisp is usually implemented as a null pointer. 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.
Re: (Score:3)
Maybe, but that's irrelevant.
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
Re: (Score:3)
Uh, no, there are meaningful differences.
Yes, Lisp -- like many other languages -- has a special null value. This is very different from a null pointer.
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: (Score:3)
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
A tag labeled "end" (Score:3)
Re: (Score:2)
They both make you crash when you dereference them, but the new crash is shinier.
BTW, is it just me or is Slashdot completely fscked these days? I had to turn off Javascript to get it to work at all.
"Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.
It's been 4 minutes since you last successfully posted a comment"
So how many minutes am I supposed to wait?
A special tag (Score:2)
A special tag is not type-compatible with every other single value in the language.
Re: (Score:2)
So what's the difference between a tag labeled "end" and a null?
A null pointer, if you dereference it, leads to a crash or possibly to a security vulnerability (imagine if you access a structure element, so it is an offset from 0). Whereas an actual, complete object who is treated as "the end" will not cause such problems.
Without null pointers, you avoid a lot of security risks and runtime failures, which are why null pointers are called "the billion $ mistake".
Re: (Score:2)
"Whereas an actual, complete object who is treated as "the end" will not cause such problems."
Until you try to access its 'next' pointer.
Which will either return null, or point to some other random object (itself, the head of the list, etc) which will cause unexpected behaviour, or just crash.
Re: (Score:3)
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
Re: (Score:3, Informative)
type Maybe a = Just a
| Nothing
Simple and doesn't infect every fucking variable access with the possibility of null.
Re: (Score:2)
From the article: "null pointers are not allowed". So what better type is there to represent what amounts to a tagged union [wikipedia.org] between a reference to an object and a value representing the lack of an object?
You've said it yourself, haven't you? Rust is supposed to support union types.
As Fast As Cee (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
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: (Score:2)
a tagged union between whatever type of object reference you intend, and the internal type () -- nil -- which has only one value representing the concept of nullity.
Re: (Score:3)
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 yo
C# has null pointers (Score:3)
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 [microsoft.com]. 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.
No. (Score:2)
Null inhabits every single (non-primitive) type in the C# language.
Implicit (Score:3)
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 (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
How about a primitive type that serves the purpose of Null, without actually being a pointer to 0x0.
Other languages have the concept of an empty object, which is simply an object that discards all input and ignores method calls, without throwing an error. It might return an empty result for whichever type is expected by the context. That could be a boolean FALSE, zero, empty array, etc. You can still ask the object if it is empty, but at least your app won't shit the bed if you accidentally or lazily inv
Re: (Score:2, Insightful)
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: (Score:2)
So what better type is there
None. Nulls are perfectly elegant for representing an empty queue, the start/end of a queue, a pointer that's declared but not yet used, etc. Surely there's a graceful way to handle the dereferencing of a null pointer, instead of eliminating them.
Null pointers do exist, but checking is enforced (Score:3)
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 der
Re: (Score:2)
Why not define a singleton object and call it "Null" or "Nil?"
Cool name (Score:2)
ultimately as fast as C++ (Score:3, Insightful)
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.
Re:ultimately as fast as C++ (Score:5, Funny)
Assembly?
Re: (Score:3)
C with a struct/macro based object oriented framework. See Linux.
Another compiler? Seriously? (Score:5, Insightful)
Re:Another compiler? Seriously? (Score:5, Funny)
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: (Score:3)
Re: (Score:2)
Heh... They keep thinking they've got a better answer, when in fact, all they have is a different one in most cases.
Re: (Score:3)
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
Re: (Score:3)
Because the people involved are dissatisfied with the alternatives to C++, as well.
The concerns they have with languages in the same abstraction/efficiency neighborhood as C++ (per the project FAQ) are:
1. Insufficient concern for
Wonderful! (Score:5, Interesting)
Yet another solution in search of a problem.
Re:Wonderful! (Score:4, Interesting)
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! (Score:5, Insightful)
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: (Score:2)
I would consider null-pointers/seg-faults an existing, and important problem. If someone wants to research a solution, I think it's a worthy cause. (Though the language is enough similar to Go for the duplicated effort to be a concern)
I like the shortened names (Score:2)
Wash it in some alkali (Score:5, Insightful)
Re: (Score:3)
Ok, I give up (Score:2)
And worse, to supposedly "protect" the programmer from himself (pointers are evil, GAHHHHH)? If the developer does not know how to make a good program in one language, it will still not know how to do in any other language.
Re: (Score:2)
It's not about "protecting the programmer from himself", it's about protecting the users. Practically nobody can write secure code in C or C++, where a very significant portion of bugs allow an attacker to run arbitrary code.
Re: (Score:2)
"Java doesn't expose you to pointers."
Every object in Java is a pointer. It's one of the dumbest design choices in that language.
The only difference is that it's guaranteed to point to something or be null, rather than allowing you to point it to random chunks of memory. That means any Java function can be called with null pointers, whereas at least in C++ I can pass objects directly or by non-null references.
I hope this solves the problem (Score:2)
Firefox is so very famous for nom nom noming all your memory over time.
I have to restart it every day because it sits on a whole GB of RAM.
Re: (Score:2)
Re: (Score:2)
well, i will assume that you are already using FF 9, not some old firefox...
show me a modern browser that dont eat ram... my firefox, opera and chrome are all using more than 1GB of ram and by experience, i get more tab open/MB in firefox than in the other two... but test it, open thesame tabs in the 3 browsers and check the ram usage
you might complain that after closing a tab, firefox dont release the ram fast enough, but in a few minutes it will release most of then (the rest it will reuse, its not lost)
b
Looks good, at first glance (Score:3)
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. (Score:3)
First, an actual link to the language's site [rust-lang.org].
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? [infoq.com].
could the summary be less accurate? (Score:5, Informative)
From the Rust Project FAQ [github.com]:
The absolutely brazen, bald-faced misinterpretation of what's going on here is stunning. They could not miss the point by more!
Re: (Score:2)
Use a language with no existing user-base.
WTF are these people thinking!?!
They are probably thinking of their 6 MLOC codebase and about the fact that codifying their common code patterns in an improved language will probably shrink down the source code size a lot, not to mention making it more robust and reliable.
Re:Sure way to attract developers (Score:5, Insightful)
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: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
Really? How is any of this true?
Re: (Score:3)
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: (Score:3)
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.
Re: (Score:3)
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: (Score:2)
"Who cares? How many of those "bazillion" C++ programmers would you entrust the security of your computer to, ideally?"
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.
Re: (Score:3)
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: (Score:3)
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 [rust-lang.org].
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: (Score:2)
How many people have learnt C# ?
A brand new complex language with no users ... seems to be a couple of people use it now ...?
Given a reason people will use a language, an it might even weed out the coding wannabees who try and contribute and get rejected time after time ...
Re: (Score:3)
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: (Score:2, Insightful)
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: (Score:3)
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.
No big rewrite necessary (Score:3)
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:Rewriting Would Be a Mistake (Score:5, Insightful)
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: (Score:3)
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, succes
Re:Rewriting Would Be a Mistake (Score:5, Insightful)
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: (Score:3)