8 ms·

Five Years of Rust

293 points by pietroalbini 6y ago

manaskarekar 6y ago
Non-Lexical Lifetimes was huge. Impressive list. I hope the next 5 years bring compiler speed ups.
- nindalf 6y ago
  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-up-the-rust-compiler-in-2020/ https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed... [2] - https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed-up-the-rust-compiler-one-last-time-in-2019/ https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed... [3] - https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed-up-the-rust-compiler-some-more-in-2019/ https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed... [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
- deleted 6y ago
  [deleted]
joshlk 6y ago
Is there a roadmap for the next 1/2/5 years?
- manaskarekar 6y ago
  I suppose https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-10-04-Roadmap-2020-Goals/ https://rust-lang.github.io/compiler-team/minutes/design-mee....
- steveklabnik 6y ago
  We only plan out per calendar year, so we have a 2020 plan, but that’s it.
- nindalf 6y ago
  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/libraryification/ http://smallcultfollowing.com/babysteps/blog/2020/04/09/libr... * Improving the async experience - http://smallcultfollowing.com/babysteps/blog/2020/04/30/async-interviews-my-take-thus-far/ http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...
sandGorgon 6y ago
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
- manaskarekar 6y ago
  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-benchmarks/pulls https://github.com/christianscott/levenshtein-distance-bench...
  - Tuna-Fish 6y ago
    And just to help the lazy people, after making the benchmarked loads equivalent, the results are: hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out 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 Benchmark #2: node javascript/main.js 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 Benchmark #3: rust/target/release/rust 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 Summary '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'
    - burntsushi 6y ago
      It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-benchmarks/pull/8 https://github.com/christianscott/levenshtein-distance-bench... That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.
    - hu3 6y ago
      The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.
ojnabieoot 6y ago
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 6y ago
  I’ve been using the anyhow crate and it’s made error handling almost painless.
  - GolDDranks 6y ago
    You are talking about different things, the grandparent was talking about the compiler error messages. Just a note, I agree with both of you :)
  - jrimbault 6y ago
    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 6y ago
      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 6y ago
        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 6y ago
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 6y ago
  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.
  - ChrisSD 6y ago
    I think more interesting would be something we're truly stuck with (at least until Rust 2.0, which may never come).
    - steveklabnik 6y ago
      (Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
      - ChrisSD 6y ago
        Sure but you don't have to use them, is the point I'm trying to make. They don't affect modern code and while it's annoying they are used in older code there is at least a path forward to "upgrade" the code to the modern equivalents.
      - pas 6y ago
        Could a lint check for them and warn if some code uses them? This way slowly the ecosystem could move and stuff could be eventually removed.
        6y ago
aey 6y ago
The killer feature of rust is rapid incremental improvement of the language. Every quarter something gets better.
- busterarm 6y ago
  That's a feature of several languages right now/at times.
  - fastball 6y ago
    I agree. That's how I've felt about Python with every release since 3.5
    - BiteCode_dev 6y ago
      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 6y ago
        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.
easytiger 6y ago
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.
- deleted 6y ago
  [deleted]
- carlmr 6y ago
  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 6y ago
    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 6y ago
      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.
Multicomp 6y ago
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.
- afandian 6y ago
  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.
- WilliamEdward 6y ago
  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.
  - ellw 6y ago
    Another example would be Dropbox which quite recently published this great blog article about "Rewriting the heart of our sync engine" in Rust [1]. [1] https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...
- lllr_finger 6y ago
  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.
arcadeparade 6y ago
What’s the best resource to get started with Rust and make a desktop app?
- qwe098cube 6y ago
  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.html https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... 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 6y ago
    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.
- davidhyde 6y ago
  Search for the following in your browser: “the rust book” for the official free online rust book. “rustlings” for a set of code exercises to get you used to fixing your code when the compiler shows you an error. “iced github” for a cross platform gui library and, lastly, “rust by example book” for a different angle on learning the language.
- jayflux 6y ago
  I personally started with the rust book, then went from there. https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
- eximius 6y ago
  There's always Electron, Wasm, and the few smatterings of decent GUI frameworks being worked on. Also https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri which claims to be a... Light, more native Electron? Just depends what you want. A common pattern is essentially to build your app as a Rust library or CLI binary that your GUI wraps in whatever is most convenient for the GUI
mindv0rtex 6y ago
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.
- lzutao 6y ago
  We need more volunteers to help implement those features!
  - mindv0rtex 6y ago
    Is there a meaningful help that a Rust beginner can provide here?
    - swsieber 6y ago
      Many tickets are scored with a difficulty, and sometimes comes with a mentor: https://github.com/rust-lang/rust/labels?q=E- https://github.com/rust-lang/rust/labels?q=E- I think there are meaningful things a beginner can do. I'd be surprised if improving error messages would be terribly hard. And working on the small issues will help you become familiar enough to help with the bigger things. Edit: Also perhaps a way to get some exposure to the rust compiler is to help implement lints (in clippy) - it's basically a compiler plugin and relies on the same things available in the compiler.
      - estebank 6y ago
        The D-papercut diagnostics tickets are in my mind a great source of these kind of newcomers tasks, as some are quite small and don't require full context of the codebase.
- bluejekyll 6y ago
  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.
lllr_finger 6y ago
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
jeffdavis 6y ago
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
pot8n 6y ago
Despite Rust is way cleanly built, superior in almost every aspect than Go can ever dream to be, I doubt it will really take off really in the cloud business until there is: 1. official gRPC support 2. official Kubernetes API client support 3. official cloud vendor SDK support (AWS, GCP, Azure, etc...) 4. Faster build times, it's frustrating to wait for cloud CI/CD to finish in 40 minutes for a single release build
ncmncm 6y ago
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.

Five Years of Rust

293 points by pietroalbini 6y ago

manaskarekar 6y ago

Non-Lexical Lifetimes was huge. Impressive list. I hope the next 5 years bring compiler speed ups.

nindalf 6y ago
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-up-the-rust-compiler-in-2020/ https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed... [2] - https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed-up-the-rust-compiler-one-last-time-in-2019/ https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed... [3] - https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed-up-the-rust-compiler-some-more-in-2019/ https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed... [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
deleted 6y ago
[deleted]

joshlk 6y ago

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

manaskarekar 6y ago
I suppose https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-10-04-Roadmap-2020-Goals/ https://rust-lang.github.io/compiler-team/minutes/design-mee....
steveklabnik 6y ago
We only plan out per calendar year, so we have a 2020 plan, but that’s it.
nindalf 6y ago
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/libraryification/ http://smallcultfollowing.com/babysteps/blog/2020/04/09/libr... * Improving the async experience - http://smallcultfollowing.com/babysteps/blog/2020/04/30/async-interviews-my-take-thus-far/ http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...

sandGorgon 6y ago

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

manaskarekar 6y ago
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-benchmarks/pulls https://github.com/christianscott/levenshtein-distance-bench...
- Tuna-Fish 6y ago
  And just to help the lazy people, after making the benchmarked loads equivalent, the results are: hyperfine go/out 'node javascript/main.js' rust/target/release/rust 1 Benchmark #1: go/out 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 Benchmark #2: node javascript/main.js 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 Benchmark #3: rust/target/release/rust 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 Summary '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'
  - burntsushi 6y ago
    It looks like you got that from this PR: https://github.com/christianscott/levenshtein-distance-benchmarks/pull/8 https://github.com/christianscott/levenshtein-distance-bench... That PR does not make the benchmark loads "equivalent." Please look at the diff. That PR adds parallelism to the Rust program. The Go program does not have parallelism.
  - hu3 6y ago
    The Go and Rust program in that benchmark are really not equivalent. Rust is using threads.

ojnabieoot 6y ago

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 6y ago
I’ve been using the anyhow crate and it’s made error handling almost painless.
- GolDDranks 6y ago
  You are talking about different things, the grandparent was talking about the compiler error messages. Just a note, I agree with both of you :)
- jrimbault 6y ago
  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 6y ago
    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 6y ago
      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 6y ago

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 6y ago
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.
- ChrisSD 6y ago
  I think more interesting would be something we're truly stuck with (at least until Rust 2.0, which may never come).
  - steveklabnik 6y ago
    (Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
    - ChrisSD 6y ago
      Sure but you don't have to use them, is the point I'm trying to make. They don't affect modern code and while it's annoying they are used in older code there is at least a path forward to "upgrade" the code to the modern equivalents.
    - pas 6y ago
      Could a lint check for them and warn if some code uses them? This way slowly the ecosystem could move and stuff could be eventually removed.
      - 6y ago

aey 6y ago

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

busterarm 6y ago
That's a feature of several languages right now/at times.
- fastball 6y ago
  I agree. That's how I've felt about Python with every release since 3.5
  - BiteCode_dev 6y ago
    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 6y ago
      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.

easytiger 6y ago

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.

deleted 6y ago
[deleted]
carlmr 6y ago
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 6y ago
  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 6y ago
    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.

Multicomp 6y ago

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.

afandian 6y ago
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.
WilliamEdward 6y ago
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.
- ellw 6y ago
  Another example would be Dropbox which quite recently published this great blog article about "Rewriting the heart of our sync engine" in Rust [1]. [1] https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...
lllr_finger 6y ago
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.

arcadeparade 6y ago

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

qwe098cube 6y ago
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.html https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... 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 6y ago
  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.
davidhyde 6y ago
Search for the following in your browser: “the rust book” for the official free online rust book. “rustlings” for a set of code exercises to get you used to fixing your code when the compiler shows you an error. “iced github” for a cross platform gui library and, lastly, “rust by example book” for a different angle on learning the language.
jayflux 6y ago
I personally started with the rust book, then went from there. https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
eximius 6y ago
There's always Electron, Wasm, and the few smatterings of decent GUI frameworks being worked on. Also https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri which claims to be a... Light, more native Electron? Just depends what you want. A common pattern is essentially to build your app as a Rust library or CLI binary that your GUI wraps in whatever is most convenient for the GUI

mindv0rtex 6y ago

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.

lzutao 6y ago
We need more volunteers to help implement those features!
- mindv0rtex 6y ago
  Is there a meaningful help that a Rust beginner can provide here?
  - swsieber 6y ago
    Many tickets are scored with a difficulty, and sometimes comes with a mentor: https://github.com/rust-lang/rust/labels?q=E- https://github.com/rust-lang/rust/labels?q=E- I think there are meaningful things a beginner can do. I'd be surprised if improving error messages would be terribly hard. And working on the small issues will help you become familiar enough to help with the bigger things. Edit: Also perhaps a way to get some exposure to the rust compiler is to help implement lints (in clippy) - it's basically a compiler plugin and relies on the same things available in the compiler.
    - estebank 6y ago
      The D-papercut diagnostics tickets are in my mind a great source of these kind of newcomers tasks, as some are quite small and don't require full context of the codebase.
bluejekyll 6y ago
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.

lllr_finger 6y ago

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

jeffdavis 6y ago

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

pot8n 6y ago

Despite Rust is way cleanly built, superior in almost every aspect than Go can ever dream to be, I doubt it will really take off really in the cloud business until there is: 1. official gRPC support 2. official Kubernetes API client support 3. official cloud vendor SDK support (AWS, GCP, Azure, etc...) 4. Faster build times, it's frustrating to wait for cloud CI/CD to finish in 40 minutes for a single release build

ncmncm 6y ago

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.