Rust 0.11.0 Released

I think Rust has been bad for me. I'm interviewing for my first technical role at the moment and all I keep talking about is how much I love Rust and look at these cool things I made in Rust and I want to program in Rust all the time.

I mainly receive bemused looks. "We use Java."

pjmlp4• 12 years ago

If you are applying to the enterprise that won't change in foreseeable future.

Worse, Java really means Java and not any alternative language for the JVM.

shmerl2• 12 years ago

If you are applying to the enterprise that won't change in foreseeable future.

That depends. Not all are bought on the Java hype from the past but it surely is still widespread.

Mr_P• 12 years ago

You could try looking for positions doing C++ development, and specifically with companies which have embraced the new C++11 features. Rust is extremely close in style to idiomatic modern C++, but with greater static safety guarantees.

humanrebar• 12 years ago

Runtime polymorphism is very different in Rust, and sum types are prolific in the standard library, so I'm not sure how "extremely close" it is to C++11. But there are many similarities in other areas, such as memory safety through references with ownership semantics.

shmerl2• 12 years ago

I mainly receive bemused looks. "We use Java."

Yeah, that happens. You probably should just skip those places to begin with :) I second those who mentioned C++ in the comments. Those places have more chances of appreciating Rust.

chillingeffect2• 12 years ago

What platform have you been working on? Win7 works ok for me, but I've tried to install rust in Ubuntu and Lubuntu (13.10 and 14.04) and get errors during the install. I was following these directions:

https://github.com/rust-lang/rust/wiki/Note-getting-started-...

steveklabnik10• 12 years ago

If you jump into IRC[1], we can help you out with that. Most people have the opposite problem: hard on Windows, easy on Ubuntu!

I myself run Ubuntu at the moment, so I can certainly help.

1: #rust on irc.mozilla.org, or http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...

kibwen12• 12 years ago

I've been following Rust for a long time, and though I'm happy to see how popular it's become I'm also a bit wary.

When people become attached to an exciting new language, in their elation they tend to envision using it in every context imaginable. But most languages are designed for a particular (and possibly narrow) domain. As you venture further from that domain, things begin to unravel.

Example: after giving a presentation at a recent Rust meetup, someone asked me if they could use Rust as a scripting language. My response was something along the lines of, "sure, it's as Turing-complete as any other language, but why would you want to?" Mostly I would like people to acknowledge that different languages exist to serve different needs, and that there does not and will never exist One Language To Rule Them All.

Rust is a low-level systems language, and it's optimized very, very well for that niche. I'm very happy if you want to use it all time, for everything! But please continue to evaluate it as a systems programming language. There are very good reasons for every feature in the language, but many of those reasons may seem entirely superfluous if you don't appreciate the context in which they were made.

meddlepal• 12 years ago

I agree with the use the right language for the job sentiment, but most developers work for other people's businesses and engineering is just as much about designing and building something as maintaining and growing it. I can definitely see why some engineers would want a single "magic bullet" type language that can do everything from replace shell scripting to building complex distributed systems; it's easier to hire people to maintain that program 10 years down the road.

lmm4• 12 years ago

Why not a single language that scales up and down? Problems come on a continuous range; rather than an infinite number of languages specialized for every spot on the range, it's better for interoperability and tooling's sake to have one language that can accommodate many different styles of programming.

/Scala fan, would and have used it for scripting.

lvillani3• 12 years ago

I'm eagerly awaiting Rust 1.0 to play with it.

These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh".

Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :)

Keep it up!

tbirdz• 12 years ago

In the mean time you might want to check out Nimrod or D. These are some other languages in a similar space - compiling to native binaries, but with the amenities of modern languages.

egeozcan• 12 years ago

These are the exact two languages I want to see prosper.

Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing

Secondly because these languages have so many great ideas with high quality implementations.

lvillani3• 12 years ago

Nimrod looks quite interesting. Not so long ago I was discussing with a colleague how much I long for a statically typed Python with macros, sum types, optional garbage collection/ref-counting etc. Nimrod seems pretty close to that ideal programming language.

Thanks for sharing such nice little gem.

lmm4• 12 years ago

In a non-systems environment (i.e. I'm fine with garbage collection and don't need perfect performance), assuming I already know OCaml and Haskell, does Nimrod or D have a lot to offer over those?

jsmthrowaway3• 12 years ago

Same here, actually. I used to be a pretty strong proponent of Go until I used it in a mid-size project. Now I'm really hoping Rust can fill the gap, and by all indications it's looking like it will.

mbell3• 12 years ago

I keep seeing a lot of 'Rust vs Go' discussions, including in this thread. To me they seem to be targeted at different use cases. i.e. Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming. I'm curious to hear what similar use cases people are using as a basis for directly comparing them.

kibwen12• 12 years ago

I have been trying to discourage Go vs. Rust comparisons since time immemorial, given their wildly different purposes and audiences.

The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies).

As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.

jsmthrowaway3• 12 years ago

None of those reasons apply to me, and I think you're overlooking a simple one: As an SRE, I compare them because I'm looking for the next language to adopt as my primary systems/infrastructure language. I have enough issues with C++11 and Python in large systems that I'm looking for an expressive language in which I can work fast and build robust systems. Go and Rust are the finalists for that, with Python keeping the scripting side. Go just happened to finish first.

And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally.

At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.

TheHydroImpulse6• 12 years ago

I would be very interested in comparisons to Erlang. Erlang seems to be the king of reliable and fault-tolerant systems and Rust seems to have taken lessons from it.

TheHydroImpulse6• 12 years ago

They are indeed targeting different use cases.

I think a potential reason people are comparing the two is because Rust is also great (it's still early, though, so it'll be interesting where people leverage Rust) at the use cases that Go was designed for, while Go cannot touch what Rust was built for. However, the two being defined as system languages with two widely different views on what "system" means doesn't help.

loudmax• 12 years ago

I am looking forward to seeing browsers and maybe even operating systems written in Rust. Go, not so much.

I'm not so positive that Rust will be so great in cases where you have many developers with different levels of skill and experience working on infrastructure projects. Rust makes the low level stuff easy, but a lot of high level stuff is still going to be easier in Go.

dragonwriter3• 12 years ago

Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming.

Go has been fairly expressly billed as a C/C++ replacement. Now, I think that's somewhat misleading in comparison to Rust also being a C/C++ replacement, in that Go seems intended to replaces C/C++ in uses that are near the boundary where C/C++ (and, yes, Java) competes with Python/Ruby/etc. (where the former set has more of the performance characteristics sought but may be less convenient/concise/expressive, whereas the latter has the reverse features), whereas Rust is aimed at C/C++ deep in those languages prime use cases where they have little current competition -- certainly not from languages like Python/Ruby/etc. -- not at the boundary where they compete with Python/Ruby.

mbell3• 12 years ago

Go has been fairly expressly billed as a C/C++ replacement.

I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team. This is really the core of my original question, why does the community think of Go as a C replacement when it explicitly does not support the feature set required to be such a language?

Nelson69• 12 years ago

"C replacement" means a lot of things to different people.

Go doesn't appear to be particularly suited for writing a kernel or drivers, Rust looks better for that. Beyond that, if we're talking about writing user space type applications, can someone point to some that need something particularly C like? There is a whole ton of C code that could easily be done in C, Rust, or go with relatively little downside. Not too many weeks ago someone posted linux coreutils in Rust and someone else posted coreutils in go. I'd be hard pressed to make the case for C over either of those, perhaps raw cycles performance is incrementally better.

pohl2• 12 years ago

When the Go team introduced the language, they used the phrase "systems language", and the meme has stuck, even though Rob Pike has since expressed some regret about having used the phrase so carelessly. Now he thinks the phrase "cloud infrastructure language" would be more apt.

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...

(approx 6 minutes 45 seconds into the talk)

I think it will take about a decade for everybody to readjust their frame on this one, alas.

P.S. Rust's own Niko Matsakis is one of the 4 people in this panel discussion, by the way, and it is well worth watching – even though they burn maybe a little too much time struggling with the question of what does/doesn't constitute a systems programming language.

spopejoy• 12 years ago

I blame Stroustrup, who likes to throw "systems programming" or "system language" into every discussion about his baby.

It is a bad meme, it even doesn't fit for C++ given it's main application as an application language (cue Torvalds rants about C++)

TylerE• 12 years ago

I actually see it the exact opposite way - Go is C's sort-of minimalist brethren, while Rust is the more turbo-powered nuclear chainsaw of C++.

wtetzner5• 12 years ago

The thing is, Rust seems rather simple. The difference is that Rust introduces some concepts most people are unfamiliar with, like lifetimes.

alricb• 12 years ago

"I keep seeing a lot of 'Rust vs Go'"

That's unfortunate. We should be arguing about Ocaml vs. Rust or Ada vs. Go!

eklavya5• 12 years ago

There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".

steveklabnik10• 12 years ago

I'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ?

Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.

kibwen12• 12 years ago

Language design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM

eklavya5• 12 years ago

Something has precedent doesn't mean you ought to do it. kibwen explains the reason above.

dbaupp3• 12 years ago

I maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.

dscrd• 12 years ago

If it's meant to signify paths, why not use the sigil that everyone uses for path separation, i.e. /

kibwen12• 12 years ago

The reason for <> instead of [] is that both are just as ambiguous to Rust's grammar, and that <> is, unfortunately, more-or-less the industry standard (C++, Java, and soon Swift). I would personally prefer something akin to D's generic syntax (but with a different symbol, since the exclamation point already has meaning in Rust).

The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)

eklavya5• 12 years ago

Thanks for shedding the light. I really really wish they had chosen [] instead of <>. I use Scala and I have fallen in love with how clean [] looks.

Good to know the reasoning behind ::.

Waiting for Rust 1.0, after it gets released it's Scala for JVM and Rust for everything else (except Qt) :P

wtetzner5• 12 years ago

Honestly, it's kind of sad that things are chosen because they're industry standard, instead of how good/nice they are. After using Scala, I think that []'s are much easier on the eyes than <>'s.

Symmetry• 12 years ago

Man, last time I checked in on Rust one of the things that I didn't like was that the rules for what was public or private by default were complicated for no good reason. Now (maybe .11, maybe a previous change) everything is private by default which is nice and simple.

I did and continue to really like the way they handle encapsulation at the module rather than object level.

kibwen12• 12 years ago

Aside from the removal of the ~ and @ sigils (an enormously impressive effort, btw), I'm actually much more excited for the next Rust release. 0.11 contains at least a few long-awaited and hugely-important features which are only half-implemented. Specifically, both DST and by-value closures should be ready for use by the time 0.12 rolls around. We also have some very exciting RFCs in the pipe, such as https://github.com/rust-lang/rfcs/pull/141 , which would make it possible to remove 90% of the lifetime parameters from our function signatures. Also, with Steve Klabnik now working full-time on documentation and Yehuda Katz's team working on our package manager, our ecosystem will soon be much more potent.

Great job, Rust developers! As ever, the challenge is to keep it up. :)

haberman• 12 years ago

DST

This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html

grayrest• 12 years ago

at least a few long-awaited and hugely-important features which are only half-implemented

I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.

DAddYE2• 12 years ago

I agree with you, but AFAIK this is the first time we are part of a real "open development" of a programming language backed by a big company. It's very rare see clever coders change their mind when someone suggest a different approach. I'm glad this is happening and I wish more could follow.

cpeterso• 12 years ago

Now that the ~ sigil has been retired, maybe it would be used for the bitwise NOT operator like C instead of the ! operator.

Dewie7• 12 years ago

So there has been what seems to be a lot of attention on high level performant languages lately; Rust, Go, Nimrod, D. Languages that can provide performance in the ballpark of C, or at least faster than a lot of other high level languages. High level languages that still keep an eye on what can be implemented efficiently.

But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.

cmrx643• 12 years ago

One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing.

Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.

Dewie7• 12 years ago

One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing.

I was talking about them in aggregate, and not all of them seem to have that goal.

chipsy• 12 years ago

I think the key is in whether these languages get the backing of a Big Institution. Tech people are simultaneously sensitive and oblivious to the political nature of what technologies interest them: For example, all the coverage of Swift is because Apple is backing it. All the coverage of Go is because it has some famous people behind it plus the tacit support of Google. All the coverage of Rust is because it's backed by Mozilla. But when asked directly about their interest most coders will proclaim that it's simply because the technology in these things is better, even though there were plenty of languages that had similar features and implementation quality beforehand. Nobody - especially not people caught within the politics of their own company - has the time or depth of experience to be completely confident about what they would need from a new language and why, so social signalling and appeal to authority tends to rule the day: "No one ever got fired for buying IBM." And so, intentionally or no, people come out of the woodwork to position themselves as early adopters of the "next IBM."

That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.

Dewie7• 12 years ago

In the case of Rust, I think the hype actually is well-founded, technically. It is aiming for a niche that I have seen no one claim that any other language has accomplished to fill before. So unless you know of some languages that have memory safety with no form of enforced garbage collection (it's part of the library, but completely optional), I'll say that Rust has merit on its own, no matter what organization is backing it.

jamesfisher• 12 years ago

I love that when I read the changelogs for Rust releases, most changes are "Feature X has been removed from the language". These guys are serious about avoiding featuritis.

pekk2• 12 years ago

Agreed, though it would be better not to have added the features to begin with.

kibwen12• 12 years ago

If a feature gets added, it is to evaluate its usefulness. Some features make the cut, some don't. Even the ones that don't pan out are useful in that they establish precedent for people who ask for that feature later on; we need only tell them "we tried that, it didn't work out, and here are all of our notes and discussions documenting our reasons why".

magg2• 12 years ago

i would really like to use rust for a project. but i don't know what i can do with it. any ideas? or which project can i join to work with rust?

steveklabnik10• 12 years ago

i don't what i can do with it. any ideas?

Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most.

What kinds of programming do you like to do?

magg2• 12 years ago

I've used Ruby and Python and PHP for web related projects. I've used C for low level programming, Linux modules and SCADA programming running on QNX. So I guess I like pretty high level and low level programming

rmc2• 12 years ago

Work through project euler?

parley• 12 years ago

A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post:

Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.

Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.

Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".

My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.

steveklabnik10• 12 years ago

(I think!)

You are correct. The third production deployment of Rust is a Ruby gem written in Rust.

pcwalton• 12 years ago

Brad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job.

It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.

enneff2• 12 years ago

Now that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8

We'll never see Go on 16-bit architectures or smaller, though.

enneff2• 12 years ago

Providing Go code as a shared library that is linkable from other languages is not technically infeasible, it is merely difficult. In 1.4 we aim to be able to load Go programs into a host process (on Android this will enable a Go process to live in the same memory space as a Java process), and also have a more general plan for Go shared libraries.

pjmlp4• 12 years ago

Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom.

I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages.

- Expand the capabilities offered by the unsafe package

- Offer more control over the GC behavior

- Add a kind of untraced pointer or a GC API for allocating them

Rust 0.11.0 Released

Related Stories