this post was submitted on 03 Aug 2023
145 points (97.4% liked)

Asklemmy

43771 readers
1666 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy ๐Ÿ”

If your post meets the following criteria, it's welcome here!

  1. Open-ended question
  2. Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
  3. Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
  4. Not ad nauseam inducing: please make sure it is a question that would be new to most members
  5. An actual topic of discussion

Looking for support?

Looking for a community?

~Icon~ ~by~ ~@Double_[email protected]~

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 36 points 1 year ago* (last edited 1 year ago) (2 children)

I'm a big fan of Rust.

  • Excellent tooling. The package/build manager (cargo) just works, the compiler's error messaging is simply unmatched and the IDE story is excellent thanks to rust-analyzer.
  • Rich ecosystem. There's a crate for almost anything you could need, and endless piles of learning resources.
  • You get the speed and low-level control (if necessary) of C/C++ without all the pain and legacy baggage.
  • The community tends to care a lot about correctness and API design, which is reflected in both the core language and the ecosystem. Rust doesn't try to hide complexity and pretend things are simple (like Go) - instead, it gives you the tools to manage it head-on.
    • Example: if a function can fail, then it returns a Result and you have to explicitly handle the possibility that something went wrong. There's no forgetting a null check and slamming face-first into a NullReferenceException or segfault in some other part of your code.
  • It's expressive. Iterators, generics/traits and other language features make it easy to communicate what's going on to both the machine and other humans. Even the syntax is designed to support this - you can tell a lot just by looking at a function signature.

Obviously it's not all perfect, however.

  • Compile times can drag you down. (rustc is always getting faster, of course, but it'll probably never be as fast as Go or JVM/NET.)
  • It can be difficult to read at times, especially when code starts leaning heavily into generics and lifetime annotations.
  • Speed and control comes at a cost. No garbage collector means that anyone coming from a managed language (which, hello, that was me) is going to have to rewire their brain to deal with lifetimes, ownership and mutability XOR aliasing. You eventually develop an intuition for how to structure your code to play nice with the compiler, but that takes time.
  • New language features can take a long time to be stabilized and released. The advantage is they tend to be baked all the way through from day one, but the slow pace can be infuriating, especially when big ecosystem advancements are hung up on key additions.
[โ€“] [email protected] 8 points 1 year ago

And much time is saved from debugging. It makes a lot of sense that we let the computer/compiler keep an eye on lifetimes, allocations and access so the code is much more correct once it compiles.

I feel like my old colleagues and I have spent a far too large part of the last 20 years chasing memory issues in C++. We are all fallible, let the compiler do more.

[โ€“] [email protected] 2 points 1 year ago* (last edited 1 year ago)

I like the way the compiler doesn't just tell you there's a problem, but also gives you advice on ways you may be able to fix it. That's a smart compiler.

And I like the way I can write something that runs fast but not feel faintly anxious all the time I'm doing it.