×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mozilla Releases Rust 0.1

timothy posted more than 2 years ago | from the is-it-ironic-that-rust-has-no-c? dept.

Firefox 232

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

232 comments

No null pionters (4, Interesting)

tepples (727027) | more than 2 years ago | (#38807123)

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

Re:No null pionters (0)

Anonymous Coward | more than 2 years ago | (#38807203)

Maybe?

Re:No null pionters (2)

DaMattster (977781) | more than 2 years ago | (#38807267)

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 (1)

Samantha Wright (1324923) | more than 2 years ago | (#38807343)

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

Re:No null pionters (2)

mcavic (2007672) | more than 2 years ago | (#38807695)

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 (4, Informative)

Samantha Wright (1324923) | more than 2 years ago | (#38807829)

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 (1)

DragonWriter (970822) | more than 2 years ago | (#38807841)

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 (1)

somersault (912633) | more than 2 years ago | (#38807367)

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 (-1)

Anonymous Coward | more than 2 years ago | (#38808089)

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 (0)

Anonymous Coward | more than 2 years ago | (#38807425)

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.

A tag labeled "end" (2)

tepples (727027) | more than 2 years ago | (#38807461)

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" (1)

0123456 (636235) | more than 2 years ago | (#38807599)

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" (1)

kripkenstein (913150) | more than 2 years ago | (#38808489)

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

rev0lt (1950662) | more than 2 years ago | (#38807463)

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 (1)

mcavic (2007672) | more than 2 years ago | (#38807555)

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

Re:No null pionters (1)

rev0lt (1950662) | more than 2 years ago | (#38807673)

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 (2, Informative)

Anonymous Coward | more than 2 years ago | (#38808147)

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 (1)

DragonWriter (970822) | more than 2 years ago | (#38807491)

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 (2)

Artraze (600366) | more than 2 years ago | (#38808043)

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 (1)

0123456 (636235) | more than 2 years ago | (#38808105)

"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 (1)

anonymov (1768712) | more than 2 years ago | (#38808497)

> 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 (1)

egomaniac (105476) | more than 2 years ago | (#38808171)

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 (1)

0123456 (636235) | more than 2 years ago | (#38808519)

"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 (1)

xouumalperxe (815707) | more than 2 years ago | (#38808121)

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 (0)

Anonymous Coward | more than 2 years ago | (#38807275)

Oh god yes! No null pointers! Hallelujah!

Re:No null pionters (2, Informative)

warrax_666 (144623) | more than 2 years ago | (#38807325)

type Maybe a = Just a
                                                              | Nothing

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

Re:No null pionters (0)

Anonymous Coward | more than 2 years ago | (#38808159)

MOD PARENT UP

Re:No null pionters (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#38807353)

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

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

As Fast As Cee (1)

tepples (727027) | more than 2 years ago | (#38807495)

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

Re:As Fast As Cee (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#38807859)

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 (2)

tepples (727027) | more than 2 years ago | (#38808201)

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 (2)

K. S. Kyosuke (729550) | more than 2 years ago | (#38808487)

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

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

Re:No null pionters (1)

DragonWriter (970822) | more than 2 years ago | (#38807403)

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 (2)

JasterBobaMereel (1102861) | more than 2 years ago | (#38807465)

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

C# has null pointers (2)

tepples (727027) | more than 2 years ago | (#38807609)

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

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

No. (1)

warrax_666 (144623) | more than 2 years ago | (#38808213)

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

Implicit (2)

tepples (727027) | more than 2 years ago | (#38808269)

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

Anonymous Coward | more than 2 years ago | (#38807649)

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 (1)

billcopc (196330) | more than 2 years ago | (#38807619)

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 (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38808135)

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 (1)

mcavic (2007672) | more than 2 years ago | (#38807641)

So what better type is there

None. Nulls are perfectly elegant for representing an empty queue, the start/end of a queue, a pointer that's declared but not yet used, etc. Surely there's a graceful way to handle the dereferencing of a null pointer, instead of eliminating them.

Null pointers do exist, but checking is enforced (2)

pavon (30274) | more than 2 years ago | (#38807967)

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.

Oblig XKCD! (-1)

Anonymous Coward | more than 2 years ago | (#38807151)

Oblig Neil Young (0)

Anonymous Coward | more than 2 years ago | (#38807345)

~~Rust never sleeps~~.

Re:Oblig XKCD! (0)

Anonymous Coward | more than 2 years ago | (#38807387)

This bot sucks because it always posts the same xkcd.

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

Sure way to attract developers (0)

Anonymous Coward | more than 2 years ago | (#38807183)

Use a language with no existing user-base.

WTF are these people thinking!?!

Re:Sure way to attract developers (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#38807233)

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 (4, Insightful)

gbjbaanb (229885) | more than 2 years ago | (#38808385)

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 (2)

beelsebob (529313) | more than 2 years ago | (#38807457)

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 (0)

Anonymous Coward | more than 2 years ago | (#38808421)

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

*Sigh* (0)

Anonymous Coward | more than 2 years ago | (#38807197)

The other guy ALWAYS has the better gun.

They no longer need developers, it seems.. (-1, Redundant)

goruka (1721094) | more than 2 years ago | (#38807291)

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.. (1)

Microlith (54737) | more than 2 years ago | (#38807315)

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.. (0)

Anonymous Coward | more than 2 years ago | (#38807347)

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.. (2)

K. S. Kyosuke (729550) | more than 2 years ago | (#38807427)

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.. (2)

0123456 (636235) | more than 2 years ago | (#38807479)

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.. (2)

somersault (912633) | more than 2 years ago | (#38807769)

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.. (1)

0123456 (636235) | more than 2 years ago | (#38807979)

"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.. (2)

K. S. Kyosuke (729550) | more than 2 years ago | (#38808151)

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.. (0)

Anonymous Coward | more than 2 years ago | (#38808453)

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.. (1)

Anonymous Coward | more than 2 years ago | (#38808077)

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.. (2)

Samantha Wright (1324923) | more than 2 years ago | (#38807447)

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

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

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

Re:They no longer need developers, it seems.. (0)

Anonymous Coward | more than 2 years ago | (#38808323)

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.. (1)

JasterBobaMereel (1102861) | more than 2 years ago | (#38807493)

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.. (2)

Grishnakh (216268) | more than 2 years ago | (#38808419)

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.. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38807761)

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.. (2)

Jonner (189691) | more than 2 years ago | (#38808449)

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-write software? (0)

Anonymous Coward | more than 2 years ago | (#38807297)

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++ (2, Insightful)

epine (68316) | more than 2 years ago | (#38807327)

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

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

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

Survival's Ick Factor [nytimes.com]

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

Re:ultimately as fast as C++ (4, Funny)

jbeaupre (752124) | more than 2 years ago | (#38807637)

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++ (0)

Anonymous Coward | more than 2 years ago | (#38808191)

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

Also ... standard C.

Re:ultimately as fast as C++ (0)

Anonymous Coward | more than 2 years ago | (#38808373)

Microcode?

Re:ultimately as fast as C++ (0)

Anonymous Coward | more than 2 years ago | (#38808403)

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

Another compiler? Seriously? (5, Insightful)

qrwe (625937) | more than 2 years ago | (#38807361)

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? (5, Funny)

Anonymous Coward | more than 2 years ago | (#38808021)

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? (2)

TheDarkMaster (1292526) | more than 2 years ago | (#38808265)

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? (1)

Svartalf (2997) | more than 2 years ago | (#38808491)

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? (2)

Grishnakh (216268) | more than 2 years ago | (#38808479)

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.

Wonderful! (5, Interesting)

Chemisor (97276) | more than 2 years ago | (#38807383)

Yet another solution in search of a problem.

Re:Wonderful! (3, Interesting)

DragonWriter (970822) | more than 2 years ago | (#38807807)

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.

I like the shortened names (2)

Vektuz (886618) | more than 2 years ago | (#38807525)

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

c++ version of scala & haskell (0)

Anonymous Coward | more than 2 years ago | (#38807547)

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

Rewriting Would Be a Mistake (1)

MichaelBuckley (1258630) | more than 2 years ago | (#38807601)

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 [joelonsoftware.com]

No big rewrite necessary (2)

DragonWriter (970822) | more than 2 years ago | (#38807759)

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

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

Re:Rewriting Would Be a Mistake (4, Insightful)

fremen (33537) | more than 2 years ago | (#38807867)

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 (4, Insightful)

gbjbaanb (229885) | more than 2 years ago | (#38808255)

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.

Wash it in some alkali (4, Insightful)

unixisc (2429386) | more than 2 years ago | (#38807733)

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 (2)

TheDarkMaster (1292526) | more than 2 years ago | (#38808163)

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.

5 years? (0)

Anonymous Coward | more than 2 years ago | (#38807989)

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

Ok, I give up (1)

TheDarkMaster (1292526) | more than 2 years ago | (#38808051)

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 (0)

Anonymous Coward | more than 2 years ago | (#38808333)

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.

I hope this solves the problem (1)

DragonTHC (208439) | more than 2 years ago | (#38808103)

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 (1)

noelbon70 (880884) | more than 2 years ago | (#38808349)

"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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...