> While we cannot promise that this is the last time there will be incompatible
    > changes, the great majority of anticipated language-level changes are
    > complete in this version

1: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no...

This is much different than what we're seeing with the evolution of, say, JavaScript or PHP. There, the languages are pretty horrific to begin with. Any "improvements" tend to be yet another hack layered upon one or more earlier hacks. Even in the best cases, these "improvements" are merely bringing JavaScript and PHP to where many other languages were 10 or 20 years ago (if not going back much earlier).

I think the fact that Rust is already so coherent makes these improvements and refinements much more impressive. It's much harder, and requires more real innovation, to improve something that's already great to begin with. Yet that's exactly what we're seeing with Rust.

From dictionary.com:

1. in the literal or strict sense: What does the word mean literally? 2. in a literal manner; word for word: to translate literally. 3. actually; without exaggeration or inaccuracy: The city was literally destroyed. 4. in effect; in substance; very nearly; virtually.

Notice definition #4.

Harmony (ES6). Isn't it obvious?

>or revisions (jsnext, asmjs) that IE won't ever adopt.

Seeing that MS caught up in the Javascript JIT game, offer Node.js for Azure, and added HTML5 features, SVG, CSS transformations and even WebGL in the latest IE head why would you say they'll never adopt JsNext?

Heck, even them adopting asm.js is not much of a stretch.

This is how you do an announcement right: you include a short description of the product along with the announcement. This way people who don't know WTF Rust is are immediately brought up to speed.

Learning the different types of pointers was a real pain point for me; so I'm very thankful for this post. Maybe it will help you out while you're learning!

[0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...

[1] http://static.rust-lang.org/doc/tutorial.html

[1] http://www.rust-lang.org/

But, as far as I understand, the goal is to not change the syntax much from now, and actually get it 'frozen' by 0.7.

Two things: It's for 0.5 (I'll be updating it to 0.6 later today/tomorrow) and 'for Rubyists' means I assume you don't know anything about systems programming, there's very little that's Ruby-specific.

http://www.rustforrubyists.com/

Then put out the same book with a new title, "Rust for Pythonistas". Two books for the price of one!

Primarily, this was an experiment in 'selling your byproducts'.[1] I'm already self-publishing a book on Hypermedia APIs[2], and the older system it was in couldn't handle my new requirements. I also wanted to learn Rust, and so I decided to just write it all down as I went. It also enabled me to get familiar enough with my new tooling that when it came time to port over DHAs, it wasn't bad at all.

So yes, doing the same thing 'for other languages' would be fun, and if Rust continues to take off, I might give it a shot. I'm already planning on writing more content for the book as I go; I've been working on a Rust buildpack for Heroku...

1: http://37signals.com/svn/posts/1620-sell-your-by-products 2: http://www.designinghypermediaapis.com/

http://www.infoq.com/presentations/Rust

The tutorial is also pretty good (as are the supplemental tutorials), but they don't yet give you the full picture. For that you'll have to play and experiment and read some code.

You might start here for some code to read:

https://github.com/pcwalton/sprocketnes

C++ -> Rust

C -> Go

Java -> Scala

Lisp -> Closure

Erlang -> (Go or Scala)

Javascript -> (Too Many; Dart, et al)

(Edit: Formatting)

Most of C's use cases, Go can't even remotely be used for. It's basically limited to the "network server" use case. It's not portable, it's not a linga franca (via FFI for non-C languages), it's not low-overhead, it's not runtime-less, ...

> Erlang -> (Go or Scala)

Yeah... no, especially not Go. In Erlang's inception, concurrency was first and foremost a tool for reliability (from its telecom roots where 1 = 0, so 1 server means the same as not having a server). Just about none of Erlang's reliability mechanisms are present in Go.

I've been using it to perform research. I also used it to build an X window manager. Neither are remotely close to a "network server" use case. In years past, I would have used C for both projects.

> Just about none of Erlang's reliability mechanisms are present in Go.

I certainly agree that Go shouldn't be viewed as a "better" Erlang, but Go does have green threads with M:N scheduling, which is a significant feature of Erlang. (As argued by Joe Armstrong himself.)

And Go also has integers, a significant feature of C...

Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.

Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.

So does every other language. Perhaps I need to be more explicit for you: Go does have green threads with M:N scheduling, which is a powerful feature of Erlang that most other languages do not have.

> Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.

I'm more convinced by Armstrong's argument [1] (and my own experience). Green threads enable a concurrent style of programming that is not viable in most other programming languages. (See also: Concurrent ML and Concurrent Haskell, although the former is not parallel.)

> Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.

I have drawn on an important similarity between goroutines and Erlang processes. I did not dispute their differences, although I think your comparison is overly simplistic.

Also, you ignored my rebuttal to your claim that Go's "basically only use case is network servers." Any particular reason why?

[1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...

I dunno. Some obscure languages are float-only. There's one called ECMAscript which I hear gets used in a few places.

[1] - http://lua-users.org/wiki/NumbersTutorial

edit: yes, I just edited this comment quickly in succession.

The JavaScript one has stuck with me because it's another good example of the various camouflaged toe-stubbing obstacles left scattered about the design.

Generalisations are excellent sarcasm-bait.

Go comes with a VM. It lives in its own world, it cannot live in the worlds of other VMs like C can. It's more like high-performance Python (or simpler+slower C++) optimized for concurrent network services.

I'd say that Rust and probably D are good candidates for replacing C.

See /usr/lib/x86_64-linux-gnu/{crt1.o,crti.o,crtn.o,gcrt1.o,Mcrt1.o,Srct1.o}.

(EDIT: VM -> runtime)

To expand upon that point, Rust is designed to allow the programmer to avoid garbage collection altogether, if the programmer chooses. I believe that makes feasible the idea of using a runtime-less subset of Rust in any application where C would have been traditionally used.

http://brson.github.com/2013/03/10/embedding-rust-in-ruby/

And even in the case of CISC processors there might be microcode playing the role of a runtime.

Why don't people learn about compiler design nowadays?!

Even the kernel has a runtime, in a less strict sense, provided by the BIOS and whatever CPU interrupts support it.

The only thing that a program can do without any "runtime" at all is warm up your desk.

+1 Funny

Because the C kind of runtime isn't what people regularly mean with the word "runtime" -- much less cpu microcode.

That said, does Forth have a runtime?

It depends if you mean one of those Forth CPUs there were common in the 80's or the more standard Forth environment, both of which have nontheless runtimes.

Because in the end, you will be using a set of words besides the basic stack manipulation ones, those words are the runtime.

The web site is an afterhought that sits like an interloper on the GNOME site. The Windows distros are years old, etc. It's too bad. They had a good idea; they just failed to execute.

    C++ -----
             \
    OCaml ------> Rust
             /
    Erlang --

    C ---------------
               \     \
    (CSP) --> Limbo ----> Go
                     /
    Modula ----------

They didn't try to improve they removed features such as error handling, distribution, all which are very important for building fault tolerant system.

Paradoxically perhaps, I see it inverted:

(Go + Scala) -> Erlang

Temporal sequencing doesn't necessarily imply strict improvement.

I'm not sure Go try to replace C. Most (all?) embedded systems need to control memory allocations.

Are you aware that there are embedded systems coded in GC enabled languages?

It is all a matter of the available resources.

I'd say, it's all a matter of the guarantees. Guarantees are everything in embedded systems.

http://www.militaryaerospace.com/articles/2009/03/thales-cho...

This is just one example from many I can pick up, this one is Java, but there are systems done in other GC languages as well.

But I do agree it is a matter of hardware resources and if hard or soft real time guarantees are to be expected, just that not all embedded systems require real time processing.

In that sense, one could also use Go. But that is a bleak argument.

I'm aware of the existence of "real time Java". There can be such a thing because of specifications like " areas of memory that are not subject to garbage collection, along with threads that are not preemptable by the garbage collector" [1]. Like I said... guarantees....

[1] http://en.wikipedia.org/wiki/Real_time_Java

There are embedded systems being coded in Basic, Oberon, Lisp, Scheme and .NET.

Although those systems are usually 32 bit based. 8 and 16 bit systems are too small for those languages.

Ada suffered from lack of available cheap compilers back in the 80's, and like Turbo Pascal and Modula-2 it was a victim of UNIX's success, which had the sad side effect of promoting C for systems programming, with all security issues we have nowadays.

Now with the work of GNAT Core, and more security conscious developers, Ada seems to be getting new users, at least here in Europe as more universities adopt it. It is already a constant presence at FOSDEM in the last few years.

http://e.ubmelectronics.com/audience/eetnewsletters/02-19-20...

That's a good time to advertise for http://www.ada-europe2013.org/ in June. :)

There is no single "Lisp", but many dialects including Common Lisp, Scheme (and its bazillion variants), Clojure, Emacs Lisp, Arc...

> Java -> Scala

Except for the fact that Scala is based on the JVM and partly reuses the Java standard library (for interoperability reasons), the language is the product of many influences, including ML, Haskell, Java, Scheme, Eiffel... The syntax and the "feel" of the language is actually quite far from Java thanks to its functional side.

http://www.paulgraham.com/fix.html

Man, am I the only one who really doesn't like implicit things like this?

For example:

    struct MyType { … }
    impl MyType { pub fn foo() { … } }
    mod my_module { pub fn foo() { … } }
    fn main() {
        MyType::foo(); // works
        my_module::foo(); // works too
    }

[This was for RC though]

Simple things like declaring fixed vectors won't compile for me: `let numbers: ~[int, ..3] = [1,2,3];` fails to compile saying it expected `~[int * 3] and got ~[<VI2>]`. That's an example straight from the tutorial.

I'm getting segfaults when iterating over a non-fixed vector of owned elements casted to a trait. (This works fine if I access the elements directly; or use managed pointers. With owned pointers my `len()` method returns the wrong number of elements, which I suspect is breaking the iterators.)

There are several known compiler bugs with any trait types other than `@Trait`. Please do continue to file any bugs you find, though—all crash bugs are bugs that need to be fixed :)

I compiled release-0.6; and sure enough `let numbers: [int, ..3] = [1,2,3];` compiles.

`let numbers: ~[int, ..3] = ~[1,2,3];` does not compile on my system though. Ditto for the @ sigil.

(Expected `~[int * 3] but found ~[<VI2>]`)

My understanding is that the first example [from the docs] allocates the vector on the stack.

My uncompilable examples should be equivalent except that they use the heap for storage.

Is there a reason this shouldn't compile?

Thanks so much for the reply!

    let numbers: ~[int] = ~[1,2,3];

For e.g: `fn foo(bar: ~[int, ..3]) { ... }`, and the compiler would enforce that you only pass vectors of length 3 to that function.

But since I can't get `~[int, ..3] = ~[1,2,3]` (etc.) to compile that seems to be impossible w/ vectors on the heap?

fn foo(bar: (int, int, int)) { ... }

Time to upgrade.

Just as a side note, I am looking forward to the day I won't need to recompile LLVM as well.

It even makes sense as an faux-etymology.

Rust: because it's close to the metal and brings some breathing oxygen to the stale system's language arena...