C++ is two and a half decades older than Rust. Come back to this comment in 25 years and see how well the pleasure of Rust's design has held up.

That’s ironic because arguably C++ became a much better language in the last decade or so than what it was before that.

...and I'm sure the language features which feel like torture now looked like a good idea at the time they were implemented, decades ago.

However, most of those torturous points were from the onset, to attempt 100% compatibility with C.

Hum... No they didn't. People were creating new languages by that time just to reimplement them correctly.

The "edition" model is a big point in Rust's favor. They can make "backwards incompatible" syntax changes without infringing on the ability to compile older code.

Pre-C++11 was. Modern C++ not so much. Things have drastically improved and dare I say, it's more appropriate to call C++11 and greater C++ v2. That said the tooling around build/test/dependency management/versioning leave much to be desired for. But a combination of meson (for build), Catch (for test) and CMake for dependency management can go a long way.

Do you still need to write makefiles manually?

If you are using makefiles, you either write them manually or use a generator like Cmake or the autotools. Tools or scripts to automate build are required in all languages once you hit a certain level of heterogeneity/complexity.

What does the build system have to do with the language?

The current trend of combining the two concerns by having language-specific build systems (like Cargo) was a mistake, IMO.

Common grounds and uniformity - if every library were using it's own build system it becomes very hard to combine libraries. See c++ for example, when including a library you always have to either wrap the build, rewrite it to your build system or find a a way to prebuild. And every library is unique. Contrast this with other systems where you just add a line to your package.json file. Big red flag is that people come up with those header-only libraries or single .c-file only libraries, just to get around the problem of package management.

Language rules define dependency rules, that the build system is not aware of. For example transitive #include chains, requiring stuff like gcc -MMD to generate makefiles. This also improves IDE experience with suggestions on where to find imports instead of elementary error messages like "header file not found".

It has a lot to do with the language because the ease of adding external libraries has an enormous impact on the design choices made when writing code.

Also, the need for header files and disgusting hacks like unity builds just adds unnecessary friction.

> ... language because the ease of adding external libraries has an enormous impact on the design choices...

even if you could incorporate external libraries with zero impedance mismatch, you still have to _use_ the said libraries.

while there might be _marginal_ element of truth to that statement, however ease of stitching external libraries into your application has no bearing on either the programming language or the act of programming the application itself.

I don't understand what you're trying to say. Of course the effort to include the library in the project and keep it up to date has an impact on the decision whether I use it or whether I just roll my own. There is a reason that my Rust projects have dozens of dependencies whereas in C++ I basically restrict myself to boost or other header-only libraries.

> I don't understand what you're trying to say.

simple, ease of integrating external libraries into a project has _nothing_ to do with the programming language.

they are at best two orthogonal topics.

50% of the popularity of modern languages like golang and rust comes from the fact that building and dependency management is light years ahead of older languages.

remind me again on what that has to do with either the syntax or the semantics of the underlying programming language.

Your original argument was that the ease of dependency management doesn't change programming or the act of programming. I feel it encourages a compartmentalized approach to writing programs, pulling in dependencies as needed rather than relying on a giant library like Boost. Thus it does actually change the "act of programming", which is a vague term that can mean anything.

This is not mentioning all the upsides of having a easy build system from easy learning and community standpoints.

Ah. So some people like writing makefiles. Interesting.

Every languages must have generics and overloading? Gosh that’s one crazy opinion.

That's my opinion for system language. And even if purely superficial, it has already more argument that the previous comment.

But yes, if your language pretend to be a modern system language, you should yes. Not being able to write generic data structure or linear algebra containers in 2020 is a shame yes.

Well. I love the fact that Go code doesn’t have generics. Super clear to read. I must be a goof.