Rust Programming Language Reaches 1.0 Alpha

c0d3g33k writes: Rust, a new a systems programming language with a focus on safety, performance and concurrency, has released the 1.0 alpha version of the language. This means that the language and core libraries are feature-complete for the 1.0 release. In practical terms, this means that the rate of change experienced by early adopters will slow down dramatically and major breaking changes should be very rare (during the alpha cycle some major changes may still occur if considered necessary). The language will stabilize further when the beta stage is reached (planned for six weeks from now).

Comments

Obligatory

[NeoGeo64]

I'm a bit Rusty on the subject. Pardon?

Re:Obligatory

[phantomfive]

Well, here is my non-humorous commentary. (I actually don't think I have a sense of humor). According to them, the primary goal of the language is:

Rust is a modern systems programming language focusing on safety and speed. It accomplishes these goals by being memory safe without using garbage collection.

ok, sounds like a great goal. How do they do that? If you read their tutorial, you won't find out for a while, they distract you with a discussion of their build system, versioning system, and package manager (that's a warning right there: a package manager should not be integrated into the language. Also, do we really need yet another package manager? And if you're actually looking for stability, avoid a language that is so focused on versioning: it's a sign they're not going to be stable).

The way it ensures memory safety is by assigning 'ownership' of an object. If two pointers point to the same thing, only one of them is allowed to change it. This is an interesting idea, and is probably especially useful when working with threads. Memory management is mainly done with smartpointers, like C++. (I also kind of like how they separate macros from generics).

Overall to me the language looks primarily based on C++, an attempt to smooth out the rough spots of C++, with a bit of Erlang thrown in (pattern matching). You might say that 'D' language was an attempt to improve on C++98, and Rust is an attempt to improve on C++11. It's like D for the new era.

To me, it's not a clear improvement over C++. For example, here is some code to read a line from input. Each of those function calls return a different object, you can't just type io::stdin().read_line(); The constant switching between return values is a bit mind-numbing for me, not only do you have to remember what functions to call, you have to remember what they all return. Kind of painful.

let input = io::stdin().read_line().ok().expect("Failed to read line");

Re:Obligatory

[Anonymous Coward]

It'd be "just type io::stdin().read_line()" only if you don't care about error handling, and not caring about error handling is pretty much the opposite of their design goals.

Actual analog of that expression wouldn't be "io::stdin().read_line()", it'd be more like
try {
        input = io::stdin.read_line();
} catch(exception &e) {
        cerr<<"Failed to read line";
        terminate();
}

In C it would be even uglier, with manual checking of error codes and all.

Re:Obligatory

[SkepticalEmpiricist]

> Overall to me the language looks primarily based on C++, an attempt to smooth out the rough spots of C++,

It's like C++, but where segfaults are impossible. In C++ (and C) you might try to return a pointer to a stack-allocated object:

        X * foo() {
                X x;
                return
        }

Any decent compiler will warn you that this is buggy. But that's only because it's a blatant bug. It's possible to write much more subtle bugs, which lead to the same problems, but which modern C and C++ compilers will miss. As well as accessing stack variables after their valid lifetime, you might free some heap memory twice, or not at all, and so on.

(Disclaimer: I have essentially no real experience with Rust, but have followed it's development a little.)

Rust will not allow you to compile the program until it can prove that your program is safe, that you are not abusing the lifetime of anything. This allows us to have performance and safety without compromising on either. The language also limits at most one variable at a time to have write access to a given object, this is good for concurrency also (well, even single threaded code would benefit from this). Basically, you just write C++-style code, but instead of having to convince a code review commitee of the safety of your code, you can just say "the compiler accepted it, therefore certain safety guarantees can now be assumed".

For example,

        Circle * foo() {
                Circle c1(5);
                Circle c2(10);
                return biggestCircle(&c1,&c2);
        }

We know that would be invalid, but a C++ compiler wouldn't see any problem. The Rust compiler, on the other hand, can see that the lifetime of the return object of biggestCircle can be no longer than the lifetime of either parameter.

I am gradually becoming incredibly excited about this feature. But it's going to be interesting watching the future of the language. This kind of feature isn't appreciated unless you're an experienced C++ developer. So we might find that lots of important software, from rocket ship code to web browser code, is written in Rust in future but we might find that most people don't understand why! It will be kind of like C++ for many people, they dismiss it when they are new to software, but ultimately everyone goes to C++ (or, in future, Rust) instead! :-)

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

Re:Obligatory

[IamTheRealMike]

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.

Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.

In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.

If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.

Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.

Great!

[Anonymous Coward]

Just the other day I was remarking how few programming languages there are.

Re:Self-defeating name

[phantomfive]

I think you gave the primary reasons there.....a bit of a learning curve, and not as powerful as Photoshop.

Re:Self-defeating name

[Tailhook]

Everyone uses "golang" due to this. It works fine.

Re:Rust is pointless because has a garbage collect

[Jeeeb]

A safety systems programming language sounds great but they had to ruin it by putting a garbage collector in it. This makes it useless for systems programming.

No they didn't: http://doc.rust-lang.org/compl...

Most will want to wait for 1.0, or at least beta

[drewm19801927]

I have been using rust during development and eagerly awaited this release. Please be warned, however, that rust has a steeper learning curve than most languages, and be especially warned that the language has been changing faster than the documentation can keep up during the push towards alpha. Last I checked, even things as core as the names of the integer types differ between the documentation and the implementation. I want people to get excited about the language, but I don't want anyone to get an unnecessarily bad initial impression!

Re:It's about time

[shutdown -p now]

Rust is specifically not designed to be a "meets all your needs" language. It's a language that knows its niche well, and sticks to it.

Basically, this is programming language for systems and other low-level stuff done right. It competes primary against C++, and to a lesser extent, C, and does it really well. It's not yet another scripting language for the web or desktop GUI or some such, and it doesn't pretend to be one.

Rust in an interesting language

[complete loony]

I'm not completely sold on the syntax, but I find the design and runtime interesting. I'd like to find an excuse to build something with it, to see if it can live up to its potential.

I started thinking about how I would design a language recently, then I came across rust, and I saw quite a lot of the same conclusions I came to myself. Abstract classes, multiple inheritance, Interfaces with versioning, combining 3rd party libraries... With rust, you define the layout of memory without inheritance, and the implementation of interfaces for types without defining the layout of memory. Neatly side-stepping some of the issues faced by other languages.

All resources and object lifetimes are managed, avoiding .NET's IDisposable. You can combine structures together, which can exist exclusively on the stack, avoiding the "everything is an object on the heap" problem that Java seems to fall into.

Since there's no NULL, there's no NullPointerException. There's no unchecked exceptions, or any exceptions at all for that matter. Though, I might prefer to have them. Sure, there's the try! macro. But that's just syntactic sugar for checking the return code of every function.

Re:Device drivers ?

[Narishma]

http://zinc.rs/

Re:Rust is pointless because has a garbage collect

[c0d3g33k]

From your link:

1.8 No constructors

Functions can serve the same purpose as constructors without adding any language complexity.

How many good OO language exist without constructors? Maybe only javascript. This seems like a terrible decision.

Or maybe an informed one. Go and Rust -- objects without class

Besides, Rust isn't an "OO" language. It's a multi-paradigm language that supports pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles. After 40+ years, a growing opinion seems to be that pure OOP isn't without its problems, and other approaches may fit development goals better. I'm not sure multi-paradigm languages are the answer (there seems to be a huge potential to be confusing, IMHO), but OOP isn't the evolutionary pinnacle of language design that the last few decades of hype would have us believe. I'm willing to give this approach a chance (and I'm always up for learning something new).

Critcisim of the OOP paradigm

(Aside: Not quite sure why, but the use of the term "paradigm" multiple times makes me feel slightly icky for some reason. Probably due to it's misuse in business jargon.)

Re:Rust is pointless because has a garbage collect

[TheRaven64]

Objective-C and Smalltalk also don't have constructors in the language, they merely have them as conventions in the standard libraries, which are adopted by most third-party code. There's no reason for constructors to be special, they're just methods that initialise the object and return a pointer / reference to it, and which (by API contract) may have undefined behaviour if used on an already initialised object.

Re:Device drivers ?

[c0d3g33k]

This Rust language is yet another flashy thing that will not get anywhere.

That remains to be seen. I've heard the same thing said about email, the internet, Linux, Java, the iPhone, tablets and many other things over the years. The truth is that in a viable and vibrant marketplace of ideas, many things fail but some survive, and predicting which is hard. Give it a chance to fail or succeed on its own rather than condemning it in the womb, and be glad you live in a time where people have the enthusiasm and energy to try new things. Your attitude leads to stagnation.

Re:Most will want to wait for 1.0, or at least bet

[drewm19801927]

The "guide" and the "guides", recently merged into "the book", actually are professionally maintained by a Mozilla employee, who is doing a great job but is of course outnumbered by the rest of the devs making language changes. Among other things, "alpha" is a chance for him, not to mention writers of external libraries, to get fully caught up with the development branch before beta and eventually 1.0.

Re:Rust is pointless because has a garbage collect

[phantomfive]

The worst criticism IMO from your link is the "study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches." That's really depressing.

Re:Not dependently type

[TheRaven64]

Existing compilers can handle that. It was a big focus of research for Java compilers 20 years ago, now it's a solved problem. You don't need to know that the sizes of two arrays are the same. Performing LICM on bounds checks is very common, and can sometimes be done by the language front end.

I have a student doing a miniproject (coursework for the MPhil compilers course, not his MPhil project) to implement this for Julia so that it can perform polyhedral loop next optimisations in code that's bounds checked. The basic approach is very simple: you hoist the bounds checks out and insert a single check for the largest bound and a branch on the result. If that check passes, you jump to the original loop, otherwise you fall through to a clone of the loop with all bounds checks removed. The compiler can optimise this aggressively, because it has few branches in it. You statically predict that branch as not-taken and ensure that the cold path (where a bounds check will fail - you're going to be doing expensive and slow things on that path anyway, so you don't care if it's slow) is emitted somewhere where it won't pollute your cache (you can even outline it as a new function and put it on a different page so you it won't be pulled from disk unless you hit it).

The only time that this is a problem is if another thread is able to change the length of the array. Rust makes it easy to statically check that this is not going to happen. Changing a language to make life easier for compilers based on 20-year-old designs is never something that I'd recommend.

Re:Safety?

[ChunderDownunder]

Type inference frees one from the boilerplate of, say, Java while maintaining static typing. You still get type safety in compilation.

It's the basis of functional languages such as ocaml and haskell.

Have a read about Damasâ"Hindleyâ"Milner typing.