Programming languages should not be made by people who want to make them.

@c0de517e I had a similar thought about compiler people - that compiler people designing a language are going to design a language that is good for... well, the compiler, not the user. :)

Which can result in benefits! Nicer error messages, faster compilation times, and less complexity in the toolchain. But also be less user-friendly and less practical.

I don't want to start a flame-war, but I heard from many Rust people that "Rust is so great because it was designed to be compiler friendly".

@BartWronski @c0de517e Counter pointer: Rust is not that compiler-friendly from the language design perspective. The long compile-time certainly shows that. (I guess it does have stricter control of aliasing, which helps optimization, but so do a lot of other languages)

Further, good tooling is usually just a good user experience. Who doesn't want more excellent error messages, faster compilation times, and less complexity in the toolchain? This especially benefits beginners.

@lesley @c0de517e to be fair to Rust compilation times - their compiler does a lot more stuff than C++ one on "normal code". And you can get abysmal compilation times with C++ and heavy use of metaprogramming as well... (Eigen...)

And sure, a lot of this translates to good user experience.
But it's also a spectrum - like you don't want to ship your tool internals and design decisions as the default UX. (Extreme example - git, which only makes sense as VCS when you understand how it works)

@lesley @c0de517e Picking the right level of abstraction is extremely challenging, especially since there is no "correct" level of abstraction for everyone and every problem. I deal with it in my own code, even just for me - so I understand that doing it "right" for a language (that later needs to be backward compatible) is almost a "mission impossible".