
Mozilla Is Designing a New Programming Language Language Called Rust - hornokplease
http://www.readwriteweb.com/hack/2010/11/mozilla-designing-programming-language-rust.php
======
daeken
> 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
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.

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

~~~
burgerbrain
> * 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!

~~~
silentbicycle
The last time I checked, it was bootstrapped in OCaml. When I met Graydon
several years ago (brilliant dude, PS), he was quite intrigued by OCaml, and
strongly recommended I check it out. If ML had any influence _at all_ , it
uses variant types instead. About time more languages use them!

Rather than, "oh crap! every single variable could potentially be null _at any
time_!", the few functions that _can_ be null make you check for None / Some
'a, _and that's it_ , no tedious null checks ever again. "Null pointers
simplify a lot of error-checking.", my ass.

~~~
effn
Yes, it does have variant types and pattern matching, and an option type in
the standard library, just like ML.

Contrary to ML, it doesn't require variables to be initialized when declared.
The typestate system checks (statically) that they are not referenced before
initialized.

~~~
thesz
>Contrary to ML, it doesn't require variables to be initialized when declared.
The typestate system checks (statically) that they are not referenced before
initialized.

What's the point, then?

------
steveklabnik
Previous coverage of rust:

<http://news.ycombinator.com/item?id=1498528>
<http://news.ycombinator.com/item?id=1498233>

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

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

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

~~~
masklinn
Why would you have to specify it's an int when the compiler is perfectly able
to discover that himself?

~~~
jemfinch
Is it an int? An int32? An int64? Is it unsigned? Maybe it's actually a float
which just happens to be initialized to a valid integer value. In that case is
it a float or a double?

Literals can map to multiple types, and there hasn't yet been discovered a
satisfactory way--apart from guessing in cases of ambiguity--to support type
inference for literals.

~~~
aplusbi
That depends on your definition of "satisfactory" - F# uses strong type
inference on literals and there is no ambiguity. Of course this means that
distinguishing between types requires metadata, for example 42uy is an
unsigned byte, 42L is an int64, 42I is a bigint and 42N is a BigRational. I
think this is satisfactory, although you might disagree.

~~~
jemfinch
Sorry, I meant "inference for overloaded literals."

------
freeflygeek
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!

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

~~~
masklinn
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
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).

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

~~~
bendotc
Maybe because this guy is passionate about making a new systems language,
instead of solving the problem you want solved?

I never understand people who complain that free project X exists, when those
people could be working on Y which is obviously more important. As if
production and enthusiasm were both zero-sum and fungible.

Also, as someone who works with systems languages every day, I can tell you
that there's a need for this work. I'm not saying Rust is it, but the systems
language space is pretty dead, which is scary in a world where processors are
threatening to become parallel on scales we don't know how to deal with with
traditional tools.

~~~
kenjackson
Lets be clear, the author of the blog post asked an explicit question. If the
question was, "Can I do whatever I want, and screw what you think?", I'd
answer, "Of course you can".

But if you ask me "Do you agree?", well do you want my answer, or do you want
me to simply say, "If that's where your passion is".

My honest answer, no I don't agree. I don't think we need a systems language
of this sort. And I think there's a bigger gap that I'd like to see Mozilla
work on, although maybe this blog post author isn't the right person to work
on it.

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

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

