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.

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.

  drop<T>(T)

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.

Non-Lexical Lifetimes was huge. Impressive list.

I hope the next 5 years bring compiler speed ups.

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

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.

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

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.

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

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 [2] https://github.com/jeff-davis/setjmp.rs [3] https://github.com/jeff-davis/cdylib-plugin.rs

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

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.

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

I learned it a few years ago, just for fun. I have it in my back pocket for a personal project. The language has some odd corners to learn (and they are what make it special), but it's not so difficult you can't forget about it for a year and then come back to your project, as I have.

There's some highly specialist aspects you _could_ learn (like anything I suppose), but I've got enough to get by and be as productive as I'd like without needing to get to that level.

So there's no harm in learning enough to get by for fun.

Compare to e.g. Haskell, which I learned at university, I have a memory that you'd have to invest quite heavily to make it do something useful.

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.

Now is a great time to learn it, because there's nothing huge on the horizon that will make your life easier or harder.

I started learning just as the async/await and futures features started causing churn and confusion in the ecosystem - it was slightly irritating at the time, but in hindsight, I'm still glad I started learning then.

Plenty of big name companies (discord, amazon) and even universities (georgia tech) are using and teaching rust. That's enough for me to say you should jump on the train.

I started a company while also learning Rust. It seemed like the right choice given that we needed something which emphasized memory safety and was also blazingly quick, but I was essentially forced onto it while dealing with the pressure of having to deliver on tight deadlines.

Our core tech is in pure Rust and I have to admit that coming from Javaland it's refreshing to deeply trust your code. It's hard to convey this idea of 'if it compiles it works' but I no longer worry about showing off prototypes to people. If they compile they work.

There is a learning curve as you are introduced to new ideas and design patterns but it's worth it! Rust has made me a better programmer.

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.

GAT and specialization still needs a lot of magic, mostly chalk/polonius integration, doesn't it?

Rust is not particularly adventerous as far as PL theory is concerned: all of the ideas in it are actually quite old (just newer than the ideas in established languages, like C). It's fundamentally quite pragmatic and you see that in most of the decisions it makes. I also don't agree that minimal features is necessary for success (even though it may be a desireable attribute of a language). Many extremely successful languages have piled on features over time, some in a far less reasoned way than rust (C actually a big outlier in how slowly it has evolved: C++, Java, C#, python, perl, PHP, etc are all large languages, with complexity in terms of number of features similar to Rust).

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.

The ecosystem _is_ one of my favorite parts of Rust.

Building C++ (or C) projects is such a clusterfuck that it's given rise to header-only libraries.

In Rust, everything is "cargo build", and adding a dependency is one line. This has only failed for me when there's a dependency on a C system library that I can't satisfy.

Is it bad to have too many dependencies? Sure, maybe. Is that an excuse to have artificial friction? No. I eagerly await the day when meson or conan or whatever becomes The C++ Dependency And Package Manager.

My other favorite part of Rust is the elitist language features like iterators, immutable borrows, functional programming, etc.

While I agree with you, I think you underestimate the number of features that help Rust be great in the face of a Lifetimes and Generics. One feature tends to lead to another. For example, Traits with Associated Types are amazing, but they then lead to a desire for GATs. GATs aren't (in this context) some fancy feature of its own, it fills in a noticeable void in an existing feature, Traits.

So many of these features Rust adds just fill in holes in an already extensive ecosystem.

I agree some feature development could be toned down to mitigate the moving target problem.. hell I think last years poll expressed roughly that. But, I think there's still a ton of features yet to come that merely complete what we already have.

I don’t think that was the conclusion.

“ as some keen HN commenters have pointed out, it looks like the rust program is not actually equivalent to the go program. The go program parses the string once, while the rust program parses it repeatedly inside every loop.”

I don't think it is. The top comment in that thread indicates why.

In general for most long lived workloads, I would expect Go to be approximately 15-25% slower than an equivalent C/C++/Rust program because of the CPU overhead of the Go GC. The Go team have done a lot of great work to optimize pause times and memory consumption though.

While Go may be faster somewhere, that post was not a good comparison.

See the discussion around it and the patches made by the community and the final results.

See the individual benchmarks: https://github.com/christianscott/levenshtein-distance-bench...

  Time (mean ± σ):      1.888 s ±  0.013 s    [User: 2.040 s, System: 0.045 s]

  Range (min … max):    1.875 s …  1.918 s    10 runs

  Time (mean ± σ):      4.257 s ±  0.033 s    [User: 4.295 s, System: 0.042 s]

  Range (min … max):    4.221 s …  4.338 s    10 runs

  Time (mean ± σ):     874.1 ms ±  50.8 ms    [User: 5.688 s, System: 0.830 s]

  Range (min … max):   813.5 ms … 1001.9 ms    10 runs

  'rust/target/release/rust' ran

    2.16 ± 0.13 times faster than 'go/out'

    4.87 ± 0.29 times faster than 'node javascript/main.js'

Rust is usually faster than Go. Note the edit in the previous post.

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.