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.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?
    • by DaMattster (977781) on Tuesday January 24, 2012 @01:13PM (#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" ?
      • by Samantha Wright (1324923) on Tuesday January 24, 2012 @01:17PM (#38807343) Homepage Journal
        Perhaps you have to create a tag expressly labelled "end"? Like a constant or something. Null±1.
        • by mcavic (2007672) on Tuesday January 24, 2012 @01:38PM (#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 (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) on Tuesday January 24, 2012 @09:07PM (#38813801) Homepage

              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.

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

      • by somersault (912633) on Tuesday January 24, 2012 @01:20PM (#38807367) Homepage Journal

        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) on Tuesday January 24, 2012 @01:26PM (#38807463)
        Let's call it a stream and have the last element point to the head of the list. No null pointer required.
      • by DragonWriter (970822) on Tuesday January 24, 2012 @01:28PM (#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.

      • by Artraze (600366) on Tuesday January 24, 2012 @02:02PM (#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.

        • by 0123456 (636235) on Tuesday January 24, 2012 @02:06PM (#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.

          • by anonymov (1768712) on Tuesday January 24, 2012 @02:32PM (#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.

            • 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) on Tuesday January 24, 2012 @03:05PM (#38808979)

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

        • by egomaniac (105476) on Tuesday January 24, 2012 @02:10PM (#38808171) Homepage

          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.

          • by 0123456 (636235) on Tuesday January 24, 2012 @02:34PM (#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.

      • by xouumalperxe (815707) on Tuesday January 24, 2012 @02:07PM (#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.
        • by Waffle Iron (339739) on Tuesday January 24, 2012 @02:59PM (#38808913)

          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.

          • by DragonWriter (970822) on Tuesday January 24, 2012 @03:06PM (#38808993)

            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 (Score:3, Informative)

      by warrax_666 (144623) on Tuesday January 24, 2012 @01:16PM (#38807325)

      type Maybe a = Just a
                                                                    | Nothing

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

    • by K. S. Kyosuke (729550) on Tuesday January 24, 2012 @01:18PM (#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.

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

    • by JasterBobaMereel (1102861) on Tuesday January 24, 2012 @01:26PM (#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 ...

    • by billcopc (196330) <vrillco@yahoo.com> on Tuesday January 24, 2012 @01:34PM (#38807619) Homepage

      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.

    • by mcavic (2007672) on Tuesday January 24, 2012 @01:35PM (#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.

    • by pavon (30274) on Tuesday January 24, 2012 @01:55PM (#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.

    • by GreyWolf3000 (468618) on Tuesday January 24, 2012 @02:36PM (#38808553) Journal

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

  • by K. S. Kyosuke (729550) on Tuesday January 24, 2012 @01:08PM (#38807189)
    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.

    • by TheDarkMaster (1292526) on Tuesday January 24, 2012 @02:16PM (#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
    • by Grishnakh (216268) on Tuesday January 24, 2012 @02:30PM (#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.

      • by DragonWriter (970822) on Tuesday January 24, 2012 @05:52PM (#38811379)

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

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

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

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

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

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

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

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

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

  • Wonderful! (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) <ulrik.mikaelsson ... il.com minus bsd> on Tuesday January 24, 2012 @02:46PM (#38808695)

      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)

  • by Vektuz (886618) on Tuesday January 24, 2012 @01:30PM (#38807525)
    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?
  • by TheDarkMaster (1292526) on Tuesday January 24, 2012 @02:02PM (#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.
    • by mrnobo1024 (464702) on Tuesday January 24, 2012 @03:08PM (#38809017)

      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) on Tuesday January 24, 2012 @03:05PM (#38808977)

      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.

  • 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. c o m> 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!

The end of labor is to gain leisure.

Working...