
Rust: Systems Programming for Everyone - adamnemecek
https://www.infoq.com/presentations/rust
======
adrianratnapala
The title makes it sound like Rust is easy to use or learn. It isn't. And I
mean that in a nice way.

The whole point of Rust is to give you compile-time errors (as opposed to UB
or runtime checking) when you are doing something unprovable and force you
annotate your code so that things become provable. That involves understanding
up-front a lot of things I learned the hard way while writing in C and C++.

If I just want to quickly get something done that involes hitting the bare
metal, then C is probably easier than Rust. What Rust makes easier is getting
up to a high standard of confidence in the coide. But easier is still hard.

~~~
steveklabnik
We are very interested in making Rust more learnable, and are taking active
steps to make it more so:

1\. I am re-writing the book with the knowledge we've gained watching people
try to learn Rust over the last 18 months. For example, compare
[https://doc.rust-lang.org/stable/book/ownership.html](https://doc.rust-
lang.org/stable/book/ownership.html) to [http://rust-
lang.github.io/book/ch04-00-understanding-owners...](http://rust-
lang.github.io/book/ch04-00-understanding-ownership.html) ; The former version
takes a rules-based, theory-heavy approach. The new version uses a concrete
example with Strings, a common thing that people new to Rust struggle with.

2\. Error messages are being overhauled across several axes
[https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-
com...](https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html)
IDE integration is also being worked on.

3\. We created a dedicated "beginners" channel on IRC, it's been a rousing
success so far.

and hopefully more things in the future.

    
    
      > If I just want to quickly get something done
    

I think one of the big differences between Rust and C is this: in C, you can
quickly get _something_ done, but it quite possibly is not the right thing. In
Rust, you have to get the right thing done. That's hard at first, but gets
easier over time. By now, I get stuff done more quickly in Rust than I do in
C, because I rarely fight with the borrow checker, and Rust's other
productivity advantages come into play: numerics, cargo and crates.io, etc.

~~~
jordonwii
Re: 1. I tried learning Rust 8 months ago, and gave up because I couldn't
quite get my head around ownership, borrowing, etc. I just read through the
link you gave, and the explanation of ownership now is _very_ good - far more
approachable than it was, then, in my opinion. Awesome work. :)

~~~
steveklabnik
Thank you so much! Glad to hear it.

------
DyslexicAtheist
watched it this morning with a fresh coffee and mind. Absolutely brilliant
talk for anyone who wants to dig deeper into sys-programming. As a systems
developer Rust is the first new language in 20 years that excites me as a
serious contender and alternative to C. The talk discusses also higher level
aspects such as closures and FP-paradigms.

Probably too early to say if Rust will become the _lingua franca_ of system-
engineering. I'd love to see them succeed and hope that it isn't trying to be
everything for everybody. We already have enough of those.

~~~
DyslexicAtheist
PS: I love that Mozilla uses Rust for the media-parser to boost security. But
in the context of wider system engineering, there's a danger that crates.io
will become another malware distribution system (like dockerhub[0]).

Personally I think TUF[1] is still too academic and at least for now doesn't
offer practical solution to this yet.

[0] [https://blog.valbonne-consulting.com/2015/04/14/as-a-goat-
im...](https://blog.valbonne-consulting.com/2015/04/14/as-a-goat-im-skeptical-
of-dockers-hype/)

[1] [https://github.com/rust-
lang/crates.io/issues/75](https://github.com/rust-lang/crates.io/issues/75)

EDIT: typos

~~~
jacques_chester
They're slightly different problems. Docker images are, as everyone loves to
point out, immutable. Once built, they're built, and if you want to patch a
vulnerability you have to rebuild and replace.

A lot of folk on Dockerhub are just folk. They don't have security teams
keeping an eye for relevant CVEs and triggering rebuilds.

I work for one of those companies (Pivotal) that _does_ have a security team
keeping an eye out for relevant CVEs. I work in buildpacks. If you send an app
to a Cloud Foundry installation, you used the rootfs image and buildpack
binaries that we built. When a high-value CVE lands we commit to providing
replacement bits within 48 hours. We usually do it in much less.

But even with extensive automation -- and ours is pretty extensive -- this
requires humans to watch the firehose of flaws. Most people who write a
Dockerfile and forget it don't have that luxury.

Incidentally, Docker now offer security scanning of dockerhub images, for a
fee.

~~~
brunoqc
> Incidentally, Docker now offer security scanning of dockerhub images, for a
> fee.

This is weird. I thought it would be in their best interest that dockerhub's
images would have better reputations.

~~~
jacques_chester
Well I think I may have mis-stated it. They offer scanning for Docker Cloud,
which I understand to be their private registry / dev platform / once-and-
future-PaaS. So it's an additional paywalled feature for _private_ images, not
for the public ones.

And, in fairness, it's a surprisingly tricky problem which many well-heeled
customers see as worth paying for.

At Pivotal we've been working on "AppDog" to do something similar: inspect
running applications on Cloud Foundry, tell you what dependencies are
installed, what their licenses are, whether there are updates available and so
on.

And yeah. It's harder than it looks. There are edge cases upon edge cases.

(Of course, nothing I say should be considered official comment etc etc).

~~~
brunoqc
I think they also offer scanning for repositories on
[https://hub.docker.com/account/billing-
plans/](https://hub.docker.com/account/billing-plans/) but only if you pay.

> Docker Cloud and Docker Hub can scan images in private repositories to
> verify that they are free from known security vulnerabilities or exposures,
> and report the results of the scan for each image tag
> [https://docs.docker.com/docker-cloud/builds/image-
> scan/](https://docs.docker.com/docker-cloud/builds/image-scan/)

~~~
jacques_chester
I need to get better at _actually reading_ people's websites :)

------
soulbadguy
While i love rust, i do agree with @lkiux it can at time be over hyped.Rust
memory feature (borrow checker ?), which seems to be rust claim to fame takes
too much mindshare. Between RAII,deterministic destructors,move semantics,
shared_ptr and allocator, it seems to me rust memory management feature is
addressing problems that peolpe had 10/15 years ago forgoing the advances made
in C++ and Dlang.

The feature IMO which make rust really great, usually only get mentioned in
passing : well define compile time environement and compilation process,fast
compile, sane macro system, ML like type system with pattern matching, great
tooling and ecosystem out of the box.

~~~
steveklabnik

      > forgoing the advances made in C++ and Dlang
    

Which ones are those?

~~~
soulbadguy
"RAII,deterministic destructors,move semantics, shared_ptr and allocator" ?

~~~
steveklabnik
Maybe I misunderstood what you're talking about then. Rust very much did not
ignore those things. In fact, Rust has (most of) those things, but with
stronger guarantees, and/or putting them more core to the language.

(Allocators are the asterisk here, those are still a work in progress.)

~~~
soulbadguy
I not familiar enough with rust, but my point was that adding those feature to
C lessen the need of a borrow checker (not that rust don't have those
features.)

------
hayd
direct link to slides: [http://pnkfelix.github.io/presentations/qcon-
london2016-depl...](http://pnkfelix.github.io/presentations/qcon-
london2016-deploy/qcon-london2016.html#/)

