
One year of Rust - steveklabnik
http://blog.rust-lang.org/2016/05/16/rust-at-one-year.html
======
aleksi
> While much of Dropbox’s back-end infrastructure is historically written in
> Go

I'm sorry, but much of Dropbox’s back-end infrastructure is historically
written in Python, not Go. Go is a new addition to the stack. Only a small and
very specific part of Dropbox is written in Rust, where things like an
effectiveness of CPU caches becomes important. Other back-end code is still
being written in Go.

~~~
steveklabnik
I think it depends on what you mean by "historically". My understanding is
that the server-side was largely in go for a long time now, but you're also
right that before that, it was Python.

While you're right that it's a small and specific part, it's also the core of
the whole thing, so it's a very significant part. Dropbox isn't moving away
from Go generally any time soon, as far as I know: it's still very much the
default.

~~~
aleksi
> server-side was largely in go for a long time now

I guess I call "a new" what you call "a long time now". Dropbox is using Go
for about 3 years.

~~~
steveklabnik
Yeah, maybe that's entirely it. Words are tough. :)

------
grenoire
One year since stable? It feels like five years for the level of maturity they
have achieved.

~~~
merb
Except the tooling, could be better. A language like Rust will benefit from a
rich IDE a lot.

But still the language is great.

~~~
Lewisham
I'd say rustdoc is pretty rough. It's very hard to navigate the rust stdlib
vs, say, Go, and when you do find what you want, it's often specified in some
very cryptic manner that seems to require a PL PhD.

It is a really big barrier to adoption because it's very hard to find out what
functionality is or is not offered. Here's an example: I want to iterate over
a set. Easy, right?

No.

[http://static.rust-
lang.org/doc/master/std/collections/hash_...](http://static.rust-
lang.org/doc/master/std/collections/hash_set/struct.IntoIter.html)

Look at the signature for Cycle. It's really hard to know what this does even
though it's trivial:

fn cycle(self) -> Cycle<Self> where Self: Clone

When you click through to the real documentation, it describes a useful use
case for this. But that's not how programmers think. They think "I need to do
X _right now_ so I'll find something that looks right" not "I'm going to click
through the documentation... oh X looks interesting I'll remember that later".
There's no way to infer what Cycle really does without having actually clicked
through or used it.

~~~
pcwalton
> fn cycle(self) -> Cycle<Self> where Self: Clone

I agree that a summary would be good, but this doesn't require a PL Ph.D. It
means "cycle is a method that moves its receiver and returns a Cycle object of
the same type of the receiver, and only works if the receiver is cloneable".
The trickiest thing here, IMHO, is move semantics, which is something
fundamental to Rust in general.

~~~
vvanders
Yup, I've got the same feeling here.

If you've spent more than a cursory time with Rust this is pretty
straightforward.

You'd represent this in Java(minus move semantics, because Java has nothing
like that) via:

    
    
      class IntoIter {
        public Cycle<T extends Clone> { ... }
        ...
      }
    

Where Clone is just an interface that knows how to clone its value.

~~~
Lewisham
Fair enough; some more noodling over the signature made it a bit more obvious
than it seemed banged out at the back of an OSCON presentation.

I think the point still holds. Maybe just not for that one.

~~~
vvanders
The thing is what you linked is the docs of an implementation not the
interface.

I guess I've just had a different experience. I come from almost no PL/ML
background and I've found the Iterator interface in Rust(along with
Option/Result) to be some of the most impressive, clear things about the
language.

------
_redwire
One thing I'm really hoping to see happen in Rust is more development to make
it more "functional," as in suitable for a functional programming style. It's
already _so close_ and, while I don't want to bring up the higher-kinded types
discussion, things like stronger support for closures being returned from
functions are just not quite there yet for me.

I filled out the survey that was sent around and mentioned some of my concerns
about missing crypto-in-Rust code and some of the shortcomings of the
documentation. I'm pretty happy I'm not the only one mentioning one or both of
those things, because it makes me hopeful that we'll see improvements soon. In
particular, regarding docs, I've found it rather difficult to go from reading
a type signature and brief explanation of a function/method and being able to
actually _use_ it, as a beginner. For example, when I tried to figure out
Hyper, it took me a long time to realize I could use pattern matching in my
function signatures to capture a mutable reference to something that Hyper was
giving me ownership over. I feel silly having missed that, but being a
beginner just referencing the Hyper docs, I really struggled.

Does anyone have more information about the crypto situation? In particular, I
use ECDSA 384-bit for a lot of the code I write at work and have only been
able to find the Ring library, which doesn't seem to feature signing yet. If I
could get some high-quality, audited crypto code (or heck, even just some nice
Rusty wrappers), I'd be so close to ready to use Rust at my day job and for
more personal stuff as well.

~~~
nilved
I think this ship sailed when Rust removed function purity. Rust is a Scala,
not a Haskell.

~~~
_redwire
So I'm actually not super familiar with Scala. I do know Haskell a little bit.
Could you elaborate on what you think the implications are for Rust's
development down the functional route are? I've heard about the potential for
support for higher-kinded types, which makes me think there could actually be
a strong incentive to be able to do more functional programming in Rust if
people started working on monad implementations and such.

~~~
killercup
There was a very nice comparison between the type systems of Rust and Haskell
a few days back on reddit:
[https://www.reddit.com/r/rust/comments/4jh8hv/question_about...](https://www.reddit.com/r/rust/comments/4jh8hv/question_about_rust_vs_haskell_type_systems/)

------
diminish
Hey HN, do you knoe Any notable projects or startups using Rust? Web, desktop
apps, scientific or algorithmic computing etc?

~~~
kibwen
See [https://www.rust-lang.org/friends.html](https://www.rust-
lang.org/friends.html) for a list of companies using Rust (perhaps most
notably Dropbox and Mozilla), but here are some non-corporate projects off the
top of my head:

Panopticon, a cross-platform disassembler:
[https://panopticon.re/](https://panopticon.re/)

Redox, an everything-is-a-URL microkernel OS: [http://www.redox-
os.org/](http://www.redox-os.org/)

Piston, a modular collection of libraries for game development:
[http://www.piston.rs/](http://www.piston.rs/)

Pijul, a next-gen implementation of Darcs:
[http://pijul.org/](http://pijul.org/)

Xi, a high-performance text editor: [https://github.com/google/xi-
editor](https://github.com/google/xi-editor)

timely-dataflow, "a low-latency cyclic dataflow computational model" (i.e. big
data shenanigans): [https://github.com/frankmcsherry/timely-
dataflow](https://github.com/frankmcsherry/timely-dataflow)

------
lossolo
I've tried to learn Rust twice because i think it's great idea (memory safety
with C++ performance) BUT... Rust seems even more complicated than C++ for me,
really i find C++11/14 a lot easier to reason about than Rust. I am not sold
on functional programming also. Dangling pointers/memory leaks are problems of
C and old C++ but not modern C++. I don't remember when i last seen any memory
problems in modern c++ code base where ownership is encapsulated inside smart
pointers. I think Rust is great and would have a lot more attention and
adoption if version 1.0 would ship in 2009. I think Rust is too late into the
game. That's why probably only mozilla is really using it and dropbox for
really small part of their infrastructure from known players. From what i
researched big part of "friends" that use Rust in production are using it
because of hype? I am not sure exactly why but some of their use cases for
sure not need systems programming language. Maybe it will not end up like D
which tried to solve similar problem.

EDIT: It's funny how people down vote my personal feelings about the language
without any anti-argument or comment. It seems having other opinion than "Rust
is GREAT" is not desirable here.

~~~
Rusky
Probably getting downvoted because the assertion that modern C++ solves memory
leaks is getting kind of tired as far as Rust discussions go, and is also
missing the point.

Rust doesn't solve memory leaks, it solves memory _unsafety_ \- things like
use-after-free and iterator invalidation that modern C++ does virtually
nothing to help with, and that vulnerability statistics show are still huge
problems with programs written in C++.

~~~
lossolo
I don't see usage of new/free without encapsulation, this is not modern c++
which invalidates your point. Using naked new/free is depreciated in modern
c++ and is problem of C not modern C++. What kind of statistics? Can you give
any links that support what you wrote? All memory leaks/buffer overflows that
i saw lately are associated with C (openssl, libc etc) not with C++. For
iterator invalidation there are couple of simple rules to remember or for
example you can use std::insert_iterator that will not be invalidated even if
relocation occurs. You could use static analyzer and would avoid most of the
problems.

EDIT: My point is that i have nothing to gain from rust when knowing c++ and
memory management rules + i got good static analyzer. But probably for someone
that do not know C++ at all Rust could be a better choice.

~~~
Rusky
Sticking the free in a destructor doesn't help you at all with memory safety,
it just makes it easier to avoid leaks.

Simple rules are, again according to the evidence, not good enough. There are
simple rules you can follow in C as well. The benefit of Rust (as far as
memory safety goes) is that the compiler enforces those rules.

In fact, the mechanism by which it does this (lifetimes) is typically what
makes Rust seem more complicated to beginners. But the fact is, that
complication is still there in C and C++, the compiler just lets you deal with
it all on your own.

~~~
lossolo
Yes i understand what your point is. I do not need to know/remember certain
rules because compiler is doing this for me in Rust, my point is that if
someone knows those rules in C++ and have good static analyzer he can get
similar safety.

I will try third time with Rust, i just feel sometimes like in shackles in
Rust, i would like to say to compiler hey i know what i am doing, like i can
do in C++.

~~~
pcwalton
> my point is that if someone knows those rules in C++ and have good static
> analyzer he can get similar safety.

No. The entire history of large-scale security-critical applications in C++
disagrees with you.

> I will try third time with Rust, i just feel sometimes like in shackles in
> Rust, i would like to say to compiler hey i know what i am doing, like i can
> do in C++.

That's precisely what unsafe is for.

~~~
lossolo
Once again show me something that proves what you wrote, where is your history
of modern C++ that proves that? No one provided any link.

~~~
the_why_of_y
Here's Mozilla Firefox, search for "use-after-free", "memory safety hazard".

[https://www.mozilla.org/en-US/security/known-
vulnerabilities...](https://www.mozilla.org/en-US/security/known-
vulnerabilities/firefox/)

Here's Google Chrome, search for "buffer overflow", "Use after free", "out-of-
bounds":

[http://googlechromereleases.blogspot.com/search/label/Stable...](http://googlechromereleases.blogspot.com/search/label/Stable%20updates)

Edit: Chromium bug tracker talks to me now, query for "use-after-free" has
2157 results:

[https://bugs.chromium.org/p/chromium/issues/list?can=1&q=typ...](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=type%3Dbug-
security+use-after-
free&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids)

~~~
lossolo
Once again, show me ONLY modern c++ code base. Those are mixed with old C++
code base.

Still waiting.

And read how chromium use C++11... ([https://chromium-
cpp.appspot.com/](https://chromium-cpp.appspot.com/)) + google style guide
that is prehistory and NOT considered good in community.

Maybe try with proxygen, rocksdb, folly from facebook ?

~~~
pcwalton
> Once again, show me ONLY modern c++ code base. Those are mixed with old C++
> code base.

These security flaws are in code that has used smart pointers for years and
years.

> And read how chromium use C++11... ([https://chromium-
> cpp.appspot.com/](https://chromium-cpp.appspot.com/)) + google style guide
> that is prehistory and NOT considered good in community.

It doesn't matter from a security perspective. In fact, I think C++11 is
actually less safe than C++03 with custom smart pointers, because use-after-
move is a hazard and lambdas make it very easy to have dangling references.

Chromium security engineers are some of the most competent engineers in their
field. If using more C++11 features made their code more secure, they would do
so. They don't, because C++11 doesn't make their code more secure.

Ultimately, these debates are really premised on something absurd: "assume
modern C++ is completely memory safe unless proved otherwise". This is
completely backwards and leads to endless "no true Scotsman" games. You need
to show _why_ C++ is supposedly memory safe. You won't be able to, because C++
is not.

> Maybe try with proxygen, rocksdb, folly from facebook ?

Those codebases aren't being attacked the same way browsers are.

But I can easily find use-after-free in them too with Google:
[http://code.metager.de/source/history/facebook/folly/folly/i...](http://code.metager.de/source/history/facebook/folly/folly/io/async/test/DelayedDestructionBaseTest.cpp)

~~~
lossolo
Indeed you have found ONE, Good job.. I didn't say modern c++ is memory safe,
did I? I've said couple of times that someone can use modern c++ with good
static analyzer in safe way if his application is properly designed.

Tell me then if it's such a huge problem that rust solves ( that people have
with memory safety) why whole world didn't switched to Rust for NEW projects?
It's stable already.

