
Two years of Rust - steveklabnik
https://blog.rust-lang.org/2017/05/15/rust-at-two-years.html
======
brandur
I'm consistently blown away by just how good the project management for this
language is. It's not just the forward progress that the language is making
(which is considerable), but also just how well they package the information
up into a form that the rest of us who are not involved day to day can digest,
like has been done here.

Another example is the "This Week in Rust" newsletter which takes progress
that would've taken you hours to read about yourself, and puts it into a
succinct format that you can get through in minutes [1].

The Rust 2017 roadmap which targeted forward movement on all the language's
weakest features was admirable in itself, but even moreso is how much progress
has already been made. In particular, I'm really excited about incremental
compilation, which is showing as much as 5x speedups in early results [2].

I was also very happy to hear that the Rust team acknowledges that regardless
of how performant they are, futures are _not_ a particularly ergonomic or
maintainable way to write code, and are considering what new constructs might
look like over the longer term:

> _Over the rest of this year, we expect all of the above libraries to
> significantly mature; for a middleware ecosystem to sprout up; for the
> selection of supported protocols and services to grow; and, quite possibly,
> to tie all this all together with an async /await notation that works
> natively with Rust’s futures._

I'm still on dabbling in Rust, but I'm fairly convinced that in another few
years after this Tokio churn has gotten a chance to settle down and the async
patterns are more broadly refined, there won't be many justifiable reasons to
_not_ write new projects in it, whether they're as low level as a Postgres
extension, or as high level as a DB-backed HTTP application. It seems to have
an almost perfect compromise between performance, safety, productivity, and
ecosystem.

[1] [https://this-week-in-rust.org/](https://this-week-in-rust.org/)

[2] [https://blog.rust-lang.org/2017/05/15/rust-at-two-
years.html...](https://blog.rust-lang.org/2017/05/15/rust-at-two-
years.html#rust-should-have-a-pleasant-edit-compile-debug-cycle)

~~~
sillysaurus3
_I 'm still on dabbling in Rust, but I'm fairly convinced that in another few
years after this Tokio churn has gotten a chance to settle down and the async
patterns are more broadly refined, there won't be many justifiable reasons to
not write new projects in it, whether they're as low level as a Postgres
extension or as high level as a DB-backed HTTP application._

Not being hindered by the compiler telling you what you can and can't do;
freeing yourself from the write-compile-debug cycle, reducing it to repl-done;
etc.

~~~
brandur
> _Not being hindered by the compiler telling you what you can and can 't do;
> freeing yourself from the write-compile-debug cycle, reducing it to repl-
> done; etc._

Yeah, I certainly understand various language trade-offs, but in my experience
any of these early wins of interpreted languages come back to haunt you at
significant cost.

I saw someone use the analogy of a credit card on here before: purchases are
very easy to make, but have to be repaid in full, and without perfect
discipline you'll be paying interest on top. Now consider most development
teams (who are generally strapped for resources) like middle-class earners who
don't make quite enough to pay back that balance every month. It starts to
accumulate, and the owed interest compounds.

Compilers can do a lot to ensure high productivity and a good user experience:
(1) be fast, (2) have great error messages, and (3) be easy to use (no
makefiles or heavy build systems). Rust's compiler has learnt from the
mistakes of its predecessors in other languages, and does all these for you.

~~~
sillysaurus3
_Yeah, I certainly understand various language trade-offs, but in my
experience any of these early wins of interpreted languages come back to haunt
you at significant cost._

If you understood the wins of untyped languages, you'd be aware that this is
often the most optimal path for a startup to take. Get features done now + fix
them later is, in hundreds of cases, the way that startups win.

It's also a win for people who come home from work and want to get features
done on their side projects rather than write perfect code.

It's beginning to get tiresome to continually hear the Rust community go on
and on about how amazing Rust is and say, with a straight face, that
eventually there will be _no reason to write anything in not-Rust_. Are you
serious? The hubris is off the charts.

If your language doesn't have a REPL, your language is less productive. Deal
with it.

That said, the engineering tradeoffs are often a win. I love Rust; borrow
checking is frankly incredible. But it's important to keep perspective.

~~~
zzalpha
_If your language doesn 't have a REPL, your language is less productive. Deal
with it._

Oh hardly.

As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and
a few others besides, a REPL is the one thing I use the _least_. I've honestly
never understood the obsession with it.

Is a rapid compile-run-debug cycle important? Absolutely. If I want to test
something in isolation, being able to rapidly turn out a UT to prove my code
does what I think it does is incredibly important.

But a REPL is a nice-to-have. Nothing more. Treating its absence as some
fundamental black mark on a language is completely absurd.

~~~
sillysaurus3
I tend to agree, but being able to have a REPL at all is a symptom that your
language is capable of an extremely fast compile-run-debug cycle.

In other words, if you can't implement a REPL, that's the definition of "less
productive language." It's not about the REPL itself but the capability of
implementing one.

Think about it like this: On your list of languages, which of them would you
say is most productive? It depends on the context, certainly: libraries,
familiarity, etc. But let's assume the languages had identical ecosystems, and
that you were competent in all of them. Which of them would take the smallest
amount of time to write your feature?

That'd probably be Python, Haskell, or even Perl. It seems very difficult to
argue that Rust would top them. And the reasons why this is might be true are
worth examining.

Here's another aspect. Is the Rust community claiming that the entire history
of computing has lead up to this point, where Rust exists, and now nobody
needs to write anything in not-Rust? Are people 200 years from now going to
write Rust and nothing else? How about 20? 2?

It becomes very difficult to argue that your programming language is _the_
lingua franca of the future. (And that's probably true for every language, not
just Rust.)

~~~
derefr
Why must productivity be measured in "smallest amount of time to write your
feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the
feature over the project lifecycle"?

Some projects are written as explorational prototypes or MVPs. I don't think
anyone is saying Rust is much good for those.

But (numerous) other projects are written as "the first real Quality
implementation of [well-known problem], using a decade's experience with other
implementations." Much of the common software we use—{server daemons (HTTP,
SSH, DNS...), parsers and encoding libraries (for XML or JSON; JPEG or PNG;
MP4 or MKV...), databases, load-balancers, distributed queues, ...}—fits this
paradigm.

If you're writing Nginx, or Redis, or djbdns, you aren't "adding features" out
of some agile user-story kanban; you're carefully _implementing_ a small,
curated set of well-known, well-understood features, with much research done
to ensure that you arrive at the _best_ and _least fraught_ implementation,
the one that will make people prefer your software for its _quality_ and
_reliability_ and _set-and-forget nature_.

Rust is for _that_ kind of software. (Which makes sense, given that Mozilla's
Servo rendering engine _also_ has the goal of being that kind of software.)

~~~
cwzwarich
> (Which makes sense, given that Mozilla's Servo rendering engine also has the
> goal of being that kind of software.)

Web browsers are not that kind of software. The web is evolving much faster
than any of the other things you mentioned. New features get proposed every
year, and you just have to deal with it and implement them, even if they
complicate the implementation of the browser. Even if you cut that off, you
still have to deal with the horrific mess that is the cumulative total of past
web-related decisions.

~~~
derefr
A rendering engine is not, itself, a web browser. (You might be thinking of a
higher-level component, like Chromium's Embedded Framework? Not the same thing
as a rendering engine.)

There's certainly a _layer_ of a rendering engine—the part that translates a
CSSOM into rendering pragmas—that changes a lot over time. But rendering the
resulting pragmas itself doesn't change much, and features requiring new
pragmas come about remarkably slowly.

~~~
cwzwarich
I definitely know the difference between a browser and a browser engine; I
worked on both WebKit and Servo. There's much more to a browser engine than
rendering alone, and rendering isn't even the most complicated part of a
browser engine. Outside of rendering and JS there's a steady stream of new DOM
APIs, and that's the part that is similar to the "agile user-story kanban".

~~~
derefr
Yes? It sounds like you're agreeing with me, and disagreeing with your own GP
comment. Or maybe I misunderstood the point of your GP comment—it _sounded_
like you were trying to use some sort of metonymy to equate Firefox/browsers
in general with Servo, as an implicit counterargument to my GGP post in the
sense of "it'd be bad to write a browser in Rust for [reasons you gave]; a
rendering engine is _part of_ a browser; a rendering engine thus has the same
lifecycle as the browser itself; and thus, a rendering engine is _not_
actually a good example of a good use-case for Rust, despite Mozilla's
ambitions. QED."

Clearly, though, you know what a rendering engine is, so I'm not sure what
your argument in the GP post was. Was it just a tangential statement (i.e.
"rendering engines are well and good, but it'd be silly to write the browser
itself in Rust, for [reasons]"), rather than a rebuttal...?

------
kibwen
Yet again allow me to shill for this year's Rust Community Survey, which
closes June 12 and is open even to people who've never used Rust:
[https://blog.rust-lang.org/2017/05/03/survey.html](https://blog.rust-
lang.org/2017/05/03/survey.html) (Yes, I know it's linked from the OP, but who
reads that anyway?)

~~~
dmix
I thought that was strange survey at first, as there were very few questions
related to programming and coding with Rust but plenty of questions around
engaging with the community (inclusiveness/comfort level, conference
attendance, etc). But then I realized it was a "Rust Community Survey".

Is there another survey more suited to use Rust as a language ala "State of
Clojure"? I don't use Clojure anymore but I still love reading these every
year to keep up to date with the progress it's making.

For ex: [http://blog.cognitect.com/blog/2017/1/31/state-of-
clojure-20...](http://blog.cognitect.com/blog/2017/1/31/state-of-
clojure-2016-results)

Edit: Oh nevermind, it seems the questions change if you select 'Yes' or 'No'
at the beginning for "still using Rust". I didn't totally stop using Rust I
just spent time learning it, experimenting on some projects, but I don't have
a day-to-day need for it - not sure if either possible answer applied to me.

------
webkike
A few years ago I was a C evangelist. C++ was and more so now is a fine
language with a lot of features I want. But Rust has that simplicity in a
systems language that I crave that lets me do my own thing. That elegence.
It's my favourite language by far. Keep it up!

~~~
nickpsecurity
Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-
checked but powerful and simple. You can learn how to use them in a day coming
from an imperative or functional language. Rust looks like it gives users
extra power/safety with quite a bit of a learning curve (most say weeks to
months) due to extra complexity. Definitely not simple, though.

[https://en.m.wikipedia.org/wiki/Modula-3](https://en.m.wikipedia.org/wiki/Modula-3)

[https://en.m.wikipedia.org/wiki/PreScheme](https://en.m.wikipedia.org/wiki/PreScheme)

~~~
webkike
It's definitely simpler than most other systems languages in what it gives you
access too. Go, D, C++, C# are all far more complicated than Rust is. I would
argue Modula-3 is not as simple because it contains a garbage collector - thus
making the connection between written and compiled code less simple. Don't
know much about pre scheme

~~~
jabits
Have only checked Rust out a bit, but you mention C#. Does Rust have
functionality similar to, and as easy to use, as Linq?

~~~
zlynx
Linq, ick. It's a performance nightmare. No one knows what it is actually
doing in the background so firstly, everyone writes horrible O-cubed
performance with it, and then it is a series of random poking around to try
fixing it.

~~~
xorxornop
Depends if you're using it with ORMs or not. It's equally as useful with data
in memory. Definitely slower for some things though (yes, it's always slower
in one sense... But its also easier to make parallel, so it can even out in
the end)

Still, I now prefer doing such things in Rust.

------
lelandbatey
I'm really excited by the new edition of the rust book mentioned in the post,
from a brief look it seems that it covers all the areas I felt most needed
improvement (for example what does a "move" mean?, a concept completely
omitted from the first edition).

Also, I want to plug just how _fun_ Rust is to write once you begin to learn
how it works. It's totally awesome to write _fast_ code that doesn't segfault,
especially when it comes to things where tooling in other languages is
lacking, such as doing parallel data processing. Speaking of which, I'll
shamelessly plug some recent results from a Buddhabrot[0] renderer I wrote[1]
in Rust:

[http://lelandbatey.com/projects/buddhabrot/3k--mellowish-
fra...](http://lelandbatey.com/projects/buddhabrot/3k--mellowish-
fractal2017-05-14_14:01:47.png)

[0] -
[https://en.wikipedia.org/wiki/Buddhabrot](https://en.wikipedia.org/wiki/Buddhabrot)

[1] -
[https://github.com/lelandbatey/rust_buddhabrot/](https://github.com/lelandbatey/rust_buddhabrot/)

------
progman
Congratulations to the Rust team for the great work!

The impact of Rust on the programming safety community has grown so big that
even hardcore Ada developers are getting really nervous about Rust's powerful
competition.

[https://groups.google.com/forum/#!topic/comp.lang.ada/H35QcY...](https://groups.google.com/forum/#!topic/comp.lang.ada/H35QcYiWR1Y)

Although Nim and Lisp are still more productive than Rust for my use cases --
Rust really needs a convenient edit-compile-debug cycle, and also an easy
bootstrap from source mechanism -- I am watching Rust's development with
pleasure.

I am pretty convinced that within the next ten years Rust will not only cause
a serious decline of C++ but also eat a big portion from Ada's lunch in safety
critical applications.

------
Animats
The success stories are Mozilla's Servo, Dropbox's client and back end, and
parts of Gnome. That's good. It's interesting that all the success stories
involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?

~~~
Manishearth
The dropbox stuff isn't a mix of Rust and C/C++, it's a mix of Rust and Go[1].

(Dropbox has a variety of things using Rust, and IIRC some of them are pure
Rust. I don't remember the details.)

[1]:
[https://news.ycombinator.com/item?id=11283758](https://news.ycombinator.com/item?id=11283758)

~~~
kibwen
The OP seems to be mostly referring to the integration with Dropbox's Windows
client, which AFAIK is actually Rust+Python. Rust+Go is what Dropbox uses for
their storage backend.

I personally love that Rust is getting used to complement so many other
languages (e.g. Rust's first known production use was as part of a Ruby gem).
Easy integration is something to be celebrated, because it means you _don 't_
need to rewrite the whole world to get benefits.

~~~
Manishearth
Yeah, but none of what Dropbox did is Rust+C++ -- they're not a C++ shop, and
Rust was their go-to systems lang.

I'm very happy to see mixing like this too!

------
breerly
Curious, since I haven't been following closely - is Tokio fit for both IO and
CPU-bound work, or do you need to break into threads?

I use Golang daily, and have been spoiled by the opinionated approach taken to
solving both CPU and IO-bound workloads.

~~~
steveklabnik
In one sense, IO, and in another sense, both; that is, what you do there is
use futures-cpupool, which is a threadpool with a futures interface. So it
still all composes just fine.

------
shmerl
Nice to see a lot additions to the Rust Book (v2). Like on OOP features for
example.

------
rolfvandekrol
A 2.4MB image is bit overkill, isn't it?

~~~
mastax
You're right, I'll go fix it.

Edit: fixed.

------
mmstick
You might like to know that I've had great success with full stack web
development using Rust. My website ([https://mmstick.tk](https://mmstick.tk))
is hosted with the Rocket
([https://rocket.rs/overview/](https://rocket.rs/overview/)) web framework and
operates as a fully static binary with 100% Rust code. I've even got HTTPS and
Brotli compression.

~~~
dang
We detached this ludicrous flamewar from
[https://news.ycombinator.com/item?id=14344760](https://news.ycombinator.com/item?id=14344760)
and marked it off-topic.

You repeatedly posted uncivilly in these comments. That's a bannable offense
on HN, so please don't do it again, regardless of how wrong you think others
are.

~~~
winteriscoming
What a mess! Came to this thread to read about Rust and its progress and this
has devolved into a useless discussion about some person's website, who seems
to consider that he/she is doing all the right things and the rest of the
technical community is stupid.

Completely lost track of what thread I was reading.

~~~
dang
That's why your friendly janitorial staff detach these and mark them off topic
so they fall to the bottom. That way you only see them when there's nothing
else to read.

One of these years we might implement a "More" link at the bottom of threads
so you have to go to a second page to see them at all.

