Mozilla releases version 0.1 of the Rust programming language

http://mail.mozilla.org/pipermail/rust-dev/2012-January/001256.html

by pcwalton • 15 years ago

236 82 15 years ago

mail.mozilla.org

In case you're wondering why we need another programming language, this short audio clip from Brendan Eich is great:

http://www.aminutewithbrendan.com/pages/20101206

"With Rust, what Graydon has been trying to do is focus on safety and also on you could say concurrency -- the actor model which I've spoken about recently - and the two are related in subtle ways."

pfraze• 15 years ago

What's the target platform? Looks like it compiles to system-executable, but Mozilla was involved, which makes me wonder if there's browser execution.

azakai• 15 years ago

System native executables: Win32, OS X, Linux, etc. This is a language for (among other things) prototyping browsers themselves, not running stuff inside browsers.

pavlov• 15 years ago

It's basically a planned replacement for C++ as the language used to program the Mozilla apps themselves (and native add-ons). It wouldn't make sense as a scripting language that runs on Mozilla.

kibwen2• 15 years ago

If anyone decides to give Rust a spin and is compelled to help out by providing feedback, the devs love to hear comments and criticism from users of the language:

https://mail.mozilla.org/listinfo/rust-dev

Chirono2• 15 years ago

Do you know if there is any explanation of 'unique pointers' and 'unique closures' anywhere? I'm quite interested to see some of the decisions, especially wrt the type-system.

zokier• 15 years ago

I do not know about unique closures, but afaik unique pointers in Rust are similar to std::unique_pointer in C++ (with some syntax sugar).

starwed• 15 years ago

One of the devs keeps a blog, and he has a post about implementing unique closures. (There are several posts on the topic actually, since I guess the idea evolved a bit with time. Just check out the Rust category for more...)

http://smallcultfollowing.com/babysteps/blog/2011/12/16/impl...

richdougherty• 15 years ago

Unique types are used to guarantee that only a single reference is ever held to a value. Sort of like the value has a single "owner". This restriction, while a maybe bit of a pain to program with, gives the compiler permission to do clever things.

In particular:

1. The compiler can detect when a value is no longer "owned" (referenced) by anything and free it automatically -- without garbage collection. That's really handy for things like closures where the compiler automatically allocated the memory for you in the first place.

2. If an immutable value is modified then a copy usually needs to be made. But if the immutable value is uniquely-referenced then the compiler can reuse the old bit of memory, thereby saving a copy operation. It can do this because it can prove the old memory can no longer be accessed.

3. I think Rust might also use uniqueness when sending values between its tasks. Since it can prove the value will no longer be referenced by the old task the compiler can avoid copying the values while still preserving isolation.

http://en.wikipedia.org/wiki/Uniqueness_type

kumarshantanu• 15 years ago

They should consider moving the discussion to Google Groups or something. Not everybody loves to read the discussion threads via email.

mapleoin2• 15 years ago

I've always found mailman's web interface a lot easier to read than Google Groups. e.g.: https://mail.mozilla.org/pipermail/rust-dev/2012-January/thr...

AFAIK Google Groups don't even support threads

freehunter• 15 years ago

I grew up with computers in the 80s that didn't have Internet connectivity. I didn't get Internet access at home until 2005. Mailing lists confuse the hell out of me.

protomyth• 15 years ago

Is there a reference manual anywhere?

samth2• 15 years ago

Reference here: http://doc.rust-lang.org/doc/rust.html

Tutorial (probably better at the moment): http://doc.rust-lang.org/doc/tutorial.html

capnrefsmmat2• 15 years ago

There's a language reference and a tutorial:

http://doc.rust-lang.org/doc/rust.html

http://doc.rust-lang.org/doc/tutorial.html

kibwen2• 15 years ago

The technical reference manual: http://doc.rust-lang.org/doc/rust.html

The friendlier language tutorial: http://doc.rust-lang.org/doc/tutorial.html

kristianp• 15 years ago

Original HN thread here: http://news.ycombinator.com/item?id=3491557

https and http links should be treated the same for de-duplication purposes, although this thread has a few more links, and points.

swah• 15 years ago

Implementation partially in OCaml! (But why don't we use Ocaml again?)

driax• 15 years ago

As I understand the first (development) versions was in OCaml, but now the compiler is completely self-hosting.

jamii• 15 years ago

> But why don't we use Ocaml again?

Rust offers better control over memory layout, more predictable resource usage and a fuller concurrency model. If it works out it will be a good replacement for ocaml, especially for systems development.

pjscott2• 15 years ago

Also, the syntax of Rust is less frightening for people who don't know Ocaml.

gnuvince2• 15 years ago

Rust is also natively unicode-aware. OCaml is not.

InclinedPlane2• 15 years ago

Maybe I'm crazy but it seems like a lot of these recent new languages are missing the mark. If you're designing a language from the ground up why wouldn't you build unit testing as a first class citizen, for example? As well as profilling and instrumentation. How about a modular compiler that can round-trip back and forth between raw source and commented parse trees so you can do much smarter merging in source control?

So many languages seem to be aiming at targets that are pretty far away from the major pain points for the normal developer.

pcwalton2• 15 years ago

Unit testing is a first-class citizen in Rust. You can annotate functions with #[test] and they become unit tests. You can then run tests with the built-in test harness on a module-by-module basis.

Profiling and instrumentation are possible using the standard tools (xperf, Instruments/DTrace, perf/oprofile). Rust works just fine with those.

Not sure what you mean by "round-trip back and forth between compiled code and commented parse trees", but Rust contains a pretty-printer which preserves comments.

nwmcsween• 15 years ago

Can you clarify a few things, these are bikeshed issues but they bother me none the less.

* Why was fn foo(bar: int) -> int chosen and not fn foo(bar:int): int? * Why annotations within comments? Annotations aren't comments it smells of C bolt-on. Why not keyword annotations?

InclinedPlane2• 15 years ago

In my view that's still just bolted on unit-testing, though very thoroughly and seamlessly bolted on, I'll give you that.

What I want are tools that help manage the complexity of unit testing, built-in where it makes sense. For example, creating mock objects and ensuring they are reflective of what they are mocking is difficult. Imagine if you could take the built-in asserts and the unit-tests for a component and use them (or some tagged subset of them) as a spec. for automatically creating mocks. Imagine if determining unit-test coverage and which tests should be run based on code changes was automatic and trivial. Etc.

Certainly profiling can be performed on any binaries provided you have symbols for them, but is that really the best we can do? I have a hard time believing that adding support for instrumented binaries at the compiler level isn't a good idea.

What I mean by "round-trip between code and parse trees" is the ability to have easy access to parse tree structure either in code or to external tools. So that you can do things like easily build in refactoring support to IDEs, or to more intelligently merge code changes at a higher level than merely lines of text in a file.

Of course, none of these ideas are anywhere near fully baked, they would require research, experimentation, and a lot of hard work. But I'd rather see people pushing the boundaries of programming languages with novel research rather than just throwing yet another mashup of already existing features out into the wilds in hopes it'll survive.

tikhonj2• 15 years ago

I've always believed that a language should have as little native as possible; the more you can off-load into a library, the better because it lets people extend the language in the language.

Why have first-class unit tests when they could be built on top of some other feature? If tests are part of the language, then using a different testing system (say something in the style of QuickCheck) would probably be at a disadvantage; if you have a language that can support expressive testing as a library, then it would be possible to add different styles of testing.

jbellis• 15 years ago

brson2• 15 years ago

Tests are mostly built-in to make sure there's no excuse to not test, but it is intended to be minimal and that other test frameworks can build off it (though it's not clear exactly how yet).

haberman4• 15 years ago

As a die-hard C guy, Rust is the first "new systems programming language" since Cyclone and D that I didn't immediately dislike. A lot of really interesting ideas in here. I'd love to know what Mozilla uses this for internally.

That said, it's hard to imagine anything displacing C for me. Almost any systems code I write these days is something I'll eventually want to be able to expose to a high-level language (Lua, Python, Ruby, etc). To do that you need code that can integrate into another language's runtime, no matter what memory management or concurrency model it uses. When you're trying to do that, having lots of rich concepts and semantics in your systems language (closures, concurrency primitives, garbage collection) just gets in the way, because you have to find out how to map between the two. C's lack of features is actually a strength in this regard.

I do really like Rust's expressiveness though. The pattern matching is particularly nice, and that is an example of a features that wouldn't "get in the way" if you're trying to bind to higher-level languages.

alexatkeplar• 15 years ago

Can you elaborate on what (if anything) you immediately disliked about Go?

haberman4• 15 years ago

I dislike duck typing; I much prefer to have an explicit declaration of what interfaces you are implementing. I also think the type system is too dynamic for a systems language (eg. their answer to generics requires run-time type checking for every operation).

Also, just as a gut-level reaction I didn't feel excited about any of the expressiveness that Go offers (compared with my reaction to Rust's pattern matching, which to me is a clear improvement over how you'd express an equivalent thing in C or C++).

shadowmint2• 15 years ago

Hi there! This is a thread about Rust. Please don't try to de-rail it with a conversation about Go.

arctangent• 15 years ago

I've only recently started to look at D as a number-crunching language, but it certainly sounds like you know a bit more than me here.

Let me ask you a question or two: is there anything at all that makes it possible to interface D with Python? I'm aware of PyD [1] but it looks like it only worked with D1.

If I wanted to stick with D and Python, would it be the case that I'd have to (re-)write something like PyD from scratch, or is there a simpler approach?

[1] http://pyd.dsource.org/

TylerE• 15 years ago

If you don't mind writing a little C, that could serve as a bridge, since both runtimes can speak C.

shadowmint2• 15 years ago

I agree, and they've done an excellent job with the tutorial documentation for it: http://doc.rust-lang.org/doc/tutorial.html

I particularly like the natives and testing support, but I agree with what you said; I wish there was a way (maybe there is and I just haven't figured it out yet) to do a reverse native thing; that is, create a C wrapper around a rust library (and then yes, use SWIG to generate a python / ruby / etc. binding for the rust library).

zem• 15 years ago

what did you dislike about ats? i've just discovered it and it seems pretty exciting to me.

mcpherrinm• 15 years ago

A bit of Mozilla commentary: There is no "internally", really -- it's an open organization. So you can find out!

The answer, unhelpfully, is that so far the only significant rust program is its own compiler.

There's people who want to experiment with writing new browser stuff in it. Not sure how serious that is, and I bet it's pretty far off before you see Firefox shipping with Rust code.

itsameta4• 15 years ago

The emphasis on memory-safety suggests to me that they'll eventually be encouraging plugin authors to use it.

kombine• 15 years ago

I think your approach is wrong all together - D actually allows you not to use 2 different languages in your project, specifically one high level and another one low level. The whole idea is that language is flexible enough, that it allows you to both write performance critical and high level code when you need to. That saves you all the troubles of interfacing, different runtimes and so on.

haberman4• 14 years ago

My project only uses one language: C.

But my project is a library whose functionality I want to expose to any language that cares to write wrappers for it. Reimplementing libraries in every language is a waste of effort and will have worse performance than sharing a single C library across many languages.

jon62• 15 years ago

The language looks ok. If they are going for world domination a more likely path seems to be evolving C very slowly. That is they should start from C and then every few years add a few new features and take out some old crummy features until they finally reach Rust.

Lots of people probably don't like rewriting code bases wholesale and new languages take a while to become trusted.

aaronblohowiak• 15 years ago

> and take out some old crummy features

Backwards-compatibility is held extremely dear to the C community, with those few breaking changes being simple (usually) to work around. If you want to break compatibility, you have a better chance calling it a new language.

jon62• 15 years ago

Thats true, but new modes can be added with switches similar to how gcc has -std=c89, -std=c99 and whatnot. Newer modes could disable old features and people could upgrade at will.

enneff• 15 years ago

How can you build trust in a language that changes all the time?

riffraff• 15 years ago

as a point of thought: you could have a language where you introduce small changes incrementally, and a tool like go's gofix that is builtin and goes over an existing code base updating stuff that is obsolete.

The current approaches of "leave the things substantiatlly unchanged" and "release a bunch of changes all together" have not exactly been proven "the best".

dain• 15 years ago

If anyone from Mozilla reads this, - http://github.com/mozilla/rust/issues.

Is an invalid URL. You put the period inside the last </a>. You should toss that out :)

markwong2• 15 years ago

And we have Ada.

mulander• 15 years ago

Honestly, I am observing closely the way some new system languages evolve - D, Go, Rust and I see a large intersection of features with Ada.

I am always amazed that no valid discussion/comparison of those languages and Ada erupt in these threads :( Ada is not as bad as it's painted to be.

markwong2• 15 years ago

i find Ada is a good and consistent programming language.

Hemospectrum2• 15 years ago

Ada has a reputation for being dramatically overengineered, especially among programmers with exposure to Ruby or Haskell (or Lisp, naturally). I've never seen a demonstration of how well it works for rapidly prototyping code and "filling in the blanks" iteratively. Would you mind providing examples?

supersillyus• 15 years ago

Does anyone have a link to some examples of non-trivial Rust programs? It looks like a pretty neat language (despite making a few more distinctions than I tend to care about), but I'd like to see how it reads in practice.

gnuvince2• 15 years ago

I guess the Rust compiler is the most non-trivial Rust program at the moment. You can start there. I've been reading the lexer and parser code (cause I've got to write those for a class) and it's very easy to follow.

mbrubeck• 15 years ago

Here's a discussion of a ray tracer written in Rust:

https://mail.mozilla.org/pipermail/rust-dev/2011-December/00...

and here's the source code on GitHub:

https://github.com/brson/rustray

marshray3• 15 years ago

I liked the part about 'immutable by default'.

I would love to have that in a language (as long as the 'mutable' keyword was something shorter :-).

rmoriz• 15 years ago

If you reinvent the wheel you should at least have one plausible use case that shows the benefit of your square/wheel over existing solutions.

Bonus points for real world examples.

samth2• 15 years ago

Imagine Firefox, but without segfaults, and using multiple cores.

That's the use case. Rust is intended as a safe language for building a research browser that works in parallel.

mapleoin2• 15 years ago

I find it really interesting that Rust itself requires all these languages to compile:

    g++ 4.4 or clang++ 3.x
    python 2.6 or later
    perl 5.0 or later

Does anyone know why that is?

gizzlon• 15 years ago

Looks like mostly building scripts (documentation, tests ..)

Guess they expect all platforms to have Perl and Python these days..

fzzzy2• 15 years ago

The perl dependency is from LLVM. Rust uses Python for utility scripts, "Just Because."

Also, you left rustc off the list of languages required to compile rust. :-) It's self-hosted.

nixarn• 15 years ago

They need to learn from Google how to present a new language. Although maybe they will once it reaches 1.0. When Google showed off Go they had some really great examples and a clean web page for it. Got me excited, this hasn't.

Edit: Apparently there is http://www.rust-lang.org/

stewbrew• 15 years ago

"They need to learn from Google how to present a new language"

You mean like choosing a name that is easy to search on the internet?

Mozilla releases version 0.1 of the Rust programming language

Related Stories