
Four Years of Rust - steveklabnik
https://blog.rust-lang.org/2019/05/15/4-Years-Of-Rust.html
======
Waterluvian
I love watching Rust progress. But the #1 thing I'm watching is the RLS and
vscode plugin. Maybe I'm weird but I work with so many languages that having
to manage multiple editors is a non-start. So any time I have a little
personal project that could be done in Rust (for learning) I end up using Go
or Python instead because the vscode support is still quite buggy.

Naturally others will say you don't need IDE-like support and that's fine.
It's just the way I enjoy learning. Autocomplete is an amazing learning tool.

~~~
oselhn
I do not understand what people like about vscode. If I ignore insane resource
consumption this is at most average IDE (the only real benefit over sublime
"text editor" is integrated debugger). This is most preferred editor at work
so I am forced to work with it and there are some of the most serious issues I
have:

1\. Only one side panel, so I can't see outline, test results and project
files at the same time as I am used to see on widescreen monitors in other
IDEs.

2\. Language servers are still not comparable to solutions offered by java
IDEs and in case of C++ they are worse than anything else I used.

3\. Python extension constantly forgets and founds unit test. There is little
support for unit test in other languages.

4\. Official C++ extension despite being completely useless consumes several
gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt
sales of Visual Studio). I also tried to use clangd which is better but there
is still a lot of work to be done before it is useful.

I like sublime rust support for really small projects and eclipse support for
larger projects (which is not ideal) but I have not coded anything serious in
rust yet, so I do not know if there is some good IDE.

~~~
Matthias247
For C++ try the cquery extension. It's pretty good. It mostly helped me to
provide IDE support (full code completion and navigation) for a project that
wasn't supported by Visual Studio or any other IDE (embedded project based on
gcc and a hacky makefile).

------
apo
> Rust+WASM went from an experiment to a usable product, making rustc the
> first compiler with focus on supporting WASM

This may be the most interesting use case of them all. WebAssembly is fast,
but it's also not fun to write. There are languages like AssemblyScript and
Lys that will let you write WebAssembly in what appears to be a higher-level
language, but you're still schlepping bytes around and must build the entire
universe yourself.

Rust offers an alternative: a high-level language with readily accessible
tooling to easily switch compile targets from native to wasm.

Given that so many JavaScript frameworks now require a compile step, the fact
that Rust is compiled is barely a disadvantage.

Not only that, but any general-purpose library code you write to support your
web application can be redistributed as native binaries for use in
C/C++/Python/Ruby/etc. projects.

Although the original idea for such a universal web/native target, Java, died
from self-inflicted wounds, the underlying need for a way to deploy code
across all platforms, native and web, never went away. Rust+wasm is a solution
that works today.

There's something else as well. WebAssembly is a sandboxed runtime, meaning it
runs in its own little environment. Anything it knows about the outside is an
opt-in add-on.

This makes wasm an interesting target for systems in which the JVM is
currently used. For example, database extension environments and web servers.

~~~
setr
Curious: if you rip out the js runtime in favor of pure webassembly, does that
have a significant impact on electron viability?

Obviously only once webassembly can do the full job

~~~
MuffinFlavored
WebAssembly can't touch the DOM without JavaScript. Does that change your
question?

~~~
Animats
_WebAssembly can 't touch the DOM without JavaScript._

There's still hope for ad-blocking, then.

~~~
pjmlp
Not really, there is Canvas & WebGL, and DOM support is coming anyway.

------
msvan
I wonder how many Rust users really want linear types and borrow checking,
instead of the other stuff Rust brings to the table: modern language design,
large and friendly community, nice type system, native compilation, good
package ecosystem.

Personally I would prefer a well-designed GC'd language with a strong type
system and native compilation over Rust, unless I was doing something with
specific demands on parallelism or embedded software.

~~~
pornel
There are already several decent GC languages. If Rust was just another GC
language, I don't think it would have attracted such a strong community
required to develop all of these things and break out of obscurity. It'd be
another Go with generics, or Elixir-native, or Swift with uglier syntax.

In the no-GC no-runtime niche for a very long time there was _nothing_ viable
besides C and C++. For programmers who want C-like level of control,
performance and low-level compatibility there are very few alternatives, and
if you want non-crash-prone parallelism on top of that, there's nothing but
Rust.

~~~
dpc_pw
I don't really understand why people would want a GC over deterministic
destruction like in Rust. GC is [neither necessary nor
sufficient]([https://ruudvanasseldonk.com/2015/10/06/neither-necessary-
no...](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-
sufficient)). Ownership model in practice is much more convenient precisely
because objects can act like resources and implement their cleanup logic, and
the business logic can rely on it. It's a great improvement in any imperative
PL.

I have (re-)implemented couple of real-life projects, and each time Rust was
much better higher-level language than eg. Java, Python or JS. Borrow checker
fights are non-issue in practice: just avoid references, pass messages as
copies and when you have to share data use `Arc` and copy on write (or just
add `Mutex`).

There's a reason why Rust is most loved PL for 4 years in a row. Once you try
it, and get past initial adjustments (mosty: what owns what relationship)
everything clicks, and I guarantee that you won't miss GC at all.

~~~
pjmlp
Because having a GC doesn't mean throwing away deterministic destruction.

Many GC enabled system languages do offer both mechanisms.

It is a matter of enjoying productivity it offers, while having the tools to
fine tune performance when it actually matters.

~~~
dpc_pw
> Many GC enabled system languages do offer both mechanisms.

?

Can you give me an example? Java's `finalize` is not deterministic
destruction. D's scope guards (or Go's `defer`) are also not like destructors,
because a calling code has to take care of them.

> It is a matter of enjoying productivity it offers,

There's hardly any productivity gain, and it is being offset by productivity
gained by a reliable and hassle-free resource management.

~~~
manwe150
Not exactly a systems language, but Python has deterministic destruction (due
to the use of reference counting) of non-cyclic data structures.

Edit: Oh, and if you don’t think that’s enough, note that Rust doesn’t
guarantee destruction to ever occur in that case (“considered safe”):
[https://doc.rust-lang.org/book/ch15-06-reference-
cycles.html](https://doc.rust-lang.org/book/ch15-06-reference-cycles.html)

~~~
dpc_pw
Oh, interesting. But from what I read it's only an implementation detail of
CPython?

With `with`I can't eg. pass an open file to another function to eg. be closed
there etc.

Example:

[https://play.rust-
lang.org/?version=stable&mode=debug&editio...](https://play.rust-
lang.org/?version=stable&mode=debug&edition=2018&gist=660bf12eee1338d4b05f747b2ba99ed6)

closing `File` will happen at the end of `foo` or `foo2`.

~~~
manwe150
That's probably a tricky question, since CPython is also essentially the spec.
PyPy talks a bit about this:
[http://doc.pypy.org/en/latest/cpython_differences.html#diffe...](http://doc.pypy.org/en/latest/cpython_differences.html#differences-
related-to-garbage-collection-strategies)

That's true, since Python has reflection it can't easily optimize that case,
whereas that's a powerful benefit of having a linear type system for tracking
ownership like Swift or Rust. But early freeing (which Rust has and Python
does not) is slightly different from deterministic freeing (which both have)
is slightly different from guaranteed freeing (which CPython has and Rust does
not).

------
deathanatos
Thank you, so much, to all the people that have put so many hours into making
Rust what it is today.

Rust, for me, took what was, prior to learning Rust, a vague undefined notion
and really helped me see it formalized into what I can now really call a
"mental model" of ownership/lifetimes. It has made my code better in _every_
language I work in.

------
yingw787
@steveklabnik what would you say are the core tenets of Rust's success? From
Python's side (as a Python prosumer), I'd say Python's core tenets may be:

\- Building an explicitly and observably welcoming open source community

\- Separating corporate money from technical direction, even at the cost of
faster execution

\- Upholding pragmatism over all else (e.g. keeping around a C/C++ API)

I'm not sure whether these principles carry over to all languages, or if
there's anything you want to add or subtract. Would be cool to have a broadly
applied philosophy endorsed by many language stakeholders.

~~~
steveklabnik
I think this answer would be a bit too long, and I don't have time at the
moment. I'll get back to you at some point :)

A quick response to your points: I'm not sure "upholding pragmatism over all
else" applies to Rust. It really depends on the details. Open source community
is absolutely important, and while you _can_ argue that money is separate from
technical direction, that's a very complex topic.

------
vijaybritto
My journey with rust has been a single application serving a couple of
endpoints from an sqlite database. Its never going over 50Mbs of memory. It
has been a solid rock for the past year no matter the hiccups in traffic!

------
simag
Kudos!

When Rust 1.0 was announced I had a look. I was very surprised because that
language was very different from my previous look, when Rust still had GC and
green threads (and a syntax with mystic sigils).

Rust 1.0 looked like it could be a good language, but coming from mainstream
languages with a richer ecosystem -- such as Java/Scala or C# --, Rust lacked
many common libs. For instance, a high-level approach to non-blocking IO,
which is something I need when writing servers. There were other issues --
lexical lifetimes often meant one needed to jump through hoops to please the
borrow checker. I thought Rust would need a lot more time to mature enough to
be a serious contender in my PL list. The next year, the Zero-Cost Futures
post[1] by Aaron Turon showed up in my news feed. It seemed interesting, but
it was only a plan. A few months later Tokio was born and, again, it seemed
interesting. But there's no way it was ready, was there? I went back to
business as usual. I kept hearing about Rust, but I had no intention to use it
in the immediate future.

Last year, I was offered a full-time Rust job out of the blue (because of my
experience in building distributed systems; I had to learn Rust as a part of
the job). I was interested because, in general, I was looking for a change --
but I also wanted to make sure I wouldn't spend energy on a language that
wouldn't be relevant in 10 years (at least, according to my intuition). I've
had job offers in other emerging languages (or old but trendy FP languages) in
the past but I don't think they will becoming mainstream, and I want a
language where 3rd party libraries for every (modern) protocol, API, database,
etc, are complete and safe (and that's more likely to happen with mainstream
languages).

I evaluated Rust again to see how mature it was. I was very surprised at the
speed of development of the language and of its ecosystem, especially compared
to other PL communities I had been part of. The energy in Rust reminds me of
Java's better days (but with a modern language). There are librairies for
everything, the language and compiler is surprising stable and mature (YMMV).
I believe this is a testament to Rust's productivity and reuse. Rust is not
perfect, but it's trying to reach an interesting trade-off. It is already very
usable considering how recent it is (obviously taking advantage of LLVM).

In my experience, projects with such hype are often just good at marketing.
You try them, and they have a lot of issues that they (sometimes) fix later;
I'd say it was the case for Cassandra, Docker, Kubernetes, TypeScript (and
more). With Rust, I started almost immediately on edition 2018 and found the
tooling, ecosystem, language and compiler to live up to its hype. Sure,
compile times could be faster, the RLS/IDE support is still a work-in-progress
(though usable), but I'd happily trade compile times for fewer bugs at
runtime, and most of all, the trajectory looks great; coming soon:
async/await, const generics, GATs, and better IDE.

So -- congratulations to everyone who had a part in making Rust happen, and
happy birthday!

[1]
[https://aturon.github.io/blog/2016/08/11/futures/](https://aturon.github.io/blog/2016/08/11/futures/)

~~~
yenwel
rust is getting HOTT? :p

------
lprd
I'm itching to get my hands dirty with Rust, but, approaching this from a web
developer background (hence minimal low level language experience), I have no
idea where to start. I have a Raspberry Pi3 sitting on my desk, perhaps I
should start there.

Congrats to the Rust Core Team!

~~~
steveklabnik
Thanks!

A lot of web dev people start off by writing command-line tools. Later this
year, Rust will also be significantly easier to write server-side web stuff
in, it’s a little tough to get into at the moment. You could also try front-
end web stuff with WebAssembly! The PI stuff is also a good choice.

There’s links to learn more about these topics on [https://www.rust-
lang.org/](https://www.rust-lang.org/) that should help you get started!

~~~
alexeldeib
I'm interested in Rust and have dabbled but don't follow the community too
closely. Why do you say later this year, specifically?

~~~
steveklabnik
It's not 100% for sure, but it's 99% for sure that async/await will be stable
in August. The decision to stabilize is being made in seven days, and if it's
decided, it will take that long to make it into its first stable release.

~~~
pimeys
We have the whole team waiting for this to land. We're probably going with
nightly already due to the problems fitting Futures 0.1 model to our codebase.

Very nice to hear.

~~~
steveklabnik
The proposed syntax has already landed in nightly, so you could use it right
now if you wanted, by the way.

~~~
pimeys
I've been trying a couple of approaches already, but first we're aiming
correctness and after that async/await.

Many libraries use tokio::spawn behind the scenes, so it seems we need compat
from 0.1 to 0.3 and back to 0.1 to get old futures to work with async/await
and the resulting futures to work in 0.1 tokio.

Last time I checked the async/await feature in tokio had some weird crashes
and tokio::spawn crashes when used inside romio...

------
ddffre
Were the major security vulnerabilities fixed?

I remember all the talking while back about the major bugs regarding the
language.

~~~
pornel
Short answer: yes

Long answer: it depends whether you mean actual vulnerabilities, or soundness
bugs

Known bugs that could affect security of programs written in Rust get fixed
ASAP. There was one serious bug in std's VecDeque that caused memory
corruption. There was a more recent issue where if you override type_id method
that wasn't supposed to be overridden, and then use another method that relies
on type_id being correct, you get crashy garbage. In C or C++ that'd be called
garbage-in, garbage-out, and a bad programmer shooting themselves in the foot.
In Rust that was considered a vulnerability.

Apart from that, there are known _soundness_ bugs in the
language/compiler/LLVM that could lead to undefined behavior, miscompilation,
or otherwise weasel out of things that the language is meant to guarantee:

[https://github.com/rust-
lang/rust/issues?q=is%3Aopen+is%3Ais...](https://github.com/rust-
lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3A%22I-unsound+%F0%9F%92%A5%22)

At this point these are mostly edge cases that you're unlikely to hit in real
code, but if you really really want to make your program crash, Rust can't
stop you.

------
jnordwick
I really want to like Rust, and I've made a few attempts in the past to get
involved - I wrote a database driver for a time series database (KDB) in pure
Rust among a few other things. I've even done a couple deep dives into rustc
to figure out the cause of some iterator slowness (it wasn't giving proper
hinting in the LLVM IM).

However, I keep having to step back. And in this short time Rust has
progressed a lot (and that isn't entirely a good thing either).

Rust might be the most liked language, but that is mostly a measure of how
vocal its supporters are. It is also very underused for how liked it is. It is
become a C-like Haskell in that people like it a lot, but don't use it for
much important. Like Haskell, it might turn out to be a great research
language, but not be used much in practice. I was hoping to see a language
that was much more practical.

I'm about to take another shot at Rust, and I decided this time I should just
ignore all the dislike of `unsafe` and just use it as much as I need to. I
think I was making life more difficult on myself by trying to avoid it so
much, but when you have a lot of pointers that have multiple refereces between
then, you kind of have to. Doulble linked and mutually linked structures -
where any pointer chance can lead to a mutation - are Rust's achillies heel.
Unfortunately, you see that a lot in system-level programming. I write a lot
of high performance code and low-latency networking. My main reason to use
Rust is for performance reasons and a language with fewer footguns than C++.,
but something that doesn't completely remove my ability to produce good code.

However, I think Rust has moved too fast in the language department. It has
changed and continues to change at a pace that prevent people how mainly use
it as a tool for other things from becoming an idiomatic writer of the
language. The idioms change too quickly.

The networking stack for efficient non-blocking event driven code still isn't
where it needs to be. In Java for example, the NIO abstractions are much
better. C++ just turns you over to the C system API. Rust is a disaster in the
middle with kind of having a socket abstraction and telling you to just use
libc for the rest. This has been an issue for years. Tokio is the wrong
abstraction on the wrong level for me, and mio underlying library is kind of a
mess with its token architecture, how it handles user defined events.
Hopefully it has improved in the last couple years. It used to be slower than
it needed to be.

"Slower than it needs to be" can describe a number of things in Rust, also the
default hash implementation. Why would you use a secure hash for your default?
If you really need that, you know you do, and 99.999% of the uses cases don't
need that. I often need small key performance, which is basically the trade
off they decided against.

C++ has blown its complexity budget a 100x over. Rust: hold my beer. In just a
few year, Rust has kept up to c++ in that measurement (again, not a good
thing). I'd like the language to stabilize a bit and work on what is currently
there instead of running off to add support for yet another programming
paradigm (async and userland threads - feel like a trip back in time to 20
years ago).

Side note on docs formatting: Reading the documentation is still incredibly
difficult for me. It doesn't flow well, the top of the page has no index - you
basically just have to scroll down. The page width is fixed to 960px so there
are interior scroll bars on the code segments. No use of background color is
mostly white so it is a big mess of black on while with some small indentation
differences. Look at cppref and cpluplus: both have essentially broken down
contents at the top making it easier to find what you are looking for, they
both make use of color effectively. And everything on Rust Docs starts off
fully expanded: you don't actually expand what you want to see instead of have
to fold what you don't want to see (so first thing on every page, I have to
immediately fold everything, then unfold the often too long context section).
Seems backwards to me. And navigation on ther two sites is much better once
you get deep on the docs. You can't go to a rust page doc and skim down a page
or two looking for the call you want (e,g.: I need to find the mutating calls
on a tree). On the cpp docs on both sites very eary, on rust it is tough.
There is no "here are all the lookup methods" and "here at all the methods to
look things up"

~~~
sriram_malhar
You speak of low latency code and doubly linked lists in the same breath.

Personally, I have moved from linked data structures to more cache friendly
data structures, which means contiguous spaces. No jumping around. It's very
liberating.

~~~
davemp
Doubly linked lists are used all over for low level programming. For low
access, large dynamic data they're a pretty good solution AFAIK.

~~~
DblPlusUngood
You are absolutely right. They are used everywhere in the Linux, OpenBSD, and
FreeBSD kernels, and likely many other kernels.

Replacing large linked lists with arrays is rarely an actual win. With an
array, insertion and deletion become far more expensive, virtual memory is
more likely to become fragmented or grow monotonically, and the cache misses
avoided are almost certainly irrelevant to total performance.

