Rust 0.2 released

https://mail.mozilla.org/pipermail/rust-dev/2012-March/001511.html

by erickt • 14 years ago

132 95 14 years ago

mail.mozilla.org

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?

naner2• 14 years ago

I believe it is supposed to be for whatever replaces Firefox/Gecko.

fusiongyro2• 14 years ago

Odd, because their FAQ is quite clear about this:

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

https://github.com/mozilla/rust/wiki/Doc-project-FAQ

kibwen7• 14 years ago

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

neilc• 14 years ago

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.

sciurus• 14 years ago

That link is worth its own HN submission.

zobzu• 14 years ago

It might be interesting to write a sing-like OS with rust (sing#) as well.

adrusi• 14 years ago

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?

kibwen7• 14 years ago

Er, it was actually five days overdue. :P

Fortunately, most of the changes in this version were internal rather than user-facing, and the few user-facing changes (classes, regions) are still somewhat half-baked. Not much new to learn at all. :)

gnuvince2• 14 years ago

So many interesting languages, so little time :(

vrotaru• 14 years ago

A language Don Juan, are you?

duaneb• 14 years ago

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

btipling• 14 years ago

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

Arelius9• 14 years ago

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.

masklinn3• 14 years ago

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)

akavlie2• 14 years ago

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

heretohelp5• 14 years ago

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.

akavlie2• 14 years ago

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

damien• 14 years ago

From the language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ

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.

GFKjunior• 14 years ago

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.

heretohelp5• 14 years ago

Just learn C.

canop_fr• 14 years ago

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

Arelius9• 14 years ago

I'm not really sure that Rust is quite ready for much usage yet, always worth a try, but some simple things are still pretty hard.

kibwen7• 14 years ago

It's good to understand the underlying systems concepts in general (such as "what is the difference between heap allocation and stack allocation?"), but you don't necessarily need to know C to grok these concepts. However, C is still a good language to know, or at least be familiar with.

As to Rust, there are still a few essential constructs missing from the language, so if you're looking for a gentle introduction you'd probably be better off waiting for 0.3 (scheduled for release in "about a month") or 0.4 (probably due to be released in three months or so).

msie• 14 years ago

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

lemming• 14 years ago

I love the idea of Rust, but...

Shorten 'mutable' to 'mut'

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

sparky• 14 years ago

Is it worse than shorting "integer" to "int" or "begin scope" to "{"?

Arelius9• 14 years ago

I think your first point is valid, but Punctuation has other advantages, the symmetry between {} and the distinctness of the symbols (Taller than most, for instance) provide other advantages for the later.

cpeterso4• 14 years ago

The ret and crust keywords also irk me.

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

someone132• 14 years ago

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

oscilloscope• 14 years ago

In JavaScript we have function, when we could be having fun.

obtu5• 14 years ago

The syntax could be made much better by focusing on usability and readability. It seems unimportant at first, but I know people get turned off functional languages because of this, and people go so far as to maintain alternate syntaxes and toolchains for Erlang, OCaml, JavaScript. Take a page from one of the “executable pseudocode” languages and their very clean syntaxes.

rdtsc4• 14 years ago

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

willvarfar7• 14 years ago

Well ideally you want both?

One can be built on the other, and it being built by the platform rather than the coder would be a big plus. Lets hope mailbox abstraction turn up in the next release.

rdtsc4• 14 years ago

I think there is a semantic difference. Each actor has one mail box. So when sending a message to it, the message is sent to the pid (address) of the actor. So the actor become the central abstraction without the need for channels.

To emulate that with channels it is like saying you have one default channel created for each task. Instead of sending a message to the task, it is sent to a channel and instead of just a simple receive, the task has to has a reference to the same channel.

Another way of thinking about it, it is like having a graph of components and one model emphasizes the nodes (actors) and the other emphasizes the edge (channels) as the central abstraction.

jamii2• 14 years ago

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.

rdtsc4• 14 years ago

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.

Arelius9• 14 years ago

It's actually really consistant with the rest of their decisions. Ports channels are much more primitive then mailboxes/messages, and yet, still safe. Mailboxes can then simply be a library built on top. This makes less assumptions.

digitalzombie• 14 years ago

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?

mkup• 14 years ago

GC per lightweight thread does not imply stop-the-world approach as in Go.

Also process is heavier entity for OS kernel in comparison to thread (address space, file descriptors are all per-process objects, not per-thread, thread is just a unit of processor time scheduling). Chrome tabs are processes for security reasons. Chrome trades speed for security in this context.

nimrody• 14 years ago

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

obtu5• 14 years ago

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.

zokier• 14 years ago

Firstly, while I'm not very familiar with Erlang or its runtime, afaik Erlang processes are not actual OS processes.

Secondly threads were originally created as a cheaper alternative because spawning processes was too expensive (on Windows). The original reason for Chrome using processes was that processes gives you memory protection. But I don't know how much it really helped them in the end, because they quickly noticed that using one process per tab doesn't scale. Thus Chrome (at least originally) limited the maximum number of processes to ten.

obtu5• 14 years ago

The costs of threads vs processes are identical if you're prepared to put some stuff in virtual memory (except on Windows, and I don't know if that has improved). Processes default to full isolation, threads are the reverse, but Rust has enough compile-time guarantees that it can do its own isolation for most purposes. I imagine they could go back and forth on this one without breaking source compatibility.

jcla1• 14 years ago

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

Rust 0.2 released

Related Stories