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'm not saying that there's a problem with doing things one way or another. Rather, I'm asking whether there's a problem with doing things differently that then led to this design decision to be made with Rust. I want to better understand how this language came to be.

The term “meta-programming” had me lost since I’m only familiar with that in reference to C++ templates (and Rust’s generics are more like templates).

Yes, like C++ template and macros. The kind of code that generates new code before being run.

So to answer your question as to why there are macros, it’s because you need to generate code based on the input. A function call can’t do that.

You can design a language where you don't need to generate code to accomplish this. My question isn't why this is necessary in Rust. My question is why Rust was designed such that this was necessary.

Someone mentioned elsewhere that this allows for compile-time type safety. I'm still trying to wrap my head around how that works.

Try Forth if you want a bare bones language.

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

I use Common Lisp, but maybe you're right and my reason for using it is bad.

Like what? If you need something that the language is missing, then just open crates.io (or lib.rs, which is subjectively better frontend for browsing crates).

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?

Part of why Python can do this is that it runs completely differently from Rust. Python is interpreted and can run completely arbitrary code at runtime. It's possible to exec arbitrary Python.

Rust is compiled ahead of time. Once compiled, aside from inspecting how the output looks and what symbol names it uses, there's nothing that ties the output to Rust. At runtime, there is nothing to compile new arbitrary code, and compiling at runtime would be slow anyway. There is no interpreter built into the application or required to run it either.

This is also why C, C++, and many other compiled languages can't execute new arbitrary code at runtime.

Through macros? The term "meta-programming" had me lost since I'm only familiar with that in reference to C++ templates (and Rust's generics are more like templates).

println! and format! are macros because they use custom syntaxes and can reference local variables in a string literal provided to the macro:

let a = 2;
println!("{a:?} {b}", b=a);

I don't know how the derive macros would be function calls. They generate whole impls.

Macros generate new code. This is the same idea as C macros (except Rust macros generate syntax trees, not tokens, but that's a minor difference).

So to answer your question as to why there are macros, it's because you need to generate code based on the input. A function call can't do that.

Can you give some examples?

What languages provide out of the box varies a lot. Rust provides a ton of things compared to say C. 

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

Does anyone? 🙃

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.

I can see that. I'm coming in from the other extreme that is Python, where even the meta-programming is done in plain Python.

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.

C++ was my first programming language. I remember the nightmare of dealing with dependencies and avoiding boost because it felt wrong to need a third part library for basic features. The toolchain for Rust is very nice (not just compared to C++, but all other languages I've worked with) and has so far been a huge joy to work with. The language itself too. I'm just curious about why the language likes to expose more of its features through meta-programming rather than directly in the language itself. Things like println! and format! being macros instead of functions, or needing a bunch of #[derive(Debug,Default,Eq,PartialEq)] everywhere for things that other language provide through regular code.

@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.

A minimal but powerful language can feel like magic. Like, literally. The whole appeal of magic in stories is that you can step out of the normal rules and do something that defies belief, and who hasn't fantasized about that in real life?

If the language you're using has a lot of magic built into it, things that the language can do but you can't do, you feel mundane, like the language is letting you look at the cool things it can do, but doesn't let you do them yourself. A more minimal language, where the important things are in the library, means that the language designers haven't kept that stuff to themselves. They built the language such that that power is available to everyone. If the language gives its standard library authors the power to do things beautifully and elegantly without special treatment, then your library is getting those benefits too.

It's also a sign of good design, because just saying "well, this thing magically works differently" tends to be a shortcut, a hack, an indication that something isn't right and couldn't be fixed nicely.

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.

What are you talking about specifically? I've written C and C++ code and it's terrible. UTF strings were an absolute pain, you needed Boost for the simplest things (though many things of boost have been assimilated in the standard), there are a thousand different ways to do simple things like iterating through iterables (again, things have changed in the standard), there's no default dependency management, and so much more.

Rust comes with dependency management, a way to write unit tests and integrations, generate docs, toggle features, has standard iterables, string handling, async, compiler targets, and a lot more things C and C++ could only dream of having.

Don't even get me started on zig which doesn't have its own friggin string class / struct whatever.

So again, I ask you, what are you referring to? Please provide examples.

I think that really depends on your perspective. I’ve spent most of my career in C or a minimal subset of C++ for embedded systems. For me, even no_std rust has a rather rich set of features.

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.

Not sure if you're talking about the language, or the core/alloc/std libraries, or both/something in-between?

Can you provide specific examples, an which specific languages are you comparing against?

I think having "LTS" mean nothing is counterproductive. Why would anyone agree to apply "meaningless" labels like that? It would only confuse people more if we applied a label which implied support but nobody was actually obligated to support it any more than another release.

I don't agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don't have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.

Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It's just a nudge, nothing more.