5 ms·

I doubt that anybody truly knows Rust. And this is aggravated by the fact that features keep getting added. But here are two simple strategies that I found very

by goku12 10mo ago

I doubt that anybody truly knows Rust. And this is aggravated by the fact that features keep getting added. But here are two simple strategies that I found very effective in keeping us ahead of the curve. 1. Always keep the language reference with you. It's absolutely not a replacement for a good introductory textbook. But it's an unusually effective resource for anybody who has crossed that milestone. It's very effective in spontaneously uncovering new language features and in refining your understanding of the language semantics. What we need to do with it is to refer it occasionally for even constructs that you're familiar with - for loops, for example. I wish that it was available as auto popups in code editors. 2. Use clippy, the linter. I don't have much to add here. Your code will work without it. But for some reason, clippy is an impeccable tutor into idiomatic Rust coding. And you get the advantage of the fact that it stays in sync with the latest language features. So it's yet another way to keep yourself automatically updated with the language features.

VorpalWay 10mo ago
I feel like other languages also have the issue of complexity and changing over time. I doubt I know all of C++ post C++14 for example (even though that is my day job). Keeping up with all the things they throw into the standard library of Python is also near impossible unless you write python every day. Rust has an unusually short release cycle, but each release tends to have fewer things in it. So that is probably about the same when it comes to new features per year in Python or C++. But sure, C moves slower (and is smaller to begin with). If that is what you want to compare against. But all the languages I work with on a daily basis (C++, Python and Rust) are sprawling. I don't have enough experience to speak about other languages in depth, but as I understand it Haskell for example has a lot of extensions. And the typescript/node ecosystem seems to move crazy fast and require a ton of different moving pieces to get anything done (especially when it comes to the build system with bundlers, minifiers and what not).
- jacquesm 10mo ago
  Languages should be small, not large. I find that every language I've ever used that tries to throw everything and the kitchensink at you eventually deteriorates into a mess that spills over into the projects based on that language in terms of long term instability. You should be able to take a 10 year old codebase, compile it and run it. Backwards compatibility is an absolute non-negotiable for programming languages and if you disagree with that you are building toys, not production grade systems.
  - aw1621107 10mo ago
    > Backwards compatibility is an absolute non-negotiable for programming languages What programming language(s) satisfy this criteria, if any?
    - GhosT078 10mo ago
      Ada does. It has been through 5 editions so far and backwards compatibility is always maintained except for some small things that are documented and usually easy to update.
      - aw1621107 10mo ago
        I'd normally be inclined to agree that minor things are probably good enough, but "absolute non-negotiable" is a rather strong wording and i think small things technically violate a facial reading, at least. On the other hand, I did find what I think are the relevant docs [0] while looking more into things, so I got to learn something! [0]: https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/compatibility_and_porting_guide.html https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/c...
      - cogman10 10mo ago
        > except for some small things that are documented I can't think of any established language that doesn't fit that exact criteria. The last major language breakage I'm aware of was either the .Net 2 to 3 or Python 2 to 3 changes (not sure which came first). Otherwise, pretty much every language that makes a break will make it in a small fashion that's well documented.
    - gethly 10mo ago
      Go, PHP, Ruby, JavaScript ... I'd say majority, actually.
      - aw1621107 10mo ago
        It's probably borderline due to the opt-in mechanism, but Go did make a technically backwards-incompatible change to how its for loops work in 1.22 [0]. PHP has had breaking changes [1]. Ruby has had breaking changes [2] (at the very least under "Compatibility issues") Not entirely sure whether this counts, but ECMAScript has had breaking changes [3]. [0]: https://go.dev/blog/loopvar-preview https://go.dev/blog/loopvar-preview [1]: https://www.php.net/manual/en/migration80.incompatible.php https://www.php.net/manual/en/migration80.incompatible.php [2]: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/ https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-rele... [3]: https://tc39.es/ecma262/2025/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/2025/#sec-additions-and-changes-that...
- pjmlp 10mo ago
  Even C, we are now at C23, and I bet most folks only know "my compiler C", and not even all the extensions it offers.
  - esafak 10mo ago
    That's why it's important to get it right early in the language. The new stuff may as well not exist.
gucci-on-fleek 10mo ago
I don't know Rust at all, but all your comments > I doubt that anybody truly knows <language>. > Always keep the language reference with you. > Use <tool>, the linter. seem like they apply to all languages (and I agree that they're great advice!).

by goku12 10mo ago

VorpalWay 10mo ago

I feel like other languages also have the issue of complexity and changing over time. I doubt I know all of C++ post C++14 for example (even though that is my day job). Keeping up with all the things they throw into the standard library of Python is also near impossible unless you write python every day. Rust has an unusually short release cycle, but each release tends to have fewer things in it. So that is probably about the same when it comes to new features per year in Python or C++. But sure, C moves slower (and is smaller to begin with). If that is what you want to compare against. But all the languages I work with on a daily basis (C++, Python and Rust) are sprawling. I don't have enough experience to speak about other languages in depth, but as I understand it Haskell for example has a lot of extensions. And the typescript/node ecosystem seems to move crazy fast and require a ton of different moving pieces to get anything done (especially when it comes to the build system with bundlers, minifiers and what not).

jacquesm 10mo ago
Languages should be small, not large. I find that every language I've ever used that tries to throw everything and the kitchensink at you eventually deteriorates into a mess that spills over into the projects based on that language in terms of long term instability. You should be able to take a 10 year old codebase, compile it and run it. Backwards compatibility is an absolute non-negotiable for programming languages and if you disagree with that you are building toys, not production grade systems.
- aw1621107 10mo ago
  > Backwards compatibility is an absolute non-negotiable for programming languages What programming language(s) satisfy this criteria, if any?
  - GhosT078 10mo ago
    Ada does. It has been through 5 editions so far and backwards compatibility is always maintained except for some small things that are documented and usually easy to update.
    - aw1621107 10mo ago
      I'd normally be inclined to agree that minor things are probably good enough, but "absolute non-negotiable" is a rather strong wording and i think small things technically violate a facial reading, at least. On the other hand, I did find what I think are the relevant docs [0] while looking more into things, so I got to learn something! [0]: https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/compatibility_and_porting_guide.html https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/c...
    - cogman10 10mo ago
      > except for some small things that are documented I can't think of any established language that doesn't fit that exact criteria. The last major language breakage I'm aware of was either the .Net 2 to 3 or Python 2 to 3 changes (not sure which came first). Otherwise, pretty much every language that makes a break will make it in a small fashion that's well documented.
  - gethly 10mo ago
    Go, PHP, Ruby, JavaScript ... I'd say majority, actually.
    - aw1621107 10mo ago
      It's probably borderline due to the opt-in mechanism, but Go did make a technically backwards-incompatible change to how its for loops work in 1.22 [0]. PHP has had breaking changes [1]. Ruby has had breaking changes [2] (at the very least under "Compatibility issues") Not entirely sure whether this counts, but ECMAScript has had breaking changes [3]. [0]: https://go.dev/blog/loopvar-preview https://go.dev/blog/loopvar-preview [1]: https://www.php.net/manual/en/migration80.incompatible.php https://www.php.net/manual/en/migration80.incompatible.php [2]: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/ https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-rele... [3]: https://tc39.es/ecma262/2025/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/2025/#sec-additions-and-changes-that...
pjmlp 10mo ago
Even C, we are now at C23, and I bet most folks only know "my compiler C", and not even all the extensions it offers.
- esafak 10mo ago
  That's why it's important to get it right early in the language. The new stuff may as well not exist.

gucci-on-fleek 10mo ago

I don't know Rust at all, but all your comments > I doubt that anybody truly knows <language>. > Always keep the language reference with you. > Use <tool>, the linter. seem like they apply to all languages (and I agree that they're great advice!).