

Rust 0.2 released - erickt
https://mail.mozilla.org/pipermail/rust-dev/2012-March/001511.html

======
MatthewPhillips
Rust definitely seems cool as a no-compromises systems language. Why is
Mozilla developing it, though? What is the intended use? Supposedly it will be
used by Firefox, but for what? Rendering? JavaScript compilation?

~~~
kibwen
Its singular goal is to be an awesome language for writing next-generation
browser engines. If it just so happens to _also_ be a really, really exciting
systems programming language, that's just a plus.

The browser engine in question is called Servo, and initial discussions of its
design have only just recently begun. See more here:
[http://smallcultfollowing.com/babysteps/blog/2012/03/28/serv...](http://smallcultfollowing.com/babysteps/blog/2012/03/28/servo-
design/)

~~~
neilc
_Its singular goal is to be an awesome language for writing next-generation
browser engines._

Well, per the FAQ: (<https://github.com/mozilla/rust/wiki/Doc-project-FAQ>)

    
    
      What is this project's goal, in one sentence?
    
      To design and implement a safe, concurrent, practical, static systems language.

~~~
jk4930
Then they should use Ada. If it's good enough for high integrity applications
in space, transportation, or banking, then it's certainly good enough for
browsers. ;)

~~~
batista
You know, there are some things that --to me-- absolutely identify a newcomer
to this programming/computer thing.

One is the belief that it would be to good to write everything in assembly
(from OSs to browsers to games) so that it would be faster. See they heard
that assembly is faster and lower-level, so "the more the merrier, right"?

Another (that you don't get much nowadays, but there was a time in the early
90's that was very common) was this fascination with Ada. Mostly because of
all the marketing and BS articles at the time. The reasoning here was "well,
if they use that for missiles and F16s, it must be the best, right?"

~~~
JulianMorrison
Ada is good because of _useful_ typing (such as the ability to say "apples and
oranges are both represented as signed 32 bit integers, the allowable range
for apples is 0..5, and you can't mix them"), strong control over data
representation, standardized extensions for on-the-metal programming and hard
real time, built in synchronous message passing concurrency, and just
generally being an awesome language. It's also good because of SPARK Ada,
which is an ultra-safe Ada subset plus annotations and supports extensive
static checking.

None of this require buying into marketing hype.

It's bad because the language is large and some parts feel out of date, the
memory management is more complicated than it ought to be, and compilers are
thin on the ground and often expensive. Targeting C at a new machine is _much_
easier than Ada, and this is probably the main reason why it lost.

~~~
jk4930
My personal guesses why Ada lost: In (Western) academia was a massive dislike
of Ada because of its DoD roots and NATO applications, so they didn't use it
for teaching. And hackers disliked it because it was a committee-designed
language and it's pretty restrictive (even paternalistic) and directed toward
mediocre programmers (a good decision for systems that run over decades and
have big, changing teams assigned to it).

What was meant half-joking (that they should use Ada for the browser) becomes
better the more I think about it. When I look at Rust's design goals, I find
that Ada 2012 fulfills them (at least superficially). Additionally: if users
have to learn Rust as a new language, then they can use Ada anyway (which has
a good track record, while there's no experience with Rust's possible quirks).
And I guess if they ask AdaCore to include certain features as add-ons to
their GNAT compiler, they'd do it or assist (because for fun and for the
publicity that Firefox uses Ada).

~~~
cpeterso
> _In (Western) academia was a massive dislike of Ada because of its DoD roots
> and NATO applications, so they didn't use it for teaching._

DARPA funds lots of computer science research, so I doubt academic dislike of
DOD is a big factor.

~~~
jk4930
From what I know in Europe, the military background was a relevant issue.

~~~
batista
In Europe maybe. In the US, hardly. We're talking early nineties, not the
sixties. In the IT academia there were hardly any leftists that would oppose a
language on the basis of it being used by the DoD.

------
duaneb
This language makes my knees go weak. A system language with a haskell-like
type system? Yes please!

------
rdtsc
> Now that we have spawned a child task, it would be nice if we could
> communicate with it. This is done by creating a port with an associated
> channel.
    
    
       let port = comm::port::<int>();
       let chan = comm::chan::<int>(port);
       task::spawn {||
        let result = some_expensive_computation();
        comm::send(chan, result);
       }
       some_other_expensive_computation();
       let result = comm::recv(port);
    

Why not let the task have a mailbox and send messages to it like in Erlang? Is
it because of the desire to have typed channels? I like everything about Rust
so far except this choice. I know Go does the same, but I consider Erlang's
approach a lot more elegant and less verbose.

~~~
jamii
After a couple of years of writing erlang full-time, tying mailboxes to
processes is one of the things that really bugs me. It conflates mutable
state, addresses and queues into one construct. Using channels allows multiple
writers/readers per queue, passing the channel as a first class value and
allows transparent task restarting without needing global address registration
per task.

~~~
rdtsc
I disagree. I think tying both together produces a new abstraction -- the
actor. Not having it that way, offers little more than a thread and a bunch of
queues.

Presumably you could still use a queue to provide the semantics you want, even
now? Or have another actor that acts as the queue. But I think that use case
doesn't warrant decomposing actors into channels and tasks.

~~~
kibwen
I believe the idea here is that the language would provide an actor construct
as a member of the standard library, built using the concurrency primitives
demonstrated above.

------
GFKjunior
I don't have a lot of experience with systems programming but want to play
around with Rust.

Would the best route be to learn C then move onto the untread waters of Rust?
I'm just looking for some guidance, this seems really cool to learn.

~~~
canop_fr
If you want to play, just play with the toy that looks the most fun. Don't
plan for the best route, take the most interesting one. There will be enough
occasions in your coding life to be serious and not be given a choice...

------
msie
I had trouble trying to just read from stdin. Actually I couldn't do it before
I got frustrated and gave up. I hope I can do it this time!!! If not, then
I'll wait for 0.3!!!

------
adrusi
COME ON!!! I literally JUST finished downloading and reading the docs for rust
0.1 an hour ago. I mean a new version is cool, but could it have come a day
earlier?

~~~
gnuvince
So many interesting languages, so little time :(

~~~
vrotaru
A language Don Juan, are you?

~~~
gnuvince
It is a curse; I'd love to settle on a nice language, but the hunt is just so
exhilarating!

------
btipling
So the garbage collection is optional? That's cool.

~~~
Arelius
Sorta... many types have a more strongly enforced ownership style lifetime
scope, but depending on the data you are declaring, the collector may come
into action automatically.

Basically, Rust makes it easy to avoid the collector by clear ownership rules,
but still provides a collector for the cases where that just won't do.

~~~
masklinn
In previous threads (can't remember if it was here or on reddit), Rust
developers noted that Rust currently needs a GC for many things, but part of
the Region works is aimed at removing that need (aka unless the efforts fail,
you should be able to use Rust 1.0 sans GC)

~~~
pcwalton
Rust actually doesn't have tracing GC; it instead uses reference counting and
cycle collection. The major things that have stopped us from tracing GC so far
are LLVM issues; I'm working on those now and we'd like to introduce optional
tracing GC soon.

My personal thinking is that the standard libraries should avoid the GC and
use regions, reference counting should be achievable through a "smart pointer"
type in the standard library, and GC should be provided if the programmer
wants it.

------
lemming
I love the idea of Rust, but...

 _Shorten 'mutable' to 'mut'_

Seriously? Are we editing with TextEdit in this day and age?

~~~
cpeterso
The _ret_ and _crust_ keywords also irk me.

In ye old time Unix tradition, the Rust developers favor extreme brevity. :)

~~~
someone13
Yeah, I found "crust" to be rather counter-intuitive. I think one of the
reasons that bugs me is that "ret" and "mut" don't have any intrinsic meaning
in English, but my brain insists on reading "crust" as if it were a word.

I'd personally have gone with "rustc".

~~~
kibwen
"rustc" is how you invoke the compiler from the command line, that's no good.
:)

I do seem to remember that the devs were passively soliciting ideas for a
better name for this keyword. The great thing about a language at this stage
is that if this _really_ bothers you, then you can petition to have it
changed!

~~~
cpeterso
How about _externc_ , hinting at C++'s _extern "C"_ for C++ code that will be
visible (unmangled) to C code?

~~~
someone13
I actually like that a lot - relatively short, to the point, and doesn't have
any conflicting intrinsic meaning.

------
akavlie
Rust seems very similar to Go. Anyone looked at/played with both enough to
offer some wisdom on the pros/cons of each language?

~~~
heretohelp
It makes fewer compromises than Go. It'd be more appropriate for concurrent,
high performance systems projects, whereas Go is a way to rapid-dev high(er)
performance networked services.

~~~
akavlie
What sorts of compromises does Go make (that Rust does not)?

~~~
heretohelp
Pertinent to what I said? Garbage collection is the biggie. Utterly
unacceptable in systems work.

~~~
rntz
Both Rust and Go have GCs. It _is_ true that Rust has mostly per-thread GC,
which should help to curb performance concerns quite a bit. And Rust aims to
have more explicit control over where things are allocated. But it's still a
GCed language.

Whether GC is acceptable in systems work depends on what you construe as
"systems work" (kernels and GC don't mix nicely; browsers and GC is OK if
you're careful).

~~~
kibwen
I'm not an expert systems programmer by any means, but I think that Rust makes
a distinction between garbage collection, reference counting, and its region
system. There are ways to allocate structures in memory using any of those
systems depending on your needs.

If you're willing to be unsafe, it should be possible to avoid most (any?)
overhead from automatic memory management. Here's a quote from one of the Rust
developers:

 _"So we basically use the runtime for three things: (a) the task system,
which features lightweight threads like Go or Erlang; (b) stack checks and
growth; (c) garbage collection. We used to use it for more, but lately more
and more stuff has been moved out of the runtime to be written in Rust itself.

"I'd like to see a 'runtime-less Rust' myself, because it'd be great if we
could implement the Rust runtime in Rust. This might be useful for other
things too, such as drivers or libraries to be embedded into other software.
(The latter is obviously of interest to us at Mozilla.) Rust programs compiled
in this mode would disable the task system, would be vulnerable to stack
overflow (although we might be able to mitigate that with guard pages), and
would require extra work to avoid leaks, but would be able to run without a
runtime.

"If anyone is interested in this project, I'd be happy to talk more about it
-- we have a ton of stuff on our plate at the moment, so we aren't working on
it right now, but I'd be thrilled if anyone was interested and could help."_

------
digitalzombie
Why didn't they do GC per process like Erlang instead of GC per thread?

I thought processes and sub processes are cheaper to spawn then threads?
That's the reason why Chrome tabs are in per sub processes right? Instead of
threads?

~~~
nimrody
Erlang's style per-process garbage collection requires (or at least favors)
passing messages by _value_ between processes.

Both Go and Rust - being relatively low level - prefer passing pointers
(references) rather than the data itself. This requires a shared GC heap.

No free lunch...

~~~
obtu
Rust actually has multiple heaps with their own lifetime characteristics so
that they can avoid GC in many cases, and that the only GCed areas are per-
thread.

------
jcla1
I like the language. But since I have been working with lots of Coffeescript
lately it feels really weird using braces!

