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

[–] onlinepersona@programming.dev 1 points 1 day ago

I see what you mean. OK, I haven't read the rust language specs, RFCs or whatever, so this is my guess why it was done that way.

Regarding derive: Rust doesn't have inheritance but it does have traits / interfaces. This is both an advantage and a disadvantage. For environment with constrained resources, having structs that dont implement a bunch of things you don't need is an advantage. The downside is that in other cases, you need to know what you want.

For example not every class needs to be comparable or know how to print itself to debug output. But if you do want that, you need to know to implement the right trait. Implementing the same trait the same way all the time however is just boilerplate, hence, the derive macro.

At the same time proc-macros like derive ate extremely powerful since they ingest the syntax tree and spit one back out. It allows you to do crazy stuff at compile time with all the IDE goodness of showing docs, finding symbols, and type checking. IDEs can predictably expand macros. I have yet to find an IDE besides CLion that does the same with C/C++ code.

Process macros in rust can do things like consume files (statically as in inserted by the compiler as opposed to dynamically I'm the function browsing the filesystem), which allows reading and interpreting another language, like python or perl, to generate symbols for those other languages. It is thus possible for example to write a python module completely in Rust. With work, it theoretically is possible to also extend python classes (or symbols from other languages) purely in rust.

As for println! and format!, those macros are in the STL. They don't make it heavier. I think they are macros because rust doesn't (or didn't) support variadic arguments.