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

[Anonymous Coward]

Maybe?

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

[Anonymous Coward]

Oh god yes! No null pointers! Hallelujah!

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

[Samantha Wright]

Perhaps you have to create a tag expressly labelled "end"? Like a constant or something. Null±1.

Re:No null pionters

[K. S. Kyosuke]

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?

You've said it yourself, haven't you? Rust is supposed to support union types.

Re:No null pionters

[somersault]

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

[DragonWriter]

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?

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

[Anonymous Coward]

I thought that null pointers are necessary in order to terminate a linked list.. How else can one terminate a linked list other than creating a tag labeled "end" ?

If you recognised another way of doing it then how could you have possibly thought that null pointers are "necessary" to do it? This makes no sense. The idea that in order for a language to be able to handle linked lists that it has to support null pointers is patently absurd.

Re:No null pionters

[rev0lt]

Let's call it a stream and have the last element point to the head of the list. No null pointer required.

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

[DragonWriter]

thought that null pointers are necessary in order to terminate a linked list.

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.

How else can one terminate a linked list other than creating a tag labeled "end"?

A tag labelled "end" doesn't have to be a null pointer; using the former for the latter is convenient in languages which don't easily support tagged union types, since then it allows you to use something that appears (to the type system) to be the same type as is used for real references but which can be distinguished from real references in conditional tests.

If you have a good enough type system, you don't need null pointers (and the dangers that they bring) to serve in this role.

Re:No null pionters

[somersault]

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

Re:No null pionters

[mcavic]

How would you know when you're at the end of the stream? Or, what happens when it's empty??

Re:No null pionters

[billcopc]

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 invoke something on that object.

Example:

byte[] myData = HTTP.get("http://slashdot.org/blah").getBytes();

If the get() call returns a true Null, the subsequent getBytes() will throw a Null pointer error. Either you try-catch that block, or you crash.

If instead the language uses empty objects, calling getBytes() on an empty object would simply return an empty byte array. myData = byte[0]. Still perfectly valid code and you could simply check that the size of myData is greater than 0, as a crude yet effective error check.

Re:No null pionters

[mcavic]

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.

Re:No null pionters

[Anonymous Coward]

I've never seen c++ as an attempt at best of both worlds..

It's the power of c with some stuff added to make it not absolutely painful for non-trivial projects. It's not close enough to a high level language to imo be considered an attempted middle ground, more like as I said, a slightly higher level c.

Re:No null pionters

[rev0lt]

if element->next == head, is last element. An empty list can be implemented in multiple ways, as a "not yet initialized" structure, or a single item pointing to itself.

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

[DragonWriter]

There would be no good way to differentiate the "end" tag from real data.

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

Or you could use Null instead of being a Java idiot. That's what the OP is probably wondering about. There is no advantage to this except to protect dumb programmers from themselves.

Re:No null pionters

[0123456]

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

[xouumalperxe]

You remember a specific implementation of a linked list. In Lisp, for example, linked lists are simply pairs. the list a,b,c,d,e,f would be (a, (b, (c, (d, (e, f)))). the head operation is simply getting the first component of the list, the tail is getting the second element. Absolutely no need for nulls.

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

[Anonymous Coward]

MOD PARENT UP

Re:No null pionters

[egomaniac]

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 holdout of non-type-safety, and it needs to go.

Re:No null pionters

[anonymov]

> 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

[0123456]

"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. Then it happens. Then your program does something completely inexpllicable because that code was never properly tested and a null pointer makes no sense and the code which called the function with the null pointer receives an error return from that function that it never expected to see and follows some default path that was never properly tested because it would never happen.

In some cases, an instant crash _is_ the correct response... better to restart the program that continue running in a state that should never happen and has never been tested.

Re:No null pionters

[GreyWolf3000]

Why not define a singleton object and call it "Null" or "Nil?"

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

[Anonymous Coward]

The exception will propagate and crash the application, or otherwise you will have handled the exception and there is no reason to crash. Tell me how is this worse than the program crashing? If your response includes "the state is probably corrupted", then you wrote your catch block wrong and that's not a problem due to not instantly crashing.

Re:No null pionters

[Waffle Iron]

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

[DetriusXii]

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

You can use the Maybe monad to terminate things. case Some(x) => x case None => doNothing() The Maybe monad is type safe and forces the developer to handle nonstandard expectations. When used as a return value, it also specifies that the developer should handle when the function didn't break.

Re:No null pionters

[anonymov]

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 what possible" or "ask user for intervention".

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

[anonymov]

Why the hell do you write and deploy code without testing?

It must be real hard to write "class TestBlah { blahblah testNPE() { somefunction(null) shouldBe blah } }", yeah.

Re:No null pionters

[Waffle Iron]

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

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

Lisp let you create a null value, and it didn't stop you from feeding it into a function that couldn't handle it, and it raised an error. That's exactly like every other language that has nulls.

Re:No null pionters

[Artraze]

Please explain how exactly a compiler catches the issues I mentioned:
1) Infinite loop over a circular linked list
2) Returning an invalid/sentinel value
3) Exceptions

Those are what you're trading NULL for. Removing NULL doesn't remove having to deal with the finite nature of lists or bad data. Theses things that create NULLs will still exist and won't be dealt with by any compiler because they are part of the definition of how the program is supposed to function. For all the compiler knows maybe you're supposed to spin through a circular list while a thread injects items.

I already pointed out that removing NULL can provide some security benefits, but in terms of that _plus_ stability and hard-to-find bugs eliminating arrays and other pointers would do more than eliminating NULL. (About the only significant area where NULL is worse is in C/C++ where dereferencing NULL undefined, but that's a story for another time.)

And this is why some applications are actually moving _away_ from static typing. (See Objective C and Microsoft's DLR, among others.) Static typing, especially in large projects, carries with it a great many things like complex inheritances, generics, casts, and just other boilerplate all allowing for all kinds of that the compiler is simply unable to detect. People are finding that the flexibility and style of dynamic languages offset those bugs created by the lack of static typing.

There is so much more to programming then just matching types or catching NULL... Some of the last few bugs I fixed were one subtly occurring in 32bits, not 64, a configuration option not being honored, and lastly, a negative array index. None helped by types or the compiler, and none related to NULL pointers. If the only bugs I ran into involved NULLs, I would be happy^Wout of work.

Re:No null pionters

[ifrag]

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.

I've heard that static analysis tools can spot points in C/C++ code where the potential for this exists. So assuming those tools are in use and reliably accurate, it's pretty much a non issue either way. End result is probably just a lot of "if (ptr != NULL)" getting splattered all over the code, which probably should have been done in the first place. And yes, the tool will likely have some false positives, but relying on assumptions and known program flow really isn't worth omitting the check anyway. Not like its burning dozens of cycles or anything.

Re:No null pionters

[Creepy]

I think what you are referring to is commonly called dynamic typing (establishing the type of an untyped object at runtime). For example, in objective-C untyped objects use the "id" tag instead of int or float or whatever (static types - set at compile time). In C++ this is functionally equivalent to using a template and then using dynamic_cast to identify that type during runtime (which, unlike static casting, doesn't actually change the value, it just identifies what type of object the value is).

I remember writing and endian flipper for float and it was worlds simpler with untyped objects (in C I had to make this a tagged union, flip the bytes as an int, and then assign it to a float, whereas in Objective-C I just use id and call them ints when I do the byte swapping and after that use it as a float).

Re:No null pionters

[ifrag]

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

Minecraft catches them and does something (gives a program internal error message about it), but I'm not entirely confident about how "graceful" it actually is. I would expect data loss would be the preferred outcome compared to full DB corruption.

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

[anonymov]

1) Infinite loop over a circular linked list

How does NULL help here? If the bug is creation of circular linked list in the first place, proper answer is "don't let programmer tweak head/tail pointers", which is handled alright by making them private. If you want to be anal, you can even formally verify list building algorithms to forbid possibility of circular references.

2) Returning an invalid/sentinel value

If the invalid/sentinel value is not a member of return type - it's a compile error.

3) Exceptions

Exceptions are by definition run-time - though compiler can help here too by pointing out places you should catch them. If you're talking just NullPointerExceptions - compiler'll tell you where you are possibly dereferencing a null.

Re:No null pionters

[Requiem18th]

Mathematically speaking. A list of type <A> should only contains elements of type <A>. Null is not type <A> so it doesn't belong there to begin with. Of course a sentinel value like "NullListElement" doesn't actually reflect the intent of the program, and conceptually it's pretty bad too.

The real WTF here is that we are talking about implementing linked lists. This is a solved problem and nobody outside college should spend anytime implementing them again.

Re:No null pionters

[somersault]

If you used a null that matches with any class, you're back to the start. What's the point in that? I assume that getting rid of a universal null has something to do with stronger typing resulting in less chance of bugs, but I'm not very up on my language design theory tbh.

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

[Requiem18th]

The problem isn't null per se, but the fact that they are out of place in an statically typed language without union types. Even then the niffty thing about union types is that the compilers prevents you from calling methods on them untill you deunionize them. You can make, for intance, a C++ compiler that always checks if an object could be null before calling operations on them. It helps if it gives you a nice syntax to deunionize them, but it's not nessecary, but you still need union types.

A simpler alternative, used in C# is to use "Nulleable" types, that is, an specific kind of union types that only consider the null case, in other words "Either an X or Null". So in C# you can say:

int? foo;
From there you can do anythig you want with foo unless they are int operations. You can return it, pass it around, whatever. But before adding or substracting it you must check for type first.

Re:No null pionters

[Artraze]

> > 1) Infinite loop over a circular linked list
> How does NULL help here?

Indeed, if circular is what you really want, then certainly NULL doesn't come into it.

So why bring this up? Well simple: it's a solution to the the original question in a statically linked environment. See, each link must have a reference to some data and the next link. The trouble is that the next link cannot be NULL and must point to a valid link... But where does that link point? Well, unless the list in infinite it must point back to the first, making a circular list. (This can be solved with inheritance using a virtual GetNext() that throws and exception for the last link, which is what brings us to point 3.)

> > 2) Returning an invalid/sentinel value
> If the invalid/sentinel value is not a member of return type - it's a compile error.

Think harder. A linked list has links: references to the next object. If that reference is statically typed and not NULL, it must be a valid object of the same type as every other member of the list. That's what this static, non NULL typing is all about after all! All references _must_ point to a valid object. So, this end reference could be a circular link (as point #1) or a sentinel object as mentioned here. Regardless, it's a real object of the same (base) type as the rest of the objects in the list so the compiler will have no issue with returning it. You have to manually check that it's the end (even if it's an up-cast, it would still need to be dynamic), thus my point.

Similar to #1, a link interface with a GetData() that throws an exception (and, of course, no actual underlying reference) is a possible solution to this. But, again, that's not actually something the compiler handles for you and we end up at #3 once again.

> > 3) Exceptions
> Exceptions are by definition run-time

And this is exactly my point. You spend all your time working around the compiler, dealing with #1 and #2, just so you can end up here: a place that is, /by definition/, something the compiler cannot help you with. So despite eliminating NULLs and statically typing our language, we still much manually manage the list or face an error condition. Except _now_ rather then just checking for NULL, we must create a link interface, a real implementation, a sentinel implementation AND catch exceptions from the last just to know we're at the end. Win?

Re:No null pionters

[Goaway]

Requires extra memory reads that a NULL pointer terminator does not, so it is less efficient.

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

[Darinbob]

You don't need a null pointer for that, you need a 'sentinel' object. Linked lists can be created without pointers too...

Re:No null pionters

[Darinbob]

Also note that a null pointer is not necessarily a bad pointer. You may have a valid object at address 0. On some machines it may even be better to use 1 or -1 as the null pointer as it will crash when you try to dereference it.

Re:No null pionters

[hazah]

And then some...

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

[anonymov]

Not for a singleton terminator object, there you get just a comparison to a constant, +- same as with NULL (which is just a singleton bottom type)

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

[Samantha Wright]

Well, they have dynamic typing as well (the let keyword introduces a new variable and type is inferred from context), but this is actually a type (option<T>, where T is a normal type such as int) that is allowed to contain either a special nil value or a value of type T. This extra semantic sugar lets the compiler know what should and shouldn't be possible.

Re:No null pionters

[Anonymous Coward]

Null pointers are reluctantly allowed in 'unsafe' blocks:

http://doc.rust-lang.org/doc/tutorial.html#pointer-fiddling

Re:No null pionters

[kcitren]

Sentinel objects? Default NO-OP objects?

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

[Goaway]

You still need to load the address of that singleton, which is still slightly slower than a zero check.

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.

Re:No null pionters

[somersault]

I hadn't heard that term before, no. But apparently anything which terminates the list is a sentinel, it doesn't have to be the list itself.

Re:No null pionters

[Anonymous Coward]

That's a problem with your Comp Sci 102. Null pointers are a thing used in programming languages such as C to represent a missing value. In a proper language, you do not have null pointers, but algebraic data types, a linked list thus looks like:

        data List t = Pair t (List t) | Empty

And a binary tree of integers looks like this:

        data IntTree = Branch Integer IntTree IntTree | Leaf Integer

Alternatively, you also have Maybe types which can hold a value or nothing, and which are similar to the approach chosen in languages such as Vala, C#, and apparently rust.

Re:No null pionters

[DuckDodgers]

We can beat this to death. There are arguments on both sides. I get paid to use Java (yuck) and frankly the compiler does catch a whole class of potential problems before I have to worry about catching them with unit testing or QA testing. But just as often our problem comes from mis-configuring our data layer, or a typo in a configuration file, or forgetting to put an HTML form variable that's required into a page, or missing some required information in the database. All of that blows up in your face at run time, and the compiler can't help at all. You have to catch that with unit tests and QA testing, and that would be true no matter how type-safe your programming language is.

But there is value in reducing the possible universe of run time errors by having the compiler check your code for correctness before it gets run. Even if it does not protect you from all possible errors or even most possible errors, it protects from some and that's nice. You just have to weigh the added work of static typing versus the added work of unit testing to cover dynamic typing. My personal opinion is that some languages - including Java - have an overly verbose and complex type system that makes the static typing generally not worth the effort. But I've tinkered with, for example, Scala and D and their type systems are much more flexible and less verbose. There are also languages like Perl6 (if any of the implementations ever hit 1.0) which has default dynamic typing but optional static typing, for a best-of-both worlds.

Re:No null pionters

[Anonymous Coward]

How else can one terminate a linked list other than creating a tag labeled "end" ?

Perhaps you point it back to the first element in the list and call it "Ouroboros" :)

Oblig XKCD!

[Anonymous Coward]

http://xkcd.com/865/

Re:Oblig XKCD!

[Jeng]

Bah, trolls just aren't what they used to be.

http://xkcd.com/318/

Re:Oblig XKCD!

[Anonymous Coward]

This bot sucks because it always posts the same xkcd.

The correct answer is http://xkcd.com/927/

Sure way to attract developers

[Anonymous Coward]

Use a language with no existing user-base.

WTF are these people thinking!?!

Re:Sure way to attract developers

[K. S. Kyosuke]

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

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

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:Sure way to attract developers

[Anonymous Coward]

Well, you could do that with Forth...but you don't see anyone rushing out to code in one of my Pet languages...

Re:Sure way to attract developers

[Bill_the_Engineer]

Sounds like a familiar trap: Inner-Platform Effect

Re:Sure way to attract developers

[Anonymous Coward]

I hope that is a joke. To a developer it's a joke.. I just hope the poster thinks that too.

Re:Sure way to attract developers

[beelsebob]

Thank you for that, it's a beautiful way of describing something utterly horrible. But I don't see how it applies either to my comment, or to what mozilla are doing.

Re:Sure way to attract developers

[Bill_the_Engineer]

It has everything to do with what Mozilla is doing. They believe they can make an language that better suits their needs, in the process they waste time and effort creating a language that may only be marginally better than the language they already have (or already exist) and to make matters worse has a significantly less number of developers that know how to use it.

Re:Sure way to attract developers

[beelsebob]

That's not what the inner platform effect means though.

The inner platform effect would involve them writing a DSL based in C++, and then expanding the DSL to be a poor copy of C++. This is simply saying "C++ isn't what we need, lets choose something different... Oh, nothing seems to suit our needs just now, lets write something that does."

Re:Sure way to attract developers

[K. S. Kyosuke]

then why aren't they thinking that codifying their common code problems in the existing language won't help?

Why did the Unix guys invent C and didn't continue using a macroassembler and coding conventions instead? Why did Stroustrup invent C++ and didn't use the C preprocessor and coding conventions instead? Sometimes you have to change your habits.

Cool name

[K. S. Kyosuke]

Get rid of bit rot and get Rust instead? ;)

*Sigh*

[Anonymous Coward]

The other guy ALWAYS has the better gun.

They no longer need developers, it seems..

[goruka]

With their constant refusal to keep up to the usability, performance, security, and innovation of other browsers it seemed to me that Firefox developers didn't care much about getting new users (they lost quite a lot in fact). Now, it seems they don't need developers either, because how many will be willing to learn and get proficient in a new, complex programming language just to contribute to a project?

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

[Microlith]

With their constant refusal to keep up to the usability, performance, security, and innovation of other browsers

Really? How is any of this true?

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

[Anonymous Coward]

Now, it seems they don't need developers either, because how many will be willing to learn and get proficient in a new, complex programming language just to contribute to a project?

The ones that are being paid to do just that? Seriously, was this a trick question?

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

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

[JasterBobaMereel]

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

[0123456]

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

[Anonymous Coward]

To paraphrase Linus Torvalds:

Quite frankly, even if the choice of Rust were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use Rust.

Now they just need a language that will keep the Javascript programmers out, and one that will keep away the people who want to rewrite everything in a new language all the time. I suggest COBOL for a two-in-one!

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

[Anonymous Coward]

It's syntactically concise, yet relatively intuitive. The reduction in use of parentheses saves some typing. But I winced when I saw "let result = 1". It brought me back to my introduction to BASIC programming on the Commodore 64, where variables could optionally be declared with the keyword "LET". I don't think I ever used "LET", as it served no purpose whatsoever, and just annoyed me when I saw it in use. I'm telling the computer that "result" equals "1", not asking it to allow that to be true.

Just a childhood pet peeve brought back to life. Certainly not a reason to avoid the language.

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

[Anonymous Coward]

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

Security is not a product, it is a process. (c) Unknown.

Even the best security minded programmers might fuck it up royally - without proper testing, review and maintenance processes.

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

[Anonymous Coward]

Well then I, for one, am glad that a company that actually produces shit for the real world is controlled and funded by a non-profit that receives millions of dollars of free money from one of the world's largest companies is interested enough in studying the current languages to find their flaws, and then researching and developing a new language that learns from the history of current languages and makes it easier to develop complicated applications that will be used by real people, and then is so wonderful that they release their compiler as open source to grow the base of knowledgeable programmers so the whole programming world can be made a little bit more discoverable and efficient.

But, that's just me. Feel free to hate something before you have thought about the motivations and consequences of it.

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

[somersault]

Hence why it's a good idea to try to make that process easier with languages that make it harder to make common mistakes. Nothing has replaced C++ so far, but that doesn't mean that nobody should even try to develop more usable languages.

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

[Samantha Wright]

I agree that it's weird. Usually when people get violently upset about the confusion in semantics between assignment and equality, they go off and do something like invent := or ==. A let solution, by contrast, is a lot more verbose. Of course, it's still an expression in Rust (IIRC from this morning), not a hard-and-fast statement, so like some twisted abomination of Algol-60 (as is the case with the rest of the language) you can still stick it inside of things... that, BASIC would never let you do.

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

[Samantha Wright]

I think a serious conceptual assessment needs to be made about the merits of a platform before necessarily falling back on arguments derived purely from sound engineering principles. It's true those things can't be ignored, but if no one ever went out on a limb to see what was on the other side, we'd still be using Fortran, assembly, and COBOL for systems implementation. Rust has some very clear strong points (like concurrency) which definitely have potential advantages to a project like a web browser. Conservatism in a development environment won't lead to good results if it's not tempered. I'm pretty sure that Rust still uses the normal gcc backends for compilation, so it's not as if we're losing all of that experience either.

Really and seriously, I think you're over-estimating how much can be blamed on the language. From a language specification perspective, unlike Ruby or Dart, a lot of attention has gone into giving this rigorously described semantics based on modern computer science. It removes some of the sharp edges from the C family, gives an excellent collection of safety knives, and adds a lot of useful innovations that are still a pain to implement in those more primitive environments. I would guess that the majority of errors come from stalwart C++ developers who are too used to their way of doing things to consider Rust's semantics, or seek out a potentially better approach because it's conceptually unfamiliar.

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

[Samantha Wright]

Wait, clarification: the "LET" keyword is only used for declaration of local variables. In BASIC it could be used for any assignment.

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

[Desler]

That sounds all well and good, but where's your real world results to show to us? Yes, one should always attempt to improve the state of things but dumping mature technology for untested and unproven solutions is asinine. Get back to us when some nontrivial software that can prove the claims of the designers has been written. Until then, no thanks. I have real work to do with no time to waste on something that as of right now is a toy language.

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

[DragonWriter]

agree that it's weird. Usually when people get violently upset about the confusion in semantics between assignment and equality, they go off and do something like invent := or ==.

In Rust, "let" doesn't distinguish assignment from equality, it distinguishes local variable declaration from assignment.

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

[anonymov]

Well, it's a good thing nobody speaks about dumping C++ for rust-0.1 then! Seems like they're putting it out for enthusiasts to play with, provide feedback and assess it.

But isn't it a nice Catch 22: "To get a language accepted by serious project, show us a serious project written in this language". Good thing not everyone is so busy and serious as you, or we'd still be writing in assembler.

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

[Samantha Wright]

I noticed already. :)

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

[Samantha Wright]

You sound like you have a serious axe to grind. Care to share what's really under your skin?

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

[VortexCortex]

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.

So is Visual Basic.

Best of luck,
Cheers!

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

[Eli Gottlieb]

There are millions of qualified ditch-diggers in the world. What do you need bulldozers for?

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

[DuckDodgers]

Really? Tom's Hardware Guide does comprehensive browser comparisons every few months, and Firefox won the last two of them after years of being outdone by most of the competition. Have a look: http://www.tomshardware.com/reviews/macbook-air-chrome-16-firefox-9-benchmark,3108.html and http://www.tomshardware.com/reviews/firefox-7-web-browser,3037.html Firefox still has more extensions than any other browser and in April they're planning to switch to the Chrome deployment model of auto-updating in the background without prompting the user to apply updates and bug fixes every few days.

I'd say their usability, performance, security, and innovation are top notch.

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

[DuckDodgers]

Hear hear. If you don't like Rust, don't use it. The free software developers who don't feel like learning Rust don't have to contribute to Firefox. Big deal - it looks like it's close enough to C++ that the learning curve will be a matter of days for any good C++ developer. Someone unwilling to do that isn't worth having on your team anyway.

Re-write software?

[Anonymous Coward]

I don't think they will re-write a software as big as firefox in another language... I'm remember a post on slashdot that the build was so big it could not compile on some compiler/environment.

It will be a huge time waiste and will just put firefox way behind the line against the other browser (IE, Chrome, Safari, Opera) that will be spend time on feature rather and re-write the code.

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++

[Anonymous Coward]

Assembly is not "as fast as C++", it is faster :-)

Also ... standard C.

Re:ultimately as fast as C++

[xorbe]

That's not a high-level language.

Re:ultimately as fast as C++

[Anonymous Coward]

Microcode?

Re:ultimately as fast as C++

[Anonymous Coward]

Unless you have OO constructs in your macro framework...no.

Re:ultimately as fast as C++

[Anonymous Coward]

Only if you know what the hell you are doing... You can write crap in ASM too...

Re:ultimately as fast as C++

[GreyWolf3000]

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

Re:ultimately as fast as C++

[Anonymous Coward]

A lot of us would argue that C++ isn't a high level language either.

Re:ultimately as fast as C++

[Anonymous Coward]

Well, Both Haskell and Ocaml are somewhere between C++ and C in speed, and the both aren’t remotely as retarded as any C-like language.
Using a C-like language today, is like lighting your house with "the most modern" oil lamps and having a horse carriage shop "to get rich".

Of course the common fallacy of "It's the best language I know (Because I willingly ignore any others that I don’t know but might be better.)" means this will instantly get modded down to "-1, Don't call out my fallibility!". But it's nonetheless true.

And I wouldn’t judge C++ and C too, if I hadn’t used them every work day for over 10 years.

Re:ultimately as fast as C++

[Anonymous Coward]

Fortran always has and always will smoke C++.

Re:ultimately as fast as C++

[aaaaaaargh!]

Just as a side note, C++ is not fast because of the language itself, quite the contrary. It is fast because existing C/C++ have been optimized extensively -- more than any other compilers. There are in fact many ways to break type-safety in C++ that hinder optimization a lot.

Re:ultimately as fast as C++

[Darinbob]

VHDL?

Re:ultimately as fast as C++

[Just Some Guy]

Assembly is not "as fast as C++", it is faster :-)

[citation needed] Recent C/C++ compilers churn out code that runs as good (or better) on a modern out-of-order, superscalar processor as code hand-written by almost any human. Things might get a little dicey when legendary coders are thrown into the equation, but those guys are few and far between by definition.

Re:ultimately as fast as C++

[Anonymous Coward]

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

C isn't that. The OO in Linux is in the programmers' heads and their discipline. In C you impose discipline upon yourself, put some conventions together and keep to them like they're holy. If you can't do that, you write C++, Java, C#, and what else.

This Rust thing looks like just the thing for undisciplined programmers while speeding up development for disciplined programmers while also being a frigging compiled language, not an interpreted one - looking at you Ruby and Python.

Oblig Neil Young

[Anonymous Coward]

~~Rust never sleeps~~.

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?

[Svartalf]

Heh... They keep thinking they've got a better answer, when in fact, all they have is a different one in most cases.

Re:Another compiler? Seriously?

[Anonymous Coward]

Every sufficiently mature project levitates towards implementing its own DSL. Yet another language is just a natural development of the framework.

Re:Another compiler? Seriously?

[Yvan256]

There's no need, by the time this article has been published on Slashdot, they've already released upgrades up to Rust 4.2.

Re:Another compiler? Seriously?

[Darinbob]

Because C++ has too many talented and skilled contributors who write bloatware? The best C++ programs are the ones that look the most like C with a few extras.

Re:Another compiler? Seriously?

[Anonymous Coward]

Life would have been so much better if we just stuck to the trees and eating bananas. Such a relaxed life. No more wars, no more corrupted governments, no more terrorists.

Ah, yeah. That's a nice thought.

Re:Another compiler? Seriously?

[Anonymous Coward]

There exist very few languages targetted at the same niche as Rust which is safe C-like languages. Rust is the only one I have seen that looks like it might actually be usable. As far as I can tell, the only reasonable competitor is C++ written to a safe coding style (i.e. using safe pointer types, etc.). Rust is simpler than C++ and the compiler is able to automatically isolate the sections that aren't memory safe using the unsafe keyword (sorta like in C# except Rust supports lower level safe operations). Also, Rust isn't an OO language. You never have vtables (all function calls are dispatched statically) unless you explicitly cast to an interface.

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.

Re:Another compiler? Seriously?

[WuphonsReach]

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.

It's pretty much an indication of either:

NIH (not invented here)

or

Our organization has grown so dysfunctional that we're branching off into dozens of directions outside of our supposed core focus (i.e. the web browser & mail client). In this particular case, we're going to chase the wild herring of creating our own language because we can't be seen as "cool" if we use an existing one that accomplishes the same things.

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:Wonderful!

[rawler]

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)

Re:Wonderful!

[DragonWriter]

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.

The language isn't a may/may not, its an "absolutely won't" fix things -- on its own.

A new language only fixes anything in an existing codebase as part of re-thinking their code base. OTOH, if, as part of rethinking their code base, they've found extensive recurrent problems where the solutions in the existing implementation language are cumbersome, using a new language where doing it right is more straightforward than in the existing implementation may be appropriate.

Re:Wonderful!

[DragonWriter]

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)

Its loosely similar to Go, but at least as different from Go as Go is from other languages which attempted to address the same concerns that predate Go.

The similarity is not surprising, Go is an express inspiration for some of Rust's features, and other features are inspired by some of the same languages Go drew inspiration from.

And competing languages in the same general space leave room for different decisions to be tried and prove themselves in practice, which is important.

Re:Wonderful!

[ChrisMaple]

Mozilla claims that poorly written addons are responsible for almost all of the memory leakage. I can get firefox to crash every couple of hours if I use the "vocabulary highlighter" extension, so it's easy for me to believe that leakage flaws are mostly not in mozilla's own 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"

[0123456]

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?

Re:A tag labeled "end"

[kripkenstein]

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: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:A tag labeled "end"

[0123456]

"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:A tag labeled "end"

[Samantha Wright]

That's pretty much what Rust does. There's a special union type called an option, which can be of type T, or undefined.

Re:A tag labeled "end"

[Anonymous Coward]

It can't crash due to a null deference if there are no nulls in the language. But, you can have incorrect behavior of course - no language feature can prevent bugs. You can though prevent some types of crashes by disallowing nulls - so it's a good thing to do.

Re:A tag labeled "end"

[Anonymous Coward]

I don't understand why idiots like you have to comment on matters you know nothing about. The whole point of an optional type, is that you must deunionize them before you can use it. (Or in your language, you'd have to have a explicit check that it's not null, before you can use it). So no, they don't crash -- cause you can't just references them.

And even if what you said was correct (which its obviously not), it would *still* offer an advantage -- namely that things that are nullable have been explicitly marked so. (Unlike Java, where potentially any reference type might happen to be null)

Re:A tag labeled "end"

[Bengie]

Most OSs never map 0 to userspace, so any null reference will just cause an access fault.

At least using null as a reference/point means you don't need to actually check said memory location to see if it's "null". You just look at the pointer/reference and said "hey, it's null, that means it's not referencing anything." compared to "The point says 0xDEADBEEF, lets go there.. twiddle thumbs while loading the memory location... lets check to see if the "null" boolean value for this object is set... ohh, it's "null" so lets ignore it"

Great, now you need extra memory loads and you're doing the same F'n check. You gain nothing, but you lose something.

As Fast As Cee

[tepples]

One of the goals set out in the Rust is to eventually be as fast as C++. Many have tried such. How much space and time overhead would such a union type incur compared to the maybe type that is the C++ pointer?

Re:As Fast As Cee

[K. S. Kyosuke]

I think the right question is whether Firefox written in Rust given an allotment of resources (people x hours) will be slower, as fast or faster than Firefox written in C++ given exacrly the same resources. Ordinarily, choosing a high level language gives you more breathing space as far as algorighms and the general program design is concerned - you have more time to play with if you don't have to hunt stupid bugs caused by the inadequacies of the legacy language. Mozilla will have one more benefit: If they find out that they keep using unions so often that their performance impact is noticeable, they can tweak their own compiler implementation. In the end, the resulting binary code could actually use nulls (as unitary alternative values for all disjoint unions), but only after the compiler checks it and deems it OK.

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

I like the shortened names

[Vektuz]

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

c++ version of scala & haskell

[Anonymous Coward]

Basically looks like it is to c++ what scala is to java, with a load of Haskell thrown in too.

Great

[jcreus]

Now we will have 1000002 different programming languages (final 2 so that Slashdotters understand it's not binary). And an obligatory XKCD reference.

Re:Great

[AndOne]

Oh sure you've ruled out binary and unary, but you haven't eliminated ternary, hex, octal, and just about any other counting system. Won't somebody please think of the Slashdotters!

Rewriting Would Be a Mistake

[MichaelBuckley]

The Firefox codebase definitely has some huge issues, but does anyone remember the big Netscape rewrite for version 6? Joel does. http://www.joelonsoftware.com/articles/fog0000000069.html

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:Rewriting Would Be a Mistake

[DragonWriter]

It also beats me why they thought a new language is the solution

They don't. They think that a new language may be part of a solution, in the fairly long term.

Re:Rewriting Would Be a Mistake

[Anonymous Coward]

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.

This is far more ludicrous than Joel's advice (which I think is sound). None of those are examples of companies deciding to junk a large codebase and rewrite everything from scratch. OS X was pretty much OPENSTEP, which was proven and rock-solid by the time Apple acquired it from NeXT. NT and DOS evolved in parallel, with DOS being fully retired years after NT was first released. DOS was still the "kernel" for Windows 95, 98 and ME.

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.

I disagree. Gradual, evolutionary changes are indeed excellent ideas when appropriate, but junking a large, working codebase and starting again from scratch (which is what Joel was talking about) is a stupid idea. Always.

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.

Look at what happened to their market share while they were busy rewriting it. Eventually, it did become a successful but quite distant runner-up.

Re:Rewriting Would Be a Mistake

[Dr. Spork]

I think that you're more right than wrong, but you too have to admit that the conclusion depends on the specifics of the case. When you have code that's an unsupportable mess and you want to bet your company on it, a rewrite may be unavoidable. But just because you rewrite doesn't mean that you have to scrap the old code immediately. You can do it like MS did with NT: Do a rewrite with the full intention of eventually transitioning everything to it, but let the code age for 10 years before you actually pull the trigger on the transition. Also, keeping old code is much easier when you wrote it in a modular way. If you didn't, a re-write might be worth it in the long run.

Re:Rewriting Would Be a Mistake

[Timmmm]

There's only so much you can do with a "solid class library". And there already *are* solid class libraries -- or do you think you could do a better job the your predecessors?

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.

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.

Re:Wash it in some alkali

[owlnation]

Why not wait until 1.0 is ready before announcing it?

I'd guess the announcement has to be now, because even with the fastest of viral marketing, the word will take longer to get out there than it takes for Mozilla to get from 0.1 to 1.0 -- which should probably be next Tuesday at the latest, knowing their preposterous update frequency.

Mozilla: moving sideways and treading water since 2005.

Re:Wash it in some alkali

[DragonWriter]

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.

Most of the languages I've learned, I didn't have anyone teaching me -- just an implementation and some written reference material.

And 0.1, meaning it's currently unusable. Why not wait until 1.0 is ready before announcing it?

Uh, because something doesn't get ready for production use except by people bashing on it, and that doesn't happen if no one knows it exists. So, generally, software products -- and especially open source ones -- are announced (and available to use) well before there first production-ready release.

Re:Wash it in some alkali

[Timmmm]

Oh great - just what we need - yet another programming language

Not all languages are the same. Maybe your criticism is valid for C# / Java, but the other languages you list are all pretty different. Rust has some features, and certainly a unique combination of features (e.g. modern, and not garbage collected).

there ain't enough people to teach kids and adults the languages we already have

Well you don't actively need teachers to learn a language (tutorials, books, etc), nor do you have to learn every language in existence.

And 0.1, meaning it's currently unusable. Why not wait until 1.0 is ready before announcing it?

Maybe so interested people can follow its development, make suggestions, help write the compiler and so on?

That too w/ such an inspiring name as 'Rust'.

Jesus Christ who spat in your face this morning? Why are you such a pessimistic parade-pisser?

Re:Wash it in some alkali

[VortexCortex]

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

Ah, well, clearly what we need is a more user friendly language that's easier to teach, mostly full featured, can be complied to machine code, byte code or interpreted, and comes with a FLOSS redistributable runtime that supports multi-media, images, sound / music, Hardware Accelerated 2D & 3D.

Hmm, it seems nothing short of a Scriptable Open Source Game Engine would be required to provide the feature set...
If only children actually liked GAMES I could simply leverage a Game Engine to provide a compelling environment for learning by way of modifying existing "example" games... I think I'll call this new teaching model "Community of Modifying", hrm, or perhaps "The Mod Community".

-- Oh, wait, the problem isn't that there's not enough teachers, it's that people don't want to program no matter how compelling you make it. I mean seriously, snag ANY Game mod platform (even Doom has Scripting now) and you get a full featured dev platfrom with instant gratifying rewards. Besides, EVERYONE has a fully capably JS dev platform installed already. The fact that MANY games invent their own scripting language hasn't stopped TEN YEAR OLDS I know from modding & scripting for multiple games at once.

Consider that we have an adequate number of skilled programmers already, those that wish to learn many languages do (I'm proficient in EVERY language you mentioned and More, and have never attended any formal education whatsoever). Consider the reality of the situation is that many people would like to have all the benefits of being a programmer with none of the investment that requires -- They like the Idea of learning to code, more than actually learning it.

I see this every day: "How do I get into programming? I want to create ____, its going to be Awesome! " [explain, provide help] "Uhg, this is hard, never mind". Few actually take to the task and stick with it, some take to it as a fish to water, most just aren't cut out for it.

Additionally, If you think introducing new languages is bad, I'd argue that there's a reason we're not all still developing using COBOL and FORTRAN or platform dependent Assembly.

I'd say you're going against nature itself. Look about at all the variety of life in the biosphere we're a part of, then tell me evolution and natural selection has no place in computer science.

Re:Wash it in some alkali

[tlambert]

Oh great - just what we need - yet another programming language

Not all languages are the same. Maybe your criticism is valid for C# / Java, but the other languages you list are all pretty different. Rust has some features, and certainly a unique combination of features (e.g. modern, and not garbage collected).

Sorry... failed to read the article?

"Rust GC is optional and per-task"

This is the same bill of goods Objective C recently sold us... the cake is a lie.

The problem with optional garbage collection is that someone "optionally" depends on it in their library, and you are stuck turning it on for everything thereafter you link with that library.

Then memory leaks happen in other code, but the garbage collector spackles over them, and now suddenly because it didn't crash over the leak, you now have more code addicted to the "optional" garbage collector.

Eventually, you give up, and buy into garbage collection being a necessity rather than the pretend "optional" you started out with, and you forget how to scope variables or use explicit retain/release interface, or forget that there was ever such a thing as explicit memory management.

By then, it's too late, and your code is suddenly all crap, and you're now stuck programming in user space.

-- Terry

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.

A special tag

[warrax_666]

A special tag is not type-compatible with every other single value in the language.

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.

5 years?

[Anonymous Coward]

So 5 years for 0.1 I look forward to version 1.0 being released 2062 ;)

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

Ok, I give up

[TheDarkMaster]

Okay, I'm lost in this one. If the goal of the new language is "to be as fast as C + +", so why not just use C + +?

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:Ok, I give up

[Anonymous Coward]

Languages are becoming more and more high level. Java doesn't expose you to pointers. Ruby, Python, and Groovy are all objects and pointers, but the person writing the code never has to deal with a non-pointer object. Even Obj-C makes you use pointers for everything.

We're at the point where knowing how to master pointers and their ilk isn't as important as it once was. So many things that you could only learn in C++ by reading extensively (or shooting yourself in the foot) have been removed or simplified in modern languages. A large chunk of any program today can stand to be written in a higher level language that doesn't require the technical knowledge of yesteryear. Of course, there are still portions of a program where getting to the low level of C/C++ is needed, and languages like Rust and Ruby give you that option.

However, to shun progress simply because it has less pitfalls is silly. A good developer can learn any language, and over time develop a proficiency in it. Higher level languages reduce developer spin up time and development time at the cost of system time, and as I said before, if a certain part of your code requires speed, it can be rewritten in a faster language.

Re:Ok, I give up

[0123456]

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

Re:Ok, I give up

[mrnobo1024]

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.

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:Ok, I give up

[Anonymous Coward]

I agree with you about the problem with languages drifting from the bare metal as if it's something unpleasant and not something to dirty your mind with.

However, there's some serious, serious issues confronting people in various areas, and most of it has to do with concurrency and parallelism.

You can program this stuff in C/C++, but it gets to be a mess, and it's only going to get worse.

On top of this is an increasing awareness that functional programming has a lot of benefits, and that a modern language can be cleaner syntactically without losing performance.

I know about lambdas in the most recent version of the C++ standard, think that a purely functional approach is restricting, think that C/C++ can actually be pretty clean, etc.

However, I also think that there is room for a new performant language that addresses these issues. I'm not sure there's one out there yet. Go is nice, but the standard parallelism isn't quite there (even if concurrency is), there's still massive generics unsolved issues, and support for functional programming (which could be streamlined *relatively* easily) seems to have gone unnoticed. Scala is nice but its performance is sort of poor comparatively if you really look at it realistically, and its reliance on the JVM is limiting it severely (even if the JVM has also helped it a lot too). Haskell is underrated but also overrestrictive and not great performance-wise. Chapel is nice but really new, with an uncertain future, and they also seem to have forgotten about this whole "functional programming" thing.

I could go on and on--there's many many languages that I haven't mentioned that are even more promising in some ways, but too new.

Meanwhile, if you compare them to C/C++, even with all it's warts, C/++ still looks pretty good.

I love all these new languages, but hate the fact none of the developers seem to take all the issues facing them seriously. That's not to say they're not doing serious work, or putting serious effort into them, or that the challenges aren't immense, but there's often this dismissive attitude of "well, X isn't necessary because it doesn't interest me." Some group will be chomping at the bit to use the language in applied work, but the developers shrug off their very real concern, and the opportunity to really grow the language goes away.

The reality is that established languages like C++ have been around for awhile, and set a very very very high bar. If people want their language used, they need to take seriously what they're up against.

Re:Ok, I give up

[DragonWriter]

Okay, I'm lost in this one. If the goal of the new language is "to be as fast as C + +", so why not just use C + +?

Because that's not the only goal (or, even the most important goal), and C++ doesn't satisfy the other goals. Particularly, the "project FAQ" on the Wiki notes three common deficiencies in the available languages at the same efficiency/abstraction level targetted by Rust that motivate its design:

1. Not enough attention to safety,
2. Poor support for concurrency,
3. Too dogmatic about paradigm.

#1 and #2 are almost certainly about C++, #3 is probably mostly about the existing alternatives to C++.

I hope this solves the problem

[DragonTHC]

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:I hope this solves the problem

[noelbon70]

"Firefox doesn't have a memory" leak is the oft-repeated line. "It's your add-ons" is the next oft-repeated line. Yet with a clean install of Firefox, no add-ons, it gobbles up memory the longer you use it. Opening and closing tabs seems to be the problem, quite simply. Translated: using the browser at all causes memory leaks.

I installed the Quick Restart add-on for FF and use it 3-4 times a day, usually at around 800mb, when performance lags become noticeable. For instance, videos start getting choppy (Flash) on my MacBook Air i5. A quick restart and I'm good for a few more hours.

Re:I hope this solves the problem

[higuita]

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)

but in today machines, web technologies and browsers, all of then use huge amount of ram.

if you want a ligher browser, disable javascript, plugins and images... or use dillo3 and links/lynx

finally, your problems is really that you have little ram and cpu power... and using broken things like flash will always make things worst... try flashblock to only show the flash you want, noscript to disable useless javascript in the background that might be eating your cpu and ram

Re:I hope this solves the problem

[Ash-Fox]

Firefox is so very famous for nom nom noming all your memory over time.

I have 24GiB of RAM on my main system, Firefox is only taking 612MiB, despite having been open for almost two days now with hundreds of tabs. Why can't I reproduce these problems everyone is having on this system?

On my netbook, Firefox is using roughly the same (having been open only an hour, very few pages), the system only has 1GiB of RAM. Why can't I reproduce it eating all of the RAM on this system either?

I just don't get why /I/ don't have these problems. You'd think if it was so common I'd be having them, being someone who uses Firefox heavily.

Re:I hope this solves the problem

[noelbon70]

You must work for Mozilla :)

Yes, I'm on 9. I keep Chrome and Safari (as well as the corporate IE8 I'm stuck with) and none of those browsers have this issue. Firefox does NOT release memory after the tabs are closed, or rather, enough of them over a period of time. I can close all my tabs, as I usually do after reading sessions, leaving it back down to 1 tab open, and no matter how much time goes by, the ram stays consumed. Firefox gets pokier and pokier until I have to restart it using the add-on I mentioned, so that I can pick back up where I left off with whatever tabs I had open.

I have a brand new HP Elitebook with 128 GB SSD, I5, so it's no slouch. I also have adblock installed. It's FF, not my machine. It's done this on every Mac and PC I've had going back to probably all the early 1.0 RCs I've used.

That said, there are still too many useful things about FF that make it my default over the other browsers, so I've put up with it all these years.

Re:I hope this solves the problem

[Anonymous Coward]

Mostly good points, but there is a difference between aggressive (pre)caching and a true memory leak. I recall many of the FF 3.5 builds and several of the 3.6 builds simply eating memory on both Win2000 and WinXP. With a clean installation, you could watch its memory use consistently tick upwards like clockwork in Process Explorer while not touching it, even while the browser was minimized. Leave it open long enough and no amount of memory is enough to contain it. I had narrowed it down to some interaction between a subset of JavaScript and leaving multiple tabs open.

I went to report my findings, first looking through old bug reports to see if someone else had already reported the same thing, but I was dejected to see a lot of "works for me" and "won't fix", even for what seemed to be good reports. Once the feature of re-opening old tabs was introduced, I stopped caring - I could just re-open it anyway with all tabs intact. Before that, I would just terminate FF with Process Explorer, and it would automatically re-open the prior session. Annoying, but workable. Later in 3.6 and beyond they seem to have eliminated leaks (or close enough to it), so even less reason for me to care.

More on topic, they don't need a new language - they need to eliminate manual memory management. Using new and delete should be a rarity in modern C++ code.

- T

Re:I hope this solves the problem

[Seekerofknowledge]

Same here. I have been using firefox since the 0.x phoenix days and I can recall maybe one time, years ago, where I got bit by a memory leak. I virtually never close the browser and instead leave it open for months with a dozen tabs open, and always just sleep/hibernate the computer. Hosts include practically anything you can name, 2k-7 (32 and 64 bit), OSX (10.5-10.7), Linux (too many to recall, mostly ubuntu).

My memory usage is always great, and has been for at least the past couple of years. It definitely uses less memory than Chrome.

Who are these people and what version of FF are they using? Maybe these people have never heard of Adblock and Flashblock, and maybe there really is a memory leak when you browse the web like a savage without them.

Re:I hope this solves the problem

[arose]

I don't have those problems either. Every single Firefox memory issue I've ever had was caused by Flash.

No.

[warrax_666]

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

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"

Use Emacs

[Anonymous Coward]

If you have never used either of the two editors with supported syntax highlighting then just use Emacs as it has always clearly better than Vim.

Waiting for binary packages

[Anonymous Coward]

newbie to programming here. I'm waiting for the binary packages for Windows XP 32bit.

These installation instructions won't work on Microsoft Windows anyways:

$ wget http://dl.rust-lang.org/dist/rust-0.1.tar.gz
$ tar -xzf rust-0.1.tar.gz
$ cd rust-0.1
$ ./configure
$ make && make install

Re:Waiting for binary packages

[3vi1]

Don't feel left out: they won't work on Linux either. :)

compile_and_link: x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/librustc.so
error: internal compiler error unexpected failure
note: The compiler hit an unexpected failure path. This is a bug. Try running with RUST_LOG=rustc=0,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/librustc.so] Error 101

Re:Waiting for binary packages

[DragonWriter]

These installation instructions won't work on Microsoft Windows anyways:

Those are the instructions on the "tutorial" page that are introduced by saying "Assuming you're on a relatively modern Linux system and have met the prerequisites", and followed by a note that the instructions are different for Windows and you need to see the linked Getting Started page. Why would you expect them, as opposed to the specific instructions for Windows, to work on Windows?

Re:Waiting for binary packages

[Ash-Fox]

These installation instructions won't work on Microsoft Windows anyways:

Almost worked for me, I just had to modify the configure script to accept the platform as 'Linux'. Other than that, worked 100% fine on Windows?

Bad logic

[bigsexyjoe]

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

That statement is not true, not close to being true, and it ignores a great deal of nuance. In fact, if you pick a random language X, most good programmers don't know how to create a good program in that language. For example, I have heard that John Resig, who created jQuery, does not know how to write a good program in Visual FoxPro.

Also, just because it possible to program in one language doesn't mean that another language be more productive, or easier to make error free code in. For example, if you created a language that relied on goto statements, it would less productive and result in more buggy code than C++. Just like Goto, it has been found that explicit pointers make buggier code than languages that make it possible to completely eliminate the use of explicit pointers.

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

Re:Not again.

[VortexCortex]

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

First, an actual organism is making a reply.

Second, isn't it time we stop breeding the same species over and over again, each time in a slightly different form? I recommend one of the best lectures on the subject: Creationism Evolved.

( Good luck with your Stagnation & resulting Extinction, I choose to Adapt and Evolve -- Even if this means some small efforts are wasted in dead ends along the way. )

Another inefficient syntax

[Anonymous Coward]

They should get rid of the braces and semicolons. Any new language should borrow from more efficient (syntax wise) languages like Python or CoffeeScript (which is the most efficient language I have worked with). Using tabs / indentations for blocks works absolutely fine and using one command / expression per line without a closing semicolon makes coding a lot faster.

One Language to Rule Them All

[bill_mcgonigle]

I'm not of the belief that the best computer language that will ever be invented has been invented.

So, onward, I say. Fail if you will, and we'll hopefully learn things from that failure. Succeed if you can, but the odds are against you, so you better be pretty sure you're learning from those who have failed before you.

0.1?

[Anonymous Coward]

0.1? No thanks, I'll wait for 11.0 next month

Designer's Facial Hair

[BinBoy]

Does the designer of the language have facial hair? No point in learning it if he doesn't. (And if it's a woman and she's not the bearded lady, forget it.) http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx

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:could the summary be less accurate?

[slasho81]

What's up with all those facts?! This is slashdot.

YABL

[iliketrash]

YABL

how do you test code to handle hardware faults?

[Chirs]

Unless you've got a dedicated hardware modding crew, it is essentially impossible to test some classes of software that are designed to deal with hardware faults.

For instance...how would you trigger an uncorrectable ECC fault on your server's memory? You can register for such notifications, but can't actually test it unless you happen to have a faulty DRAM module hanging around.

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.

They did go reinvent

[AHuxley]

Ada for the next generation.

Why A New Language? Here's why.

[vAltyR]

For all those people commenting asking about why we need a new language, Rob Pike, one of the developers of Go, gave a talk a couple years back that included some of the reasoning behind why the Go developers felt that a new language was needed, rather than just a new library. The rationale was mostly intended for Go, but Rust fills a very similar niche, so the rationale works for it as well. The video is here for those interested.

No implicit null pointers

[tepples]

Pointer variables in C++ and reference variables in Java are in essence a nullable/option/maybe reference to an object of a given type. This is conceptually the same as a tagged union between a reference to the given type and the global sentinel object called NULL. In fact, others have explained to me that Rust allows such option types as a language feature. I was just worried that messing around with a tagged union might hurt the goal of being "as fast as C". Perhaps my point is that "no null pointers" should have been written "no implicit null pointers": each variable can be marked with type T or option<T> depending on whether the program ever expects to store a reference to the null object in this variable, and static analysis will keep a reference to the null object from being stored in a variable of type T.

Lambda calculus.

[Anonymous Coward]

All is human-translatable to C language that's the most popular, but who doesn't use lambda calculus?

JCPM

Right to work

[tepples]

The whole point of an optional type, is that you must deunionize them before you can use it.

Deunionize? Does this mean programs written in languages that distinguish variables of type T not null from option<T> have a right to work?