Forgot your password?
typodupeerror
Firefox Mozilla Programming

Mozilla Releases Rust 0.1 232

Posted by timothy
from the is-it-ironic-that-rust-has-no-c? dept.
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."
This discussion has been archived. No new comments can be posted.

Mozilla Releases Rust 0.1

Comments Filter:
  • No null pionters (Score:5, Interesting)

    by tepples (727027) <tepples AT gmail DOT com> on Tuesday January 24, 2012 @01:04PM (#38807123) Homepage Journal
    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?
    • 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" ?
      • Perhaps you have to create a tag expressly labelled "end"? Like a constant or something. Null±1.
        • by mcavic (2007672)
          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 (Score:5, Informative)

            by Samantha Wright (1324923) on Tuesday January 24, 2012 @01:46PM (#38807829) Homepage Journal
            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.
            • by MtHuurne (602934)

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

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

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

      • by rev0lt (1950662)
        Let's call it a stream and have the last element point to the head of the list. No null pointer required.
        • Sounds less like a stream and more like a water processing plant.

        • by mcavic (2007672)
          How would you know when you're at the end of the stream? Or, what happens when it's empty??
          • by rev0lt (1950662)
            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: (Score:2, Informative)

              by 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

      • 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 do

      • by Artraze (600366)

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

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

        • by 0123456 (636235)

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

          • by anonymov (1768712)

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

            • by 0123456 (636235) on Tuesday January 24, 2012 @02:44PM (#38808661)

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

              • by anonymov (1768712)

                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

        • by egomaniac (105476)

          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

          • by 0123456 (636235)

            "Arguing that a null-free language doesn't buy you any safety is like arguing that type checking doesn't buy you anything; you are correct that you can still make the exact same mistakes, but the difference is that the compiler will catch most of them."

            While that's somewhat true, I also disagree. Sure, the compiler will force you to add a null pointer check in a function wihch never expects to receive a null pointer.

            But then what?

            You write some code to deal with the case that you never expect to happen. The

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

          • 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

    • Re: (Score:3, Informative)

      by warrax_666 (144623)

      type Maybe a = Just a
                                                                    | Nothing

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

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

      • 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?
        • 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
          • by tepples (727027)
            So in other words, once they optimize the [expletive] out of their maybe types, they'll be back where they started.
            • 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.

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

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

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

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

      C# is a high level language yo

      • C# 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.

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

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

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

            • Re:Implicit (Score:5, Informative)

              by anonymov (1768712) on Tuesday January 24, 2012 @02:55PM (#38808847)

              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"

      • by sawatts (2552422)
        C++ is what you make of it.
    • by billcopc (196330)

      How about a primitive type that serves the purpose of Null, without actually being a pointer to 0x0.

      Other languages have the concept of an empty object, which is simply an object that discards all input and ignores method calls, without throwing an error. It might return an empty result for whichever type is expected by the context. That could be a boolean FALSE, zero, empty array, etc. You can still ask the object if it is empty, but at least your app won't shit the bed if you accidentally or lazily inv

      • Re: (Score:2, Insightful)

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

    • by mcavic (2007672)

      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.

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

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

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

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

  • Get rid of bit rot and get Rust instead? ;)
  • by epine (68316) on Tuesday January 24, 2012 @01:16PM (#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.

  • by qrwe (625937) on Tuesday January 24, 2012 @01:19PM (#38807361) Homepage Journal
    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?
    • by Anonymous Coward on Tuesday January 24, 2012 @02:00PM (#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.

    • 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
      • by Svartalf (2997)

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

    • by Grishnakh (216268)

      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

      • 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

  • Wonderful! (Score:5, Interesting)

    by Chemisor (97276) on Tuesday January 24, 2012 @01:21PM (#38807383)

    Yet another solution in search of a problem.

    • Re:Wonderful! (Score:4, Interesting)

      by DragonWriter (970822) on Tuesday January 24, 2012 @01:45PM (#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.

      • Re:Wonderful! (Score:5, Insightful)

        by Svartalf (2997) on Tuesday January 24, 2012 @02:41PM (#38808615) Homepage

        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.

    • by rawler (1005089)

      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)

  • Because every time I see someone abbreviate "Function" as "Fn" I read it as "effing"
  • by unixisc (2429386) on Tuesday January 24, 2012 @01:41PM (#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?
    • 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.
  • 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.
    • 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.

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

    • by Ash-Fox (726320)

      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

  • by Animats (122034) on Tuesday January 24, 2012 @03:34PM (#38809375) Homepage

    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.

  • by slasho81 (455509) on Tuesday January 24, 2012 @03:50PM (#38809575)

    First, an actual link to the language's site [rust-lang.org].

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

  • by fusiongyro (55524) <faxfreemosquito@@@yahoo...com> on Tuesday January 24, 2012 @04:49PM (#38810369) Homepage

    From the Rust Project FAQ [github.com]:

    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!

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin

Working...