
Rust - a new programming language from Mozilla - grn
http://www.rust-lang.org/
======
kibwen
Please note that Rust is very alpha alpha alpha at the moment. Syntax evolves
constantly. Several concepts don't even _exist_ yet, and many are present only
in half-formed nascent states.

The bottom line is that if you're interested in writing applications using
Rust, you should really hold off until 0.4 or so (I'd say give it three
months), both to give them time to implement all the missing pieces and then
to refactor the Rust compiler to _use_ those pieces, thereby shaking out the
bugs and annoyances.

But if you're interested in helping out on writing the compiler itself, or
proof-of-concept libraries, definitely consider pitching in. The devs greatly
appreciate volunteer contributions.

~~~
kamaal
When will this ready for the real world?

I mean an actual production release?

~~~
kibwen
I guess it depends on what you mean by "ready". For instance, Go 1.0 was
released just last week, but people have been building useful things with it
for a long time now. I suppose it depends on how much instability you're
willing to put up with in order to use the shiny new thing.

As someone who follows the project closely, I do think that almost all of the
core concepts will be present by 0.4 or 0.5 at the latest (fingers crossed),
which would probably be the best time for eager early adopters to dive in.
Also consider that Mozilla will be using Rust for experimental prototype
browser engine implementations _soon_ , likely even before 0.3 is released.

But if you're looking for some semblance of stability, I'm not sure what
advice I can give beyond "wait for 1.0"--which has no definite timeframe. The
Rust devs don't even schedule minor releases more than two in advance, so Rust
might jump directly from 0.4 to 1.0, or from 0.9 to 1.0, or from 0.367 to 1.0.
But don't worry, when they _do_ make the jump, I'm sure you'll hear about it
on HN. :P

If you'd prefer to track the project milestones yourself, check out the Github
issues page[1] and browse the currently scheduled milestones from the dropdown
in the left column.

[1]
[https://github.com/mozilla/rust/issues?milestone=&sort=c...](https://github.com/mozilla/rust/issues?milestone=&sort=created&direction=desc&labels=&state=open)

------
jmilkbal
I feel like I'm beating a dead horse, but I really can not grasp what the
catalysts are for creating Rust or Go or Julia or other new languages that
want to be safe, reliable, readable, etc.. 30 years ago these problems were
solved in a language Ada. Its exact requirements include all of those and
more.

See for yourselves: <http://www.adahome.com/History/Steelman/steelman.htm>
Later revisions have well-though-out rationales that show off all the changes:
Ada 95:
[http://www.adaic.org/resources/add_content/standards/95rat/r...](http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-contents.html)
Ada 2005: <http://www.adaic.org/ada-resources/standards/ada05/> Ada 2012(!!):
[http://www2.adacore.com/wp-
content/uploads/2006/03/Ada2012_R...](http://www2.adacore.com/wp-
content/uploads/2006/03/Ada2012_Rational_Introducion.pdf)

The steelman was the end revision of requirements for the original language.
There is a comparison of C/C++/Java/Ada wrt the steelman available as well.
Ada has become so much more since this document and it's original version one
really must see it to be believe it. :o)

As a community we have a tendency to embark on projects on a whim, but the
effort, time and money required to bring a language to maturity is enormous.
Even then any deficiency a preexisting language may have surely is not so
insurmountable as to make it viable to develop a new language in house.

Can we please have some sanity? Can we please look for mature solutions?

Edit: Ada has an amazing GCC frontend developed largely by a successful
opensource company (with just massive customers across the globe) and is
available across all of its targets: the bsd's, solaris, linux, mac, haiku,
android and more. It's a great solution that is hard to ignore.

~~~
tedunangst
I've used Ada. It was a super major pain in the butt. Go is like an easier to
use C, where Ada is like a harder to use C. The solution to "people screw up
dynamic allocations" is not "make dynamic allocations brutally difficult".

~~~
jmilkbal
Ada wants to catch as much as it can before runtime. To that end, it is one
strict beast when you're used to all the willy nilly (and unsafe) constructs
that we can beat C into doing. Ada absolutely is harder; it's built for hard
problems. I don't intend to turn away from the topic of TFA, but Ada is on
quite a different plane than C for a number of reasons--reasons that I think
are compelling. C is wonderful for creating a foundation for low-level
software as it has demonstrated for what seems like an eternity, but beyond
that--and I think the crazy things we've done over time to make it a little
easier to use reflect this--something with more high-level, safe, readable,
yada, yada, yada is desirable if not absolutely needed.

Dynamic allocations in Ada are a cinch by the way. We use the "new" reserved
word.

subtype Hacker_News_Article_ID is Natural; -- Numbers 0 .. Integer'Last;

type Article_Handle is access all Hacker_News_Article_ID; -- "all" reserved
word used allows access to variables on the stack.

Favorite_Article : aliased Hacker_New_Article_ID := 3793716; -- "aliased" so
we can point to this stack variable.

Article_Pointer : Article_Handle := Favorite_Article'Access; -- A sensible
default perhaps.

later on...

Article_Pointer := new Hacker_News_Article_ID (Whatever);

Good luck!

~~~
tedunangst
What I meant by dynamic allocation was allocating an array of the necessary
size. Last I checked, the Ada solution was to always allocate the largest
possible array you would ever need every time. Correct me if I'm wrong, but in
Ada if two arrays are different sizes, they are completely different types.

In practice, this means your Ada written image viewer can show you 1000
thumbnails, but no more. Or 10000, or some other hard limit. And you can only
view images smaller than 2MP. Unless the author made the fixed sizes really
large, but now you're burning 10MB of memory per image even if they're all
tiny gifs.

~~~
xlq
This is untrue. This is an Ada declaration for a fixed-size array of Foo with
indices 1 to 10 (inclusive): type Foo_Array is array (Integer range 1..10) of
Foo; This is an array indexed by an enumeration: type Foo_Array is array
(Some_Enum) of Foo; But dynamically sized arrays can also be declared: type
Foo_Array is array (Integer range <>) of Foo; Note that such an array has a
dynamic lower bound and a dynamic upper bound. If I create an instance of such
an array and pass it to a procedure: declare My_Array: Foo_Array (3..10) begin
Do_Something (My_Array); end; then the procedure Do_Something receives both
bounds of the array, 3 and 10, which it can read with the 'First and 'Last
attributes.

A declaration like the one above is typically done on the stack (although it
doesn't have to be). An array can be allocated on the heap with "new", with,
IIRC, the following syntax: new Foo_Array (3..10)

~~~
tedunangst
Thanks for the clarification. Can you create an array with variable size
though?

    
    
        new Foo_Array(x..y)
    

That's what I couldn't figure out how to do last I tried.

~~~
xlq
Yes. What you've written is exactly how to allocate an array of dynamic size
on the heap. You can also do: declare My_Array: Foo_Array(X..Y); begin ...
end;

~~~
tedunangst
Hmm, I remember it being very hard, but it seems I've lost the specifics. My
bad. In any case, Ada is not a language I'm excited to work with, but Go could
be one.

------
zokier
Previous discussions:

* <http://news.ycombinator.com/item?id=3774075>

* <http://news.ycombinator.com/item?id=3501980>

* <http://news.ycombinator.com/item?id=3027777>

* <http://news.ycombinator.com/item?id=2390980>

------
Maro
How does Rust compare with Go?

Their goal of being a modern systems programming language are similar.

~~~
kxs
<https://github.com/graydon/rust/wiki/Doc-language-FAQ>

Has a section called: "Have you seen this Google language, Go? How does Rust
compare?"

Excerpt: "Go adopted semantics (safety and memory model) that are quite
unsatisfactory." Like Null pointers, global GC, shared mutable state etc.

~~~
Maro
Thanks for the link, I upvoted you.

I'm a C++ systems programmer, so I'm trying to understand some of the issues
here. I'm not familiar with either language, please forgive the ignorant
questions.

Null: Why is null evil? Doesn't Go use it in the Java sense of releasing a
reference to the object?

Global GC: Seems more like a runtime implementation choice?

Shared mutable state: Doesn't seem so bad for someone approaching a systems
programming language. I don't always want to make copies and send it over as a
message to the other threads?

My higher-level point is that, perhaps these languages could do a better job
of selling, differentiating, explaining themselves. I know it's hard, that's
why I'm trying to help by posing my stupid questions. Btw. if they're planning
to write Firefox in this, maybe the author should maintain a minimal browser
written in Rust to show how the language fits its original design goals.

~~~
pcwalton
Note that we don't forbid shared mutable state entirely (we don't forbid
anything really, as we have an unsafe sublanguage that allows all the pointer
tricks that you can do in C++), but we want to contain data races. Basically,
as the FAQ says, "you can break the rules, if explicit about where and how".

We've learned that, especially when it comes to concurrency, there really is
no one model that supports everything you might want to do. Instead, the idea
is to support safe, data-race-free language constructs, and to make those the
easiest ones to use. Data races (and memory unsafety) are clearly marked in
"unsafe" blocks, with the idea that if you find a concurrency bug in your
software, you can grep for that keyword and go over those blocks only, instead
of having to crawl through the entire codebase.

The same principle applies to null. You can get nullable pointers (use
option<T>), but you have to declare that that's what you want. You also have
to declare some strategy for handling the null case every time you use the
pointer, or at least communicate your intent to fail on null via the .get()
method. The vast majority of pointers in any program aren't nullable, so in
practice we've found that this eliminates a lot of bugs.

------
ses
This is an interesting new language but I'd be interested to know - what is
the motivation behind its creation?

~~~
sanxiyn
Mozilla is writing Servo, a parallel browser engine, with Rust.

[http://smallcultfollowing.com/babysteps/blog/2012/03/28/serv...](http://smallcultfollowing.com/babysteps/blog/2012/03/28/servo-
design/)

~~~
_delirium
Writing a new programming language from scratch in order to enable the writing
of a new HTML rendering engine from scratch is at least ambitious!

~~~
bzbarsky
Is it more or less ambitious than trying to take an existing large C++ single-
threaded codebase and try to multithread it without introducing bugs or
running into Amdahl's Law early on?

That's the key question here...

------
jurre
Did anyone find an explanation for why they opted for brackets in favor of
whitespace or a ruby-like syntax?

~~~
xd
Being someone that has only ever programmed in languages that use brackets, I
really, really don't get this white space thing .. it appears, to me at least
to make reading code very difficult. With brackets I can scan a page of code
and _see_ the blocks of related code.

What are the advantages to using white space?

~~~
inerte
I don't know if this will apply to you, but it's also possible to "see" the
blocks just by indentation.

If you assume that this is possible, and your eyes can get used to read code
just by its blocking, then brackets are unnecessary, even superfluous.

~~~
webjprgm
It's like becoming bilingual. When you know only English other languages are
completely confusing, but once you learn a second language you can more easily
pick out pieces of others.

If all you know is {}, then other code is harder to read. Once you learn
either a Lisp-like language or a Python-like language then you learn to see
code blocks without {}. This is what happened for me. (I was forced into
learning Scheme in school. Only after that did I decide that Python was an OK
language after all.)

------
jentulman
Can anyone explain this, from the first paragraph, to a bog standard PHP-for-
the-web programmer please?

"Its design is oriented toward concerns of “programming in the large”, that
is, of creating and maintaining boundaries – both abstract and operational –
that preserve large-system integrity, availability and concurrency."

~~~
dkarl
Some of the difficulties in large projects include:

1\. It's easy to break things accidentally, and it's hard to track down all
the usages of something when you change it. This is especially true when
functions and types can be aliased under different names, changing a class
affects all subclasses, etc. The more complex the application, the more you
get pervasive usage of types defined within the application. This is a real
change from smaller applications where most of the pervasive types probably
come from the language's standard library, which can be trusted to be stable
between major releases.

2\. A large codebase means that whatever finicky housekeeping the language
requires is almost guaranteed to get screwed up somewhere in your application.
If this affects the integrity of the whole app, it can be very bad. Invalid
memory accesses are an infamous example. It doesn't matter if you have a
million lines of awesome, feature-filled code; if one buggy line of code
crashes your app every ten minutes by dereferencing an invalid pointer, your
app is unusable.

3\. Fragmentation of types and libraries. Programmer X adds a Flugelhorn
library on one end of the app, programmer Y adds a Flugelhorn library on the
other end of the app, and nobody realizes it until incompatible Flugelhorn
types start bumping into each other in the middle. This is less of a problem
for a community where "programming in the large" means many people writing
many small independent projects, but it could be a major annoyance for a
language where the goal is to write large, complex applications such as web
browsers.

4\. Concurrency. Concurrency can be a coupling factor that requires
programmers to know too much about global design and global state. It can also
destroy performance and stability. Finally, given principle #2 above (every
large running application contains screwed-up code somewhere) runaway tasks
are a threat to the whole system if not contained. When done well, however,
concurrency can reduce coupling and improve stability.

5\. It can take a long time to rebuild a large codebase and run its tests.

I don't know much about Rust so far, but here's my stab at matching the
features of Rust against those five problems:

1\. Compile-time type checking is a big help. Rust also has some ways to
enhance types without subclassing.

2\. Memory safety, garbage collection, errors that propagate upward by
default, isolated tasks. Error handling is unappreciated in this category, I
believe. It's important that an application not accidentally suppress an error
and continue, because it could corrupt data, return incorrect results, or
behave insecurely. A language like C where errors can be swallowed through
oversight or programmer laziness is dangerous in that regard. In Rust, errors
propagate upward, unwinding the stack until they terminate a task or are
explicitly handled.

3\. Generic types help, and built-in support for Unicode text is a necessity.
It also helps that the organization shepherding the language is likely to be
the biggest user of the language. It's important to note that anything that
helps with #3 also helps with #1. For example, if the language has a standard
string type you can use everywhere, then your tests don't need to protect
against Doug down the hall (or across the world) changing the string type and
not realizing he broke your code.

4\. Immutability, message passing, isolated tasks, per-task GC. It sounds like
Rust is trying to make task isolation the default way to firewall errors off
from the rest of your app. For a web programmer, this is exactly like the way
a Java web container is supposed to work. If one web app in the container goes
haywire, the container and all the other web apps should ideally be able to
continue running without their stability being compromised.

5\. I don't know what techniques are used by Rust to speed up compilation. A
compiled language is at a disadvantage on this count, but compiling to object
code is necessary for a systems language. Also, static type checking means
drastically fewer unit tests (I don't want to start a flamewar about whether
this is a good thing; it's just the way people code) so you get a little bit
of your lost compile time back when you run tests.

~~~
kibwen

      > I don't know what techniques are used by Rust to speed up compilation.
    

From what I've observed, forcing the developers to compile the language using
itself is a great way to keep the programmers mindful of compilation speed. :)

In Rust's case, I believe the bottleneck is LLVM. You can disable optimization
if you just care about fast turnaround times, but you're always at the mercy
of LLVM to do the actual code generation. To that end, the Rust devs have
recently begun an initiative to profile the amount of LLVM IR that they
generate in the compiler, and they've made some good strides so far just from
picking the low-hanging fruit.

As far as comparisons to other languages go, I'm not sure if Rust's
compilation model is set up to be as fast as Go's, although (IIRC) Rust avoids
the template-generation step that bogs down C++.

~~~
pcwalton
We'll never be as fast as Go in compile speed: just to name a few issues, we
do flow analysis (so we check whether your variables are initialized before
you use them), our typechecking proceeds by unification (so you can say stuff
like [] and the typechecker will figure out what the type of that empty vector
is), and we have an extra IR-generating step (so we can take advantage of LLVM
optimizations). It's a question of different goals; one of Go's primary goals
was to compile quickly (which is a fine goal!), which isn't one of the goals
of Rust (although we definitely want to compile fast, of course, and we have
continuous integration benchmarks to that effect).

------
ecubed
Out of curiosity, what's Mozilla's motivation for making a new language?

Everything I'm reading here in the comments is talking about how this would be
a replacement for c/c++, but wouldn't Mozilla be more interested in a language
that's more web focused? As I see it, Rust would NOT be a web language, or am
I missing something? Is this something they would try and develop future
versions of Firefox in?

~~~
gnuvince
That latter; they want to be able to build a large and complex web engine and
have it be as safe as possible without sacrificing performance.

------
thealistra
<http://doc.rust-lang.org/doc/tutorial.html#pattern-matching>

This is the whole reason why that language has such a big potential.

It has high level algebraic datatypes with pattern matching, so you can nicely
model your control flow (like haskell or ocaml) but still remaining low-level.

------
luser001
Interesting language.

Doesn't require JVM to run. I consider that a plus. But others might not.

------
zem
rust seems to get compared to go a lot, simply because they are socially
similar (open source c-like language developed by large, popular company). i'd
like to see some comparisons with languages like clay and ats, both of which
seem closer to what rust is trying to be.

------
jorgem
Looks similar to F#

------
agumonkey
feels like ADA

~~~
Gertm
You make it sound like a bad thing. :p

~~~
wglb
Whatever its merits (and it does have a few), it hasn't exactly been a popular
choice outside of building fighter airplanes.

~~~
tbsdy
What's not to like about building fighter airplanes? :P

~~~
wglb
Odd fact about fighter airplanes: The official documentation for a fighter
airplane, if it were all printed out, would outweigh the airplane itself.

~~~
zokier
You don't see a lot of books flying around, do you :)

------
omi
Rusted before any use was gotten?

------
jchughes
The syntax is horrible. I would prefer C over that.

~~~
pcwalton
What don't you like about the syntax?

------
iamgopal
Now even I want to create a new programming language.

 _for downvoters : pun intended._

