7 ms·

Mozilla Is Designing a New Programming Language Language Called Rust

92 points by hornokplease 16y ago

steveklabnik 16y ago
Previous coverage of rust: http://news.ycombinator.com/item?id=1498528 http://news.ycombinator.com/item?id=1498528 http://news.ycombinator.com/item?id=1498233 http://news.ycombinator.com/item?id=1498233
daeken 16y ago
> Ed Borasky recently commented here at ReadWriteHack: "We flat out don't need any more programming languages! What we need is efficient implementations of the ones we have now and IDEs / version control systems that enforce software engineering discipline." There was no need for assembly -- writing straight machine code worked. There was no need for C -- writing straight assembly worked. Etc, etc. There has never been a need for a new programming language, but new programming languages can make life easier, can save you time, can make new optimizations possible, etc. So he's right in that we flat out don't need any more programming languages, but that doesn't mean creating new programming languages is a bad idea, or something we shouldn't do.
- quanticle 16y ago
  It might be too soon to ask, but what distinguishes Rust from Google's Go or the D programming language? It seems to me that we've got three programming languages competing for the same niche.
  - daeken 16y ago
    Not a whole lot, conceptually, it seems. The syntax feels very Nemerle-like to me, though, which is nice. Definitely something to play around with, if nothing else.
    - hamilton 16y ago
      Having seen early versions of Rust (I work at Mozilla) I can tell you that the syntax is the last thing they're even considering (though that may have changed over the past few months). Seems like Graydon wants to get the guts right first.
      - quanticle 16y ago
        That gets back to my question. What are Rust's advantages over Go or D?
  - Semiapies 16y ago
    Not entirely sure what distinguishes them, but I'd rather have some competition in the niche than avoid defaulting to the first language that addresses the niche.
    - quanticle 16y ago
      That's true, but this whole effort smells like an exercise in wheel re-invention to me.
      - Semiapies 16y ago
        If you know what you're doing, that's a valid way to try to make better wheels.
  - neilk 16y ago
    From https://github.com/graydon/rust/wiki/language-faq https://github.com/graydon/rust/wiki/language-faq : *Have you seen this Google language, Go? How does Rust compare?* Yes. Rust development was several years underway before Go launched, no direct inspiration. Though Pike’s previous languages in the Go family (Newsqueak, Alef, Limbo) were influential. Go adopted semantics (safety and memory model) that are quite unsatisfactory. - Shared mutable state. - Global GC. - Null pointers. - No RAII or destructors. - No type-parametric user code. There are a number of other fine coroutine / actor languages in development presently. It’s an area of focus across the PL community.
    - quanticle 16y ago
      Thanks for that. It wasn't clear from the linked article that Rust was started before Go. The overall impression that I got from TFA was that Rust is another instance of the garbage-collected system language fad.
      - ramchip 16y ago
        What are the other instances? Besides Go, I don't recall many languages that fit the bill. There's D, but it's not very new and certainly not a fad language.
        steveklabnik 16y ago
        And it's only garbage collected if you want it to be. (My friends are making an exokernel in D)
      - konad 16y ago
        I think the fact that Rust is older and yet Go has 1000s of active programmers is indicative of something. "Ship early, ship often" springs to mind. The Plan9 community has been working like that for years, almost every day an updated version is available (the distro cdrom is rebuilt every night) with bug fixes / improvements / new stuff.
  - deleted 16y ago
    [deleted]
    - effn 16y ago
      Rust is not very functional at all. E.g. no lambda, no closures (yet).
    - deleted 16y ago
      [deleted]
  - effn 16y ago
    Compared to Go: * Rust does not have NULL!! * Rust has parametric polymorphism. * Rust has more predictable memory/cpu usage thanks to forgoing global GC for a novel memory management model based on stack allocation/RAII, immutability, isolated processes and reference counting. * Rust has a very Erlang-like model of handling failures. * Rust has typestate, which is an easy to use way of proving properties about your program statically, or check them dynamically via assertion. * Rust has no shared mutable state. Those are facts. My personal, more subjective, opinion is that Rust is a lot better thought out than either D or Go. If this niche is too crowded, I'd rather see them go and Rust win. :) But given that Rust lacks shared global GC, I guess you could say it's closer to C++
    - supersillyus 16y ago
      I think Rust is very interesting and quite exciting, but it's hard to evaluate in relation to other languages (for me, at least) because it is really really young. I've never seen a useful program written in Rust. All of the features sound really good in theory, but I've never used a similar language, so I don't have a sense for how these features work in practice. Actually, anybody have a link to some non-trivial Rust code?
      - effn 16y ago
        The self hosted Rust compiler is probably the largest piece of Rust code right now: https://github.com/graydon/rust/tree/master/src/comp/ https://github.com/graydon/rust/tree/master/src/comp/
        supersillyus 16y ago
        Awesome. Thanks for the link. Didn't realize that existed.
    - burgerbrain 16y ago
      > * Rust does not have NULL!! That hardly strikes me as a feature. Null pointers simplify a lot of error-checking. Don't know if what you got back was valid? As easy as checking to see if it's zero!
- tgflynn 16y ago
  I'd like to see a better programming language. All of the existing languages involve accepting certain trade-offs. Of course maybe no "perfect" language can exist but until someone proves that there's always hope. For me the ideal language would : - Support OO, imperative and functional paradigms - Compile to fully optimized machine code with efficiency comparable to that of C - Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab - Support list comprehensions - Provide map,list and set types similar to those of Python - Support dynamic typing - Support optional static typing, and contracts - Provide standard libraries with breadth of functionality comparable to those of Java but simpler API's (more like Python) - Provide a mechanism for efficient compile-time parametrization of algorithms, like C++ templates - Support free-form (ie. whitespace independent) syntax - Provide a high quality cross-platform GUI toolkit with support for OpenGL - Provide an interactive graphical environment for experimentation and data analysis - Provide a dataset abstraction similar to R data frames - Be supported by a high-quality IDE and debugger Of course that's a lot to ask for, but it would be nice to be able to do everything with a single unified syntax and environment.
  - jamii 16y ago
    Ocaml hits most of the points on your list, if you can bring yourself to use a statically typed language. > Support OO, imperative and functional paradigms Yep. Objects aren't used all that often but they are fully supported and can do some things that are difficult in Java or C++ eg http://caml.inria.fr/pub/docs/manual-ocaml/manual007.html#toc39 http://caml.inria.fr/pub/docs/manual-ocaml/manual007.html#to... > Compile to fully optimized machine code with efficiency comparable to that of C Not quite, but ocamlopt generates pretty damn fast code and, more importantly, has very predictable performance. Ocaml makes a pretty good systems language as demonstrated by the recent Mirage paper: http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf > Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab No, but this would make a good Jane Street summer project. Ocaml has extensible syntax via camlp4 and bindings to R, GSL and Matlab (no octave bindings for some reason). > Support list comprehensions Yes, as a syntax extension. http://batteries.forge.ocamlcore.org/doc.preview:batteries-beta1/html/extensions.html#Comprehension http://batteries.forge.ocamlcore.org/doc.preview:batteries-b... > Provide map,list and set types similar to those of Python The syntax is not as nice but apart from that: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Map.Make.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Map.Make.h... http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.ht... http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Set.S.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Set.S.html > Support dynamic typing Nope. You can circumvent the type system using Obj but its generally not advisable. > Support optional static typing, and contracts Static typing - yes. Contracts - see eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.157.5372&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.157... http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/opis_presentation.pdf http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/opis... > Provide standard libraries with breadth of functionality comparable to those of Java but simpler API's (more like Python) No. Ocaml Batteries is a start but nowhere near as broad as Python or Java. > Provide a mechanism for efficient compile-time parametrization of algorithms, like C++ templates Not just compile time specialization but multi-stage compilation via MetaOcaml. See eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.2541&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.... > Support free-form (ie. whitespace independent) syntax Yep, although there are some issues with the syntax eg dangling-else-like problems with nested matches. > Provide a high quality cross-platform GUI toolkit with support for OpenGL Well tested bingdings to Tk, Gtk and OpenGL. > Provide an interactive graphical environment for experimentation and data analysis None that I know of. I tend to use matplotlib and opengl interactively from the repl but its not up to the standards of mathematica etc. > Provide a dataset abstraction similar to R data frames I dont think so. I haven't used R much so I don't know exactly what features are missing. > Be supported by a high-quality IDE and debugger There are a couple of IDEs but none of them seem to be very well polished. Ocaml-mode and emacs is generally the way to go. The time-travelling ocaml debugger is pretty amazing. You can also compile with support for gdb for low level debugging.
- joe_the_user 16y ago
  Yes, The boundary between a file format and a programming language is fairly fuzzy too. I recently created a custom "little language" as a replacement for some rather fragile configuration routines. It won't need a lot of users to be a win. (and no, it wouldn't have been faster/easier to use Lua/Ruby/Python etc).
- scott_s 16y ago
  New programming languages are never necessary, but they should scratch some itch. Something that was cumbersome in other languages should be easy in the new language. Or the new language should be the union of things that only existed disjointly in other languages. Rust seems to fall in that latter category.
- axod 16y ago
  There's a spectrum from machine code up to high level languages. Pretty much all the points on that spectrum already have languages on them. We absolutely don't need any more languages. Languages aren't a problem that needs fixing. But they're fun to create, which is why people keep creating them. Also it's very much a 'social' and fashion driven thing. Some people can't bear to be using 'last years' language.
  - stcredzero 16y ago
    Languages aren't a problem that needs fixing. Keeping Multicore machines busy is a problem that needs fixing and it's also an example of a problem amenable to a solution in the form of a new language. http://gigaom.com/2008/06/19/multicores-not-so-secret-problem/ http://gigaom.com/2008/06/19/multicores-not-so-secret-proble...
    - axod 16y ago
      We've been told for around 10 years now that we'll soon have 128 cores in our laptops. It hasn't happened yet.
      - stcredzero 16y ago
        Yeah, but now we have 8 cores in our desktops, and our popular languages can't handle that so well.
  - InclinedPlane 16y ago
    If you think we don't need any new languages then either you aren't doing anything interesting, aren't paying attention, or you just don't care.
    - axod 16y ago
      Name some technological advance or achievement that has only been possible through the creation of a new programming language. edit: Thanks for the downmod to 0. It really does speak volumes.
kenjackson 16y ago
A new "systems" language? Really? What about an IL to replace Javascript as the lingua franca, rather than doing this?
- dangoor 16y ago
  Actually, Brendan discussed that very topic recently: http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122
  - kenjackson 16y ago
    His argument against Bytecode is unconvincing, in particular version hell and optimization limits in bytecode. The part that is convincing is the fact that we can't get vendors to agree on a bytecode. It's unfortunate that the most popular platform in the world will continue to look like it was cobbled together by CS 101 studwents who weren't particularly great students, and were drunk. People thought Windows 2.0 was bad as a platform. It's like we have Windows 2.0 for the life of the web because there's too many vendors in conflict to actually make it decent.
    - BrendanEich 16y ago
      My "argument" against bytecode on the basis of inevitable version hell and bytecode-lowering tending to overspecify against alternative implementation and optimization strategy is fundamentally an observation: both Java and .NET were designed for one particular language first, and the intermediate code design reflects this in many hardcoded and hard-to-change ways. Not only in what was put into the bytecode, but what was left out. Both the JVM and the CLR fail to run other than their premier languages, or nearby languages, very well (fast enough or with all features in the "port"). Continuations? Hah. Invokedynamic has taken way too long and the JS VMs have run laps around the JVM. Yes, browser vendors will also not agree, and for these good reasons among other more "selfish" ones. Get over it.
      - kenjackson 16y ago
netaustin 16y ago
I tend to judge languages solely on their aesthetic utility unless they're designed to make something very difficult possible (e.g. Erlang). And this one isn't any more pleasant to read than Java or C, it just happens to be a little different. Given the long list of advantages to using Rust, why they can't use an existing syntax? Also, I've always felt queasy about using -> or => as arrows. And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down.
- chime 16y ago
  > And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down. I agree about the 'let' part. Why isn't "int i = 0;" sufficient?
  - nickik 16y ago
    int i = 0 not code because modern compilers don't need to know about int at first. The compiler wants to now that you creat a variable the type is not importend at that moment. Thats why most new languages like go or scala have the type after the inizalisation.
    - masklinn 16y ago
      > int i = 0 not code because modern compilers don't need to know about int at first. Where "modern" means "any non-utterly-stupid compiler built in the last 40 years or so".
  - tjarratt 16y ago
    I suspect this is an artifact from their stance on mutable state, and some inspiration from more functional languages. There certainly isn't much harm in being clear where you are initializing variables. I would say that using actual english words rather than brief non-words such as def or var makes the syntax more readable. If the keyword really bothers you that much, couldn't you fork the project and perform a global find/replace? (yes I realize that _maintaining_ a fork like that could be nightmarish, but the point still stands)
brlewis 16y ago
Scheme/Lisp compilers already allocate variables on the stack when it's safe to do so. It isn't always safe to do so. The part about "lambda-blocks w/o heap allocation" describes a missing feature, not an innovation in concurrency or efficiency.
whakojacko 16y ago
This seems to be fairly similar to Go. Given I don't know too much about either, what are the major differences?
- masklinn 16y ago
  See their FAQ: *Have you seen this Google language, Go? How does Rust compare?* Yes. Rust development was several years underway before Go launched, no direct inspiration. Though Pike’s previous languages in the Go family (Newsqueak, Alef, Limbo) were influential. Go adopted semantics (safety and memory model) that are quite unsatisfactory. - Shared mutable state. - Global GC. - Null pointers. - No RAII or destructors. - No type-parametric user code. There are a number of other fine coroutine / actor languages in development presently. It’s an area of focus across the PL community. tl;dr, Rust seems to not ignore the last 20 or 30 years of computer science.
  - supersillyus 16y ago
    Indeed. Go seems inspired by the last 20 or 30 years of computer engineering (it is built from concepts that have been proven to work (and often not work) in the past), and Rust seems to take into account the last 20 or 30 years of research. In my view, Rust has more potential, but Go is a safer bet, at least until Rust has been used for a fair bit of Real Code (tm).
- konad 16y ago
  Go has users
phalanx 16y ago
Looks like ReadWriteWeb is looking to DZone for inspiration. Amazing how my article about some 'old news' generated so many spinoffs. http://java.dzone.com/rust_language http://java.dzone.com/rust_language
DjDarkman 16y ago
It looks a lot like JavaScript, maybe we could fix up JavaScript instead of inventing a whole new language. I'm just saying...
- mbrubeck 16y ago
  The key people behind Rust are also on Mozilla's JavaScript team (one of them is Brendan Eich, the creator of JavaScript), and they are active in the ECMA process that's defining ES5 and ES Harmony, which are "fixed up" versions of JavaScript. Firefox 4 contains one of the first implementations of many of the improvements in ES5. But high-performance JavaScript VMs and rendering engines are not written in JavaScript; today they are mostly written in C++. Rust is designed by and targeted at the people implementing the VMs. It's the language they hope to use to implement future JavaScript compilers.
bryanlarsen 16y ago
Kudos to Mozilla. The chance of failure for this project is very high -- there's lots of new languages coming out all the time, and existing languages have huge infrastructure advantages. It's nice to see organizations take a flyer on something that has the potential to really make our lives a lot better. Rust's design decisions make much more sense than Go. Rather than designing C+++, they've ditched shared mutable state, a global GC and null pointers, and the stupid parts of the C syntax.
joe_the_user 16y ago
It may be that we'll see more languages in the future rather than seeing more language consolidation. As Moore's Law for processor speeds hits a wall, programmers are going to have an incentive to take advantage of the parallel/multi-core CPUs that are appearing in lieu of actually faster CPUs. Parallel programming is inherently less general-purpose than single threaded programming - there are a narrower range of things that you can do really quickly. I'd suspect that even doing that narrower range well will be more dependent on the memory/communications/threading model you use. If this is true, it seems logical that we'll see a wider variety of languages in the future rather than having things consolidate. One language might better for simulation, another for 3D manipulation, etc. I'd also imagine chip-makers would start to look at the languages which can target The standard Von Neumann architecture has allowed the general purpose computer to be relatively dominant product (even purpose built-machines often just leverage general-purpose chips). Parallel architecture would tend to allow the reappearance of purpose-built machines so-designed from the ground-up with all the differentiation that this world previously had.
freeflygeek 16y ago
I cannot believe that in the age of multi-core and distributed computing on the cloud, programming languages are still being designed with for-loops and iteration as the basic construct?!? Good luck parallelizing that!

92 points by hornokplease 16y ago

Previous coverage of rust: http://news.ycombinator.com/item?id=1498528 http://news.ycombinator.com/item?id=1498528 http://news.ycombinator.com/item?id=1498233 http://news.ycombinator.com/item?id=1498233

daeken 16y ago

> Ed Borasky recently commented here at ReadWriteHack: "We flat out don't need any more programming languages! What we need is efficient implementations of the ones we have now and IDEs / version control systems that enforce software engineering discipline." There was no need for assembly -- writing straight machine code worked. There was no need for C -- writing straight assembly worked. Etc, etc. There has never been a need for a new programming language, but new programming languages can make life easier, can save you time, can make new optimizations possible, etc. So he's right in that we flat out don't need any more programming languages, but that doesn't mean creating new programming languages is a bad idea, or something we shouldn't do.

quanticle 16y ago
It might be too soon to ask, but what distinguishes Rust from Google's Go or the D programming language? It seems to me that we've got three programming languages competing for the same niche.
- daeken 16y ago
  Not a whole lot, conceptually, it seems. The syntax feels very Nemerle-like to me, though, which is nice. Definitely something to play around with, if nothing else.
  - hamilton 16y ago
    Having seen early versions of Rust (I work at Mozilla) I can tell you that the syntax is the last thing they're even considering (though that may have changed over the past few months). Seems like Graydon wants to get the guts right first.
    - quanticle 16y ago
      That gets back to my question. What are Rust's advantages over Go or D?
- Semiapies 16y ago
  Not entirely sure what distinguishes them, but I'd rather have some competition in the niche than avoid defaulting to the first language that addresses the niche.
  - quanticle 16y ago
    That's true, but this whole effort smells like an exercise in wheel re-invention to me.
    - Semiapies 16y ago
      If you know what you're doing, that's a valid way to try to make better wheels.
- neilk 16y ago
  From https://github.com/graydon/rust/wiki/language-faq https://github.com/graydon/rust/wiki/language-faq : *Have you seen this Google language, Go? How does Rust compare?* Yes. Rust development was several years underway before Go launched, no direct inspiration. Though Pike’s previous languages in the Go family (Newsqueak, Alef, Limbo) were influential. Go adopted semantics (safety and memory model) that are quite unsatisfactory. - Shared mutable state. - Global GC. - Null pointers. - No RAII or destructors. - No type-parametric user code. There are a number of other fine coroutine / actor languages in development presently. It’s an area of focus across the PL community.
  - quanticle 16y ago
    Thanks for that. It wasn't clear from the linked article that Rust was started before Go. The overall impression that I got from TFA was that Rust is another instance of the garbage-collected system language fad.
    - ramchip 16y ago
      What are the other instances? Besides Go, I don't recall many languages that fit the bill. There's D, but it's not very new and certainly not a fad language.
      - steveklabnik 16y ago
        And it's only garbage collected if you want it to be. (My friends are making an exokernel in D)
    - konad 16y ago
      I think the fact that Rust is older and yet Go has 1000s of active programmers is indicative of something. "Ship early, ship often" springs to mind. The Plan9 community has been working like that for years, almost every day an updated version is available (the distro cdrom is rebuilt every night) with bug fixes / improvements / new stuff.
- deleted 16y ago
  [deleted]
  - effn 16y ago
    Rust is not very functional at all. E.g. no lambda, no closures (yet).
  - deleted 16y ago
    [deleted]
- effn 16y ago
  Compared to Go: * Rust does not have NULL!! * Rust has parametric polymorphism. * Rust has more predictable memory/cpu usage thanks to forgoing global GC for a novel memory management model based on stack allocation/RAII, immutability, isolated processes and reference counting. * Rust has a very Erlang-like model of handling failures. * Rust has typestate, which is an easy to use way of proving properties about your program statically, or check them dynamically via assertion. * Rust has no shared mutable state. Those are facts. My personal, more subjective, opinion is that Rust is a lot better thought out than either D or Go. If this niche is too crowded, I'd rather see them go and Rust win. :) But given that Rust lacks shared global GC, I guess you could say it's closer to C++
  - supersillyus 16y ago
    I think Rust is very interesting and quite exciting, but it's hard to evaluate in relation to other languages (for me, at least) because it is really really young. I've never seen a useful program written in Rust. All of the features sound really good in theory, but I've never used a similar language, so I don't have a sense for how these features work in practice. Actually, anybody have a link to some non-trivial Rust code?
    - effn 16y ago
      The self hosted Rust compiler is probably the largest piece of Rust code right now: https://github.com/graydon/rust/tree/master/src/comp/ https://github.com/graydon/rust/tree/master/src/comp/
      - supersillyus 16y ago
        Awesome. Thanks for the link. Didn't realize that existed.
  - burgerbrain 16y ago
    > * Rust does not have NULL!! That hardly strikes me as a feature. Null pointers simplify a lot of error-checking. Don't know if what you got back was valid? As easy as checking to see if it's zero!
tgflynn 16y ago
I'd like to see a better programming language. All of the existing languages involve accepting certain trade-offs. Of course maybe no "perfect" language can exist but until someone proves that there's always hope. For me the ideal language would : - Support OO, imperative and functional paradigms - Compile to fully optimized machine code with efficiency comparable to that of C - Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab - Support list comprehensions - Provide map,list and set types similar to those of Python - Support dynamic typing - Support optional static typing, and contracts - Provide standard libraries with breadth of functionality comparable to those of Java but simpler API's (more like Python) - Provide a mechanism for efficient compile-time parametrization of algorithms, like C++ templates - Support free-form (ie. whitespace independent) syntax - Provide a high quality cross-platform GUI toolkit with support for OpenGL - Provide an interactive graphical environment for experimentation and data analysis - Provide a dataset abstraction similar to R data frames - Be supported by a high-quality IDE and debugger Of course that's a lot to ask for, but it would be nice to be able to do everything with a single unified syntax and environment.
- jamii 16y ago
  Ocaml hits most of the points on your list, if you can bring yourself to use a statically typed language. > Support OO, imperative and functional paradigms Yep. Objects aren't used all that often but they are fully supported and can do some things that are difficult in Java or C++ eg http://caml.inria.fr/pub/docs/manual-ocaml/manual007.html#toc39 http://caml.inria.fr/pub/docs/manual-ocaml/manual007.html#to... > Compile to fully optimized machine code with efficiency comparable to that of C Not quite, but ocamlopt generates pretty damn fast code and, more importantly, has very predictable performance. Ocaml makes a pretty good systems language as demonstrated by the recent Mirage paper: http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf > Provide language support for numerical multidimensional arrays and linear algebra with a syntax comparable to Matlab No, but this would make a good Jane Street summer project. Ocaml has extensible syntax via camlp4 and bindings to R, GSL and Matlab (no octave bindings for some reason). > Support list comprehensions Yes, as a syntax extension. http://batteries.forge.ocamlcore.org/doc.preview:batteries-beta1/html/extensions.html#Comprehension http://batteries.forge.ocamlcore.org/doc.preview:batteries-b... > Provide map,list and set types similar to those of Python The syntax is not as nice but apart from that: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Map.Make.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Map.Make.h... http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.ht... http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/List.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Set.S.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Set.S.html > Support dynamic typing Nope. You can circumvent the type system using Obj but its generally not advisable. > Support optional static typing, and contracts Static typing - yes. Contracts - see eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.157.5372&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.157... http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/opis_presentation.pdf http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/opis... > Provide standard libraries with breadth of functionality comparable to those of Java but simpler API's (more like Python) No. Ocaml Batteries is a start but nowhere near as broad as Python or Java. > Provide a mechanism for efficient compile-time parametrization of algorithms, like C++ templates Not just compile time specialization but multi-stage compilation via MetaOcaml. See eg http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.2541&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.... > Support free-form (ie. whitespace independent) syntax Yep, although there are some issues with the syntax eg dangling-else-like problems with nested matches. > Provide a high quality cross-platform GUI toolkit with support for OpenGL Well tested bingdings to Tk, Gtk and OpenGL. > Provide an interactive graphical environment for experimentation and data analysis None that I know of. I tend to use matplotlib and opengl interactively from the repl but its not up to the standards of mathematica etc. > Provide a dataset abstraction similar to R data frames I dont think so. I haven't used R much so I don't know exactly what features are missing. > Be supported by a high-quality IDE and debugger There are a couple of IDEs but none of them seem to be very well polished. Ocaml-mode and emacs is generally the way to go. The time-travelling ocaml debugger is pretty amazing. You can also compile with support for gdb for low level debugging.
joe_the_user 16y ago
Yes, The boundary between a file format and a programming language is fairly fuzzy too. I recently created a custom "little language" as a replacement for some rather fragile configuration routines. It won't need a lot of users to be a win. (and no, it wouldn't have been faster/easier to use Lua/Ruby/Python etc).
scott_s 16y ago
New programming languages are never necessary, but they should scratch some itch. Something that was cumbersome in other languages should be easy in the new language. Or the new language should be the union of things that only existed disjointly in other languages. Rust seems to fall in that latter category.
axod 16y ago
There's a spectrum from machine code up to high level languages. Pretty much all the points on that spectrum already have languages on them. We absolutely don't need any more languages. Languages aren't a problem that needs fixing. But they're fun to create, which is why people keep creating them. Also it's very much a 'social' and fashion driven thing. Some people can't bear to be using 'last years' language.
- stcredzero 16y ago
  Languages aren't a problem that needs fixing. Keeping Multicore machines busy is a problem that needs fixing and it's also an example of a problem amenable to a solution in the form of a new language. http://gigaom.com/2008/06/19/multicores-not-so-secret-problem/ http://gigaom.com/2008/06/19/multicores-not-so-secret-proble...
  - axod 16y ago
    We've been told for around 10 years now that we'll soon have 128 cores in our laptops. It hasn't happened yet.
    - stcredzero 16y ago
      Yeah, but now we have 8 cores in our desktops, and our popular languages can't handle that so well.
- InclinedPlane 16y ago
  If you think we don't need any new languages then either you aren't doing anything interesting, aren't paying attention, or you just don't care.
  - axod 16y ago
    Name some technological advance or achievement that has only been possible through the creation of a new programming language. edit: Thanks for the downmod to 0. It really does speak volumes.

kenjackson 16y ago

A new "systems" language? Really? What about an IL to replace Javascript as the lingua franca, rather than doing this?

dangoor 16y ago
Actually, Brendan discussed that very topic recently: http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122
- kenjackson 16y ago
  His argument against Bytecode is unconvincing, in particular version hell and optimization limits in bytecode. The part that is convincing is the fact that we can't get vendors to agree on a bytecode. It's unfortunate that the most popular platform in the world will continue to look like it was cobbled together by CS 101 studwents who weren't particularly great students, and were drunk. People thought Windows 2.0 was bad as a platform. It's like we have Windows 2.0 for the life of the web because there's too many vendors in conflict to actually make it decent.
  - BrendanEich 16y ago
    My "argument" against bytecode on the basis of inevitable version hell and bytecode-lowering tending to overspecify against alternative implementation and optimization strategy is fundamentally an observation: both Java and .NET were designed for one particular language first, and the intermediate code design reflects this in many hardcoded and hard-to-change ways. Not only in what was put into the bytecode, but what was left out. Both the JVM and the CLR fail to run other than their premier languages, or nearby languages, very well (fast enough or with all features in the "port"). Continuations? Hah. Invokedynamic has taken way too long and the JS VMs have run laps around the JVM. Yes, browser vendors will also not agree, and for these good reasons among other more "selfish" ones. Get over it.
    - kenjackson 16y ago

netaustin 16y ago

I tend to judge languages solely on their aesthetic utility unless they're designed to make something very difficult possible (e.g. Erlang). And this one isn't any more pleasant to read than Java or C, it just happens to be a little different. Given the long list of advantages to using Rust, why they can't use an existing syntax? Also, I've always felt queasy about using -> or => as arrows. And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down.

chime 16y ago
> And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down. I agree about the 'let' part. Why isn't "int i = 0;" sufficient?
- nickik 16y ago
  int i = 0 not code because modern compilers don't need to know about int at first. The compiler wants to now that you creat a variable the type is not importend at that moment. Thats why most new languages like go or scala have the type after the inizalisation.
  - masklinn 16y ago
    > int i = 0 not code because modern compilers don't need to know about int at first. Where "modern" means "any non-utterly-stupid compiler built in the last 40 years or so".
- tjarratt 16y ago
  I suspect this is an artifact from their stance on mutable state, and some inspiration from more functional languages. There certainly isn't much harm in being clear where you are initializing variables. I would say that using actual english words rather than brief non-words such as def or var makes the syntax more readable. If the keyword really bothers you that much, couldn't you fork the project and perform a global find/replace? (yes I realize that _maintaining_ a fork like that could be nightmarish, but the point still stands)

brlewis 16y ago

Scheme/Lisp compilers already allocate variables on the stack when it's safe to do so. It isn't always safe to do so. The part about "lambda-blocks w/o heap allocation" describes a missing feature, not an innovation in concurrency or efficiency.

whakojacko 16y ago

This seems to be fairly similar to Go. Given I don't know too much about either, what are the major differences?

masklinn 16y ago
See their FAQ: *Have you seen this Google language, Go? How does Rust compare?* Yes. Rust development was several years underway before Go launched, no direct inspiration. Though Pike’s previous languages in the Go family (Newsqueak, Alef, Limbo) were influential. Go adopted semantics (safety and memory model) that are quite unsatisfactory. - Shared mutable state. - Global GC. - Null pointers. - No RAII or destructors. - No type-parametric user code. There are a number of other fine coroutine / actor languages in development presently. It’s an area of focus across the PL community. tl;dr, Rust seems to not ignore the last 20 or 30 years of computer science.
- supersillyus 16y ago
  Indeed. Go seems inspired by the last 20 or 30 years of computer engineering (it is built from concepts that have been proven to work (and often not work) in the past), and Rust seems to take into account the last 20 or 30 years of research. In my view, Rust has more potential, but Go is a safer bet, at least until Rust has been used for a fair bit of Real Code (tm).
konad 16y ago
Go has users

phalanx 16y ago

Looks like ReadWriteWeb is looking to DZone for inspiration. Amazing how my article about some 'old news' generated so many spinoffs. http://java.dzone.com/rust_language http://java.dzone.com/rust_language

DjDarkman 16y ago

It looks a lot like JavaScript, maybe we could fix up JavaScript instead of inventing a whole new language. I'm just saying...

mbrubeck 16y ago
The key people behind Rust are also on Mozilla's JavaScript team (one of them is Brendan Eich, the creator of JavaScript), and they are active in the ECMA process that's defining ES5 and ES Harmony, which are "fixed up" versions of JavaScript. Firefox 4 contains one of the first implementations of many of the improvements in ES5. But high-performance JavaScript VMs and rendering engines are not written in JavaScript; today they are mostly written in C++. Rust is designed by and targeted at the people implementing the VMs. It's the language they hope to use to implement future JavaScript compilers.

bryanlarsen 16y ago

Kudos to Mozilla. The chance of failure for this project is very high -- there's lots of new languages coming out all the time, and existing languages have huge infrastructure advantages. It's nice to see organizations take a flyer on something that has the potential to really make our lives a lot better. Rust's design decisions make much more sense than Go. Rather than designing C+++, they've ditched shared mutable state, a global GC and null pointers, and the stupid parts of the C syntax.

joe_the_user 16y ago

It may be that we'll see more languages in the future rather than seeing more language consolidation. As Moore's Law for processor speeds hits a wall, programmers are going to have an incentive to take advantage of the parallel/multi-core CPUs that are appearing in lieu of actually faster CPUs. Parallel programming is inherently less general-purpose than single threaded programming - there are a narrower range of things that you can do really quickly. I'd suspect that even doing that narrower range well will be more dependent on the memory/communications/threading model you use. If this is true, it seems logical that we'll see a wider variety of languages in the future rather than having things consolidate. One language might better for simulation, another for 3D manipulation, etc. I'd also imagine chip-makers would start to look at the languages which can target The standard Von Neumann architecture has allowed the general purpose computer to be relatively dominant product (even purpose built-machines often just leverage general-purpose chips). Parallel architecture would tend to allow the reappearance of purpose-built machines so-designed from the ground-up with all the differentiation that this world previously had.

freeflygeek 16y ago

I cannot believe that in the age of multi-core and distributed computing on the cloud, programming languages are still being designed with for-loops and iteration as the basic construct?!? Good luck parallelizing that!