
Rust 0.11.0 Released - veeti
https://mail.mozilla.org/pipermail/rust-dev/2014-July/010655.html
======
parley
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.

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

~~~
enneff
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](https://www.youtube.com/watch?v=a4BQRUpQoe8)

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

~~~
cmrx64
Embedded and embeddable are different things. Embeddable refers to the ability
to call code written in your library from any other environment (and these
days, over a C FFI).

------
kibwen
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](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. :)

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

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

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

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

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

~~~
pnathan
I sit in that area (SRE/DevOps/Tools) as well, and I _strongly_ believe that
Rust is a better foundational language because of the type system strength and
guarantees. Particularly useful is the `enum` type and type matching. I want,
simply put, to be able to write code that is "bulletproof" after I've brought
it to deployment, and Rust gives me some _awesome_ tools for that.

(I've also come to understand that Go is an extremely sharp tool for _Google_
's problems - the style of coding, the concurrency, the expectations of the
developers (look at the Google style guides to see the culture of development
there, there's a harmony with Go). Your harmony with Go reflects your harmony
with Google's problems).

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

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

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

~~~
kibwen
Different domains will be optimally served by different features,[1] and any
language that aspires to be usable in _every_ domain must assimilate all of
those features somehow. This is especially pernicious when considering how
similar features can overlap and interact in unexpected ways, creating a
labyrinth of corner cases with which a user must familiarize themselves. To
maintain sanity, people will start carving out bits of the language to create
"dialects" and restrict themselves to only those dialects, at which point you
have effectively created multiple languages, each with their own idioms and
learning curves.

Consider as well that as long as there exist languages that are so heavily-
laden with features, there will continue to crop up "minimalist" languages
like Go which will appeal to people by virtue of sheer simplicity and eat the
lunch of the maximalist languages.

[1] An example: you know one thing that's great about using bash instead of
Python for quick scripts? I don't need to put quotes around strings! Imagine
how much time you'd waste in your terminal if you had to type `git grep foo --
bar.txt` as `git "grep" "foo" "\--" "bar.txt"` all the time (which is valid
bash, btw), or worse, `git("grep", "foo", "\--", "bar.txt")`. TCL adopted this
barewords-as-strings behavior as well, and though I hear mixed things about
the rest of TCL this feature has always intrigued me. But this feature would
be _awful_ for any language where text input or string manipulation were not
the predominant activity, so how would you go about turning it on and off? And
even if you provide tools to automatically convert source files between
barewords-as-strings and barewords-as-keywords, is that even the same language
anymore?

~~~
lmm
> To maintain sanity, people will start carving out bits of the language to
> create "dialects" and restrict themselves to only those dialects, at which
> point you have effectively created multiple languages, each with their own
> idioms and learning curves.

Sure, scripting Scala looks rather different from high-performance Scala. But
there's a continuity between them, which allows you to customize the
appropriate "dialect" for a particular project, and avoids the overheads of
using multiple languages in a project that straddles one of the lines.

> how would you go about turning it on and off

There's already a certain level of syntax customizability in most languages,
e.g. I can use an import that will make symbols ('grep) treatable as strings.
Whether this is a single language or a suite of languages designed to work
closely together is an academic question, but I certainly think it would be
possible to write something that allowed you to write (say) C-like code and
Python-like code with a much smoother interface between them than there
currently is when calling C from Python.

------
kbd
I love all the "X has been removed from the language" bits that occur in every
Rust release.

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

~~~
jsmthrowaway
The other side of that is that D has had a long time to percolate and hasn't
found the success of Go, and soon Rust. So, we come back to the common startup
ailment, which is having an awesome product but it just inexplicably doesn't
get traction, while the inferior (depending on perspective) product does.

I know there are pockets of D throughout the industry. I know it's catching on
at Facebook (and, because I know Facebook folks, I know what an uphill battle
those folks are having too). I just don't hear about D nearly as much as I'd
expect to over a decade in.

Nothing against D, mind.

~~~
lvillani
In my opinion the fact that there were two competing standard libraries (Tango
and Phobos) certainly brought confusion and needlessly fragmented the
community.

IIRC, at the beginning the whole thing was not being developed in the open and
the compiler was proprietary (although the front-end became open source at one
point).

Those two things (especially the former) pretty much killed it for me.

D finally matured at a time where I was already more interested and invested
in the Lisp/ML family of languages, thus I ended up never considering it for a
project.

~~~
simcop2387
Those were definitely the two things that kept me from really considering it
in the past. Both of those have now changed for the better and there's a more
active community building up again. I think the facebook use of D has also
brought some much needed attention to it to the point where the language
itself is starting to accelerate changes to move forward. The DMD reference
compiler still has some restrictions on the backend of it I think but because
of the frontend being available there's now LDC and GDC that are LLVM and GCC
versions of the compiler that do much better at optimizing and are fully open
source anyway. It's also seemed to help find bugs in both the language spec
and the DMD backend from what i've read on the news groups because they've got
three very different implementations of the language now that are all mostly
compatible (the DMD version is always a little ahead since the other two are
essentially ports of it to LLVM/GCC).

~~~
WalterBright
The D front end was just relicensed from GPL to Boost. (The front end is
shared by DMD, GDC, and LDC.)

~~~
simcop2387
I knew something had changed but was unsure of the details. Thanks for the
correction.

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

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

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

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

~~~
pekk
If a feature gets released, it is for people to use it. A judicious hand with
features saves a lot of trouble down the line. If you are adding too many
features you get a big pile of features like C++. I don't see how it is worth
arguing that people developing something like a programming language need to
very carefully weigh these decisions instead of throwing everything at the
wall to see if it sticks.

The main reason to load up on features is that you are anxious your audience
won't like you unless you do, but it is a wrong idea about design.

~~~
kibwen
You completely misjudge the Rust developers. Features _are_ carefully weighed
before implementation. Developer time is not infinite. But ultimately some
decisions can only be made with experience, and sometimes (thanks to the
domino-effect nature of language design) previous decisions need to be
reevaluated as entirely separate parts of the language change. If this were
C++, we would have left all those features _in_ rather than taking the trouble
to purge them.

------
AYBABTME
I'm mostly doing Go nowadays but keeping an eye on Rust, which I think would
make a good match in my toolbox for areas where Go lacks.

Wondering if there's a roadmap/ETA for v1.0?

~~~
sp332
I found this roadmap
[https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGd...](https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGdSdEVzZW1BeDA5dm0zM2FFeW0ySEE&usp=drive_web#gid=0)

~~~
steveklabnik
That Google doc has not been updated in a while.

Also [https://github.com/rust-
lang/rust/issues?direction=desc&mile...](https://github.com/rust-
lang/rust/issues?direction=desc&milestone=20&page=1&sort=updated&state=open)

and [https://github.com/rust-
lang/rust/issues?direction=desc&labe...](https://github.com/rust-
lang/rust/issues?direction=desc&labels=P-backcompat-
lang&milestone=20&page=1&sort=updated&state=open) , which are the most
interesting open questions regarding backwards compatibility.

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

~~~
steveklabnik
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 ::.

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

~~~
mercurial
I don't know about Clojure, but . in Java is ambiguous in the grammar, since
it's also used for method calls. And . is function composition in Haskell. I
can understand why Rust would want a different sigil.

~~~
Dewie
I think I saw some proposal to replace the function composition from prelude
(.) with some other symbol, and presumably making it illegal to define
operators named (.). This would of course break a lot of code, but it seems
simple enough to make a largely automated transition.

The reason for the proposal was that (.) for function composition made the
grammar more complex or problematic because of the accessing 'operator' (.),
and/or something that had to do with more fancy accessing and such (lenses?).

------
magg
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?

~~~
steveklabnik
> 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?

~~~
magg
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

~~~
steveklabnik
Well, there are a number of web frameworks being worked on, maybe checking
them out and helping out would be a good idea?
[https://github.com/iron/iron](https://github.com/iron/iron) was on HN asking
for help the other day.

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

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

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

~~~
cmrx64
And I think that that is one of the things that sets Rust apart.

