
Five Years of Rust - pietroalbini
https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html
======
ojnabieoot
The progress on the error messages truly is worth highlighting, and kudos to
the team for all the hard work there. It's one of the hardest things to get
right in a programming language, particularly if that language has a fussy
compiler.

~~~
empath75
I’ve been using the anyhow crate and it’s made error handling almost painless.

~~~
jrimbault
Just to point out for other readers, nowadays to make a custom error type you
just need :

\- an enum (or struct)

\- its Display implementation

\- its Error implementation, now just one function

And a few `impl From<OtherError> for MyError` to make the try? operator work.

For a library it's really not that much work. And even that can be simplified
further to a few derive macros with another library : thiserror.

~~~
asdkhadsj
To simplify even more, you don't _actually_ need `Display` or `Error` impls. I
use Error enums frequently without display or Error impls. Though, with better
backtrace support coming it'll be handy to have Error and the Backtrace
related APIs implemented.

 _(Sidenote, I don 't use `impl Error` because I never use `Box<dyn Error>`.
Which isn't to say that's correct, just to say that I've never had the need to
implement it)_

~~~
JeanMertz
Even though GP meant to highlight compiler error messages, I also have to take
my hat off for the library/application error-handling story in Rust.

Using a crate such as thiserror[1] combined with displaydoc[2] makes handling
errors in a structured manner a great experience. I love how the error
handling story has evolved over the last couple of years in Rust, and it
really feels like we're entering into the final stretch of fine-tuning to get
the best possible experience.

And yes, anyhow[3] is also great, it serves a different purpose, but I
frequently reach for all three crates.

[1]: [https://crates.io/crates/thiserror](https://crates.io/crates/thiserror)
[2]:
[https://crates.io/crates/displaydoc](https://crates.io/crates/displaydoc)
[3]: [https://crates.io/crates/anyhow](https://crates.io/crates/anyhow)

------
jasode
Now that there's been 5 years since v1.0, is there any consensus on design
mistakes that Rust made? Any mistakes that people wish they could turn back
time and do differently but can't because it would break compatibility with
too much existing code out there? That's the more interesting list to me.

~~~
ainar-g
One way to reason about what could have been done better from the beginning is
looking at stuff that is marked as [deprecated] in the standard library. E.g.
how the "try!()" macro was deprecated in favour of the "?" operator.

~~~
cesarb
I would say the try!() macro is an exception to that rule: if the ? operator
existed since the beginning, it would be seen as "too much magic" (in a
language that already used up most of its "strangeness budget" in
lifetimes/borrowing), while try!() is just a very simple macro you could write
yourself, with no special compiler support. Only later, after people got used
to try!() everywhere, the ? operator became viable, as "just a shortcut to
try!() with better precedence (and it also works on Option)".

That is, there's a path dependence, where the existence of try!() made the ?
operator viable.

~~~
jasode
_> if the ? operator existed since the beginning, it would be seen as "too
much magic" [...] That is, there's a path dependence, where the existence of
try!() made the ? operator viable._

Yes, C++ creator Bjarne Stroustrup made a similar observation:

\- For new features, people insist on LOUD explicit syntax.

\- For established features, people want terse notation.

There seems to be an invisible "Overton Window" of evolving programming
language features and syntax.

------
Multicomp
Is now the time to start learning rust? In your estimation, are there going to
be lots of job opportunities for people who have 15 years experience with
rust?

I primarily live in the .Net world, but rust seems extremely close to f# in
terms of compiler safety, and I'm trying to decide what programming language
to learn next.

~~~
doteka
My job is about 50% Rust, 40% Typescript, 10% Python with regards to language.

I would say Rust is the best day to day experience out of these 3 except for
glitchy editor tooling and the long compile times. We have 1000 line services
that take close to 10 minutes for a release build which is not ideal.

I would not necessarily suggest learning Rust to get a job though. We mostly
stopped mentioning it in our job ads because we don’t want people applying for
the “hip stack”. Usually, competent programmers with some basic understanding
of how manual memory management works have no trouble picking it up as they
go.

~~~
mlindner
> We mostly stopped mentioning it in our job ads because we don’t want people
> applying for the “hip stack”.

Can you elaborate on that? I'm maybe thinking of changing jobs soon and my #1
want is that I can commonly program in Rust as opposed to C. Why would you
explicitly avoid mentioning Rust?

~~~
doteka
Also, a word of advice: the language in use should be one of the last things
you're considering when looking for jobs. It really doesn't make a difference
in your day-to-day happiness.

Instead, try to look for a team you fit in with, a manager you can trust,
growth opportunities, and the chance to work on interesting projects that have
impact. Case in point, one of my most enjoyable (and beneficial to my career)
jobs was mostly Java 8 - and that's certainly near the bottom of my "good
programming languages" list.

~~~
athriren
This is all very good advice.

------
manaskarekar
Non-Lexical Lifetimes was huge. Impressive list.

I hope the next 5 years bring compiler speed ups.

~~~
nindalf
It probably will. Every release has a number of performance improvements
although the release notes don't mention them. Great work like [1] [2] [3]
weren't mentioned in the release notes because those notes mostly focused on
feature improvements.

This work seems to be gaining momentum, if anything. The next version (1.44)
will significantly improve the performance of programs that use async [4]. The
next version of LLVM will be faster [5] (hopefully reversing the perf
regressions in LLVM 10).

[1] - [https://blog.mozilla.org/nnethercote/2020/04/24/how-to-
speed...](https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed-up-the-
rust-compiler-in-2020/)

[2] - [https://blog.mozilla.org/nnethercote/2019/12/11/how-to-
speed...](https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed-up-the-
rust-compiler-one-last-time-in-2019/)

[3] - [https://blog.mozilla.org/nnethercote/2019/10/11/how-to-
speed...](https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed-up-the-
rust-compiler-some-more-in-2019/)

[4] - [https://ferrous-systems.com/blog/stable-async-on-
embedded/](https://ferrous-systems.com/blog/stable-async-on-embedded/)

[5] - [https://nikic.github.io/2020/05/10/Make-LLVM-fast-
again.html](https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html)

------
lllr_finger
One of my favorite things with Rust is how other things are starting to use
it. Just yesterday I started playing with Deno and was anticipating a severe
lack of database bindings. Some people used the built-in Typescript->Rust
message passing to make a tiny shim around the Rust bindings for things like
MongoDB:
[https://github.com/manyuanrong/deno_mongo](https://github.com/manyuanrong/deno_mongo)

------
mindv0rtex
I hope Rust adds the major anticipated features (GATs, const generics,
specialization) soon, or alternatively decides to not implement them
altogether. I'm a rather new Rust developer, but still I very quickly ran into
the issue of needing a nightly version of rustc because one of my dependencies
(PyO3) relied on one of these features. It would be awesome to have some
periodic updates from the compiler team on the progress thereof.

~~~
bluejekyll
Technically speaking, those are implemented, just not stabilized, if you’re
using them in the nightly, they’re just disabled in stable.

So I would anticipate they will eventually stabilize like many other features
have and become part of stable.

~~~
estebank
Just want to clarify that an implementation being present in nightly doesn't
ensure a timeline for stabilization or even that it _will_ happen, as
unexpected bugs in the implementation or design of the original RFC might crop
up once it's actually used that makes us take the decision to push the
stabilization back. This has happened multiple times (from a single version
delay to things that are perma-unstable). That being said, the majority of the
unstable features you're waiting for "only" need baking time.

------
aey
The killer feature of rust is rapid incremental improvement of the language.
Every quarter something gets better.

~~~
busterarm
That's a feature of several languages right now/at times.

~~~
fastball
I agree. That's how I've felt about Python with every release since 3.5

~~~
BiteCode_dev
And yet there are people complaining it's too slow, or too fast.

I don't think there is any pace of language evolution that will never be
criticized.

~~~
aey
Rust has been really great at incremental language upgrades because of clippy.
Stuff get deprecated, clippy issues warnings, buy the time support is dropped
your code has been patched.

It feels like we are in some new weird software engineering world where the
code is only alive while its actively maintained and worked on. The libraries
that are shipped in the OS seem as constant and fixed in time as x86,
basically completely abstracted by the constantly evolving software on top of
it.

------
ncmncm
Rust is on track to soon--within ten years--become an industrially important
language. I see no other language on the horizon that could take Rust's place
alongside C++, in the places where they both excel.

That is not to say it _will certainly_ become industrially important. It
depends entirely on the numbers. Today, the total number of working Rust
coders may be less than the number who start coding C++ in any given week.
(This is a simple consequence of the difference between a base of thousands
vs. millions.) But if it can sustain exponential growth long enough, and
nothing else comes up in the meantime to take the wind from its sails, it
should get there.

------
arcadeparade
What’s the best resource to get started with Rust and make a desktop app?

~~~
qwe098cube
[https://areweguiyet.com/](https://areweguiyet.com/) gives a broad overview,
but is slightly outdated i believe. I recommend all raph linus' research on
this topic, fairly recent blog:
[https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....](https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.html)

Personally I used iced [1] a bit and found it very pleasant to use. iced is
cross platform, sponsored and very active.

[https://github.com/hecrj/iced](https://github.com/hecrj/iced)

~~~
rvz
Well, at least read the small prints and footnotes of this GUI library.

> Iced moves fast and the master branch can contain breaking changes!

Even in general, this crate is not even 1.0 or stable for production use. I'd
rather wait until it is mature before touching it. Until then, Qt is the way
to go.

------
jeffdavis
I've been working on postgres-extension.rs[1]. The idea is that, instead of
writing a PostgreSQL extension in C (which is the only option for interesting
extensions), you can also write one in pure rust.

I've eagerly awaited many features to make this work reasonably well, and I've
been very pleased how much rust has helped my use case over the last few
years.

Although lots of languages have a C FFI, that's really not enough to extend a
complex codebase. Postgres has it's own setjmp/longjmp-based error handling,
it's own system of allocators, it needs a way to find the right functions in
an extension and call them the right way, its own way of dealing with signals,
etc. There are zillions of internal structs, and the extension needs to be
able to read/modify them without copying/translation. Oh, and also, postgres
doesn't like threads at all, so the extension better not make any (at least
not ones that call back into postgres APIs).

The only language even close to getting all of this right is rust:

* it has no runtime that causes problems with threading, scheduling, signal handling, or garbage collection

* typically GC'd languages can't operate very well on unmodified C structs; rust doesn't have a GC so it can

* rust goes out of its way to support C-compatible structs without any copying/translation, and can even treat some plain C representations as more interesting types in a binary-compatible way (like a nullable pointer in C could be treated as an Option<&MyStruct> in rust)

* the tokio library allows nice concurrency without creating threads if you use the CurrentThread runtime

* it supports changing the global allocator to be the postgres allocator

* rust has good procedural macro support, which is important because a lot of postgres APIs heavily use macros, so making the rust version ergonomic requires similar macro magic

Areas rust could be more helpful, but which I'm trying to address on my own to
the extent that I can:

* Support for setjmp/longjmp. I know this is not easy, but important for interacting with C code that already uses it. I realize it would be unsafe, and that it can't be wrapped up in a safe way directly, and it would be delicate to create safe APIs that use it at all. But I still want it. I made a crate[2] that adds support, but it has a few issues that can't be resolved without compiler support.

* Better support for cdylib shared libraries that might call back into the host program that loads the library. Right now, you have to pass platform-specific flags to get it to link without complaining about undefined symbols (because they won't be resolve until the library is loaded into the host program). Also, it's difficult to test the shared library, because you have to guess at the location of the built library to be able to tell the host program where to find it before you can begin your test. I made a crate[3] to help with these things also, but it would be nice to have better support.

Oh, and one more thing on my wishlist not directly related to this project is
that it would be nice to have support for datastructure-specific allocators
(like a mini-allocator just for a hash table). Then, you'd be able to monitor
and control memory usage by inspecting that allocator; and when you destroy or
reset the hash table, you can know that the memory is freed/cleared as well
(without worrying about fragmentation). Maybe these mini-allocators could also
be used in other contexts, too, but it would probably be easiest to get the
lifetimes to work out if it was tied to a data structure.

[1] [https://github.com/jeff-davis/postgres-
extension.rs](https://github.com/jeff-davis/postgres-extension.rs) [2]
[https://github.com/jeff-davis/setjmp.rs](https://github.com/jeff-
davis/setjmp.rs) [3] [https://github.com/jeff-davis/cdylib-
plugin.rs](https://github.com/jeff-davis/cdylib-plugin.rs)

------
joshlk
Is there a roadmap for the next 1/2/5 years?

~~~
nindalf
One of compiler devs Niko Matsakis wrote a couple of posts about this

* Splitting the compiler into libraries so it's easier to iterate on them, while also making it easier to develop static analysis tools - [http://smallcultfollowing.com/babysteps/blog/2020/04/09/libr...](http://smallcultfollowing.com/babysteps/blog/2020/04/09/libraryification/)

* Improving the async experience - [http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...](http://smallcultfollowing.com/babysteps/blog/2020/04/30/async-interviews-my-take-thus-far/)

------
easytiger
Rust mods have to stop listening to the elite language intelligentsia.

Successful eco systems are pragmatic and idiomatically straightforward.

Everything & the kitchen sink in a language is not a recipe for success.

Every language that has a long lifespan spent a long time in feature minimal
stasis too. The world won't learn a moving target.

~~~
carlmr
Rust is barely a moving target since 1.0. If you only read the version
releases it might seem so, but for the pragmatic programmer not much is
changing. Many of the changes concern very special features that only a few
libraries make use of. As a library user you don't need to learn them.

I learned Rust a few years ago and without keeping up with the latest changes
too much I still feel confident I can work on current code.

~~~
bennofs
Having these "very special features" means that there are some things with are
added to the language but rarely used. That means that you might come across
code in a library that you don't understand, especially if you're not using
those features in your own code.

So, I think the argument that "very special features" shouldn't be counted
toward language complexity/growth is wrong, IMO. I would even say that there
needs to be even more focus on those features, since they tend to be not
widely known, not familar, and often there is less documentation about them,
so the likelyhood that they make code hard to understand is even higher.

This is not to say that those features are unnecessary. I just don't think the
justification "they are not what a pragmatic programmer will see" is good.

~~~
FreeFull
I'd say having special features is ok, as long as these criteria are met:

1) It's obvious the feature is being used.

2) The feature is easy to look up without knowing what it's called, just based
on how it's been used.

3) It's easy to understand what the feature actually does, with the
appropriate context.

~~~
estebank
The ? operator doesn't fulfill at least two of the three points, yet it's way
more loved than hated. As a general guideline I agree with your points, but it
is not to be taken as rigid gospel either.

------
sandGorgon
Is the current status of Rust that it is slower than Go ? According to this
previous post -
[https://news.ycombinator.com/item?id=23058147](https://news.ycombinator.com/item?id=23058147)

~~~
empath75
As someone who is not a particularly good programmer who has done quite a bit
of coding in both at this point, it seems to be easier to accidentally write
extremely slow code in rust than it is in go, but once you start optimizing,
rust will generally be faster, sometimes by quite a lot. I’ve also run into
fewer pathological cases as I’ve learned more of the idiomatic rust patterns.

~~~
jdub
And yet, a lot of experienced programmers have noted that even when they write
their first time naïve Rust, it turns out to be really fast.

~~~
sanxiyn
For example, Bryan Cantrill wrote about his experience in "The relative
performance of C and Rust". I found the post fascinating.

[http://dtrace.org/blogs/bmc/2018/09/28/the-relative-
performa...](http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-
of-c-and-rust/)

