Is it just me, or does Rust feel much more bare-bones than other languages? I just started learning it recently and this is the one thing that stood out to me, much more so than the memory management business. A lot of things that would normally be part of the language has to be achieved through meta-programming in Rust.

Is this a deliberate design choice? What do we gain from this setup?

Edits:

Somehow, this question is being interpreted as a complaint. It's not a complaint. As a user, I don't care how the language is designed as long as it has a good user experience, but the curious part of my mind always wants to know why things are the way they are. Maybe another way to phrase my question: Is this decision to rely more on meta-programming responsible for some of the good UX we get in Rust? And if so, how?
I'm using meta-programming to mean code that generates code in the original language. So if I'm programming in Rust, that would be code that generate more Rust code. This excludes compilation where Rust gets converted into assembly or any other intermediate representation.

you are viewing a single comment's thread
view the rest of the comments

[–] kornel@programming.dev 18 points 1 month ago* (last edited 1 month ago) (11 children)

Rust tries to move language functionality to libraries where possible. Instead of adding high-level magic to the language, Rust prefers to add a low-level feature that can be used to build higher-level features. For example, instead of built-in nullable types, it has enums with data, which were used to make Option. This way hopefully you can do more things with fewer language features. Functionality of higher-level features can be explained by lower-level ones (knowing how things are implemented is important for systems programming), and you can reimplement them if you need (e.g. Rust in the Linux kernel uses its own smart pointers instead of those from the standard library).

Rust tries to keep the standard library small, and move unnecessary code into crates-io crates. The problem with stdlib is that there is only a single version shared by all programs, so it has to stay backwards-compatible forever. Long term stdlib accumulates outdated functionality and deprecated APIs, which can't be fixed. Crates.io crates support versioning, so they can evolve and iterate without breaking anyone.

Another reason is that Rust supports low-level programming, including embedded. This means that the language itself can't depend on any fat runtime, and doesn't even perform heap allocations.

[–] cx40@programming.dev 6 points 1 month ago (10 children)

I'm not talking about what features are in the standard libraries vs third party libraries. I mean meta-programming as in the stuff that generates Rust code. Take console printing for example, we use a macro println! in Rust. Other languages provide an actual function (e.g. printf in C, System.out.println in Java, print in Python, etc). The code for my first project is also full of things like #[derive(Debug,Default,Eq,PartialEq)] to get features that I normally achieve through regular code in other languages. These things are still in the Rust standard library as I understand it.

[–] tatterdemalion@programming.dev 2 points 1 month ago* (last edited 1 month ago)

Regarding the derive macros, there are a few reasons these are required.

Rust does not have a language runtime (like Java). So certain features that would normally require reflection instead require an opt-in trait implementation. This is part of Rust's "zero cost abstractions" philosophy. You don't pay for code you don't need.
You get the benefit of being able to customize the behavior of those core traits. Rather than doing something simple (and wrong) for every type, like a byte-for-byte equality check, you get to define the behavior that is appropriate for a given type.
The derive macros are just a convenience. You are free to use "regular code" to implement those traits instead.

load more comments (9 replies)