printf uses macros in its implementation.

int
__printf (const char *format, ...)
{
  va_list arg;
  int done;

  va_start (arg, format);
  done = __vfprintf_internal (stdout, format, arg, 0);
  va_end (arg);

  return done;
}

^ This is from glibc. Do you know what va_start and va_end are?

to get features that I normally achieve through regular code in other languages.

Derives expand to "regular code". You can run cargo expand to see it. And I'm not sure how that's an indication of "bare bone"-ness in any case.

Such derives are actually using a cool trick, which is the fact that proc macros and traits have separate namespaces. so #[derive(Debug)] is using the proc macro named Debug which happens to generate "regular code" that implements the Debug trait. The proc macro named Debug and implemented trait Debug don't point to the same thing, and don't have to match name-wise.

@cx40 @kornel using a macro ensure the format string and the values printed are typed correctly at compile time. It also ensure that most of the parsing is done at compile time and just the bare minimum is done at runtime. It's a safe and fast way to solve this issue.

Most high-level languages do a lot of things implicitly, like casting types, cloning values, deciding what the default is. Rust tends to avoid that, which though less convenient makes behavior more predictable, reducing footguns and surprises.

Using a function is strictly worse than figuring out the formatting at compile time (something Zig also does).

The derives are just shortcuts. You can write everything out long-hand like you would in C++ or Python too if you really want.

Honestly both of these complaints are essentially "why does Rust use macros to make writing code better/easier?".

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

1. 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.
2. 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.
3. The derive macros are just a convenience. You are free to use "regular code" to implement those traits instead.

I also come from python, actual meta-programming concepts are usually implemented via meta-classes, which I would describe as more complex than rust macros, in the "it takes longer to fully understand" sense.

You could also generate python code and execute it if you don't mind the obvious security implications, but that's only a possibility thanks to it being an interpreted language, while rust macros can provide validations and readable error messages out of the box.

To your post's point in general:

• Python uses exceptions, rust uses errors as values, making rust more predictable.
• Python uses Nullables (None | T) which require hand-written handling, instead of rust's Option<T> which has convenience methods and syntax support (... = maybe?).
• Python has GC by default, and making a function fast requires delegating it to another programming language, meaning you usually would write python for software that needs not be performant.

I have more points if you'd like to understand my position, and am willing to explain if you need.

even the meta-programming is done in plain Python

@decorator comes to mind, and only the keyword is part of the language.

Common Lisp has meta programming built-in but no one uses Common Lisp for a good reason.

Source needed because the Rust library is bigger than the STL, no one cares about print being a macro, and derivation being an issue only applies when you compare Rust to scripting languages.

Rust is a contender to C and C++, not Visual Basic that can do everything poorly.

A lot of things that would normally be part of the language

Give examples because println is not convincing. Why would you have println on an embedded system that has no display?

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.