Yes. Multiple historical layers (...)

This is reaching a level of idiocy that's completely unheard of.

Just say you know nothing about what you're saying and you're completely oblivious, and sit out the rest of the discussion.

Well ok, but the concern is about the weaknesses, Mr. Stroustrup.

I don't think these discussions on "weaknesses" come from a place of intelectual honesty. None of these arguments even touches the fact that there are already a myriad of freely available static code analysis tools and memory profilers that do a very good job catching memory safety issues.

For some unexplainable reason, these criticisms of C++ always focus on a single strawman: these tools do not exist and no developer in the world cares about the topic.

I enjoyed the read so much that I've created a community dedicated to data structures and algorithms: !data_structures@programming.dev

Kotlin is IMO easier and less error prone

I'm no Kotlin expert, but I think Kotlin has a far more extensive core language and requires a heavier cognitive load to get up and running than Java.

It might have better developer experience and be less error-prone, but that comes at a price of admission that newbies have to pay.

There’s Tauri.

...and now your newbie has to onboard onto not only Rust (?!) but also HTML, CSS, and JavaScript to render "Hello World".

The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language.

You don't need to take my word for it. Google the topic and go through all the discussions. Even the ones in Rust's own forum get mixed responses, and that community is by its very nature very partial towards Rust.

Also, framing the discussion around newbies learning Rust as a first language is a strawman. The question is not whether if someone without any prior experience in programming can or cannot make and effort and write code in Rust. The question is which language to learn.

There are many programming languages to pick and choose from, and some are renowned to be very beginner friendly. Rust is not one of them.

If you want to make a case for Rust, it's up to you to prove that Rust is a better language to take first steps than any other programming language around. In my personal opinion, it is simply not possible to claim that Rust is better for this particular usecase than quite a sizable set of programming languages, including but not limited to Python. If you want to claim Rust is better suited then you need to make a case for it, and that is a challenging thing to pull off.

Java 15

The amount of unqualified people is staggering beginning with those who have no university education.

I don't see it as a problem, because qualifications without competence are meaningless.

You should be more concerned with how qualified people end up performing worse and being less educated, knowledgeable, and prepared than unqualified people.

Why not another scripting language (no compile necessary)? (...) If I could write my scripts in a nice syntax, but be sure my users will be able to use it effortlessly by distributing to them compiled versions, then that would make both of our lives easier!

Would it make sense to describe your idea as a typescript for bash or sh?

Unless I’m misreading, you brought monads into it.

You're misreading it. What do you think a 'Result' type is?

compiler support

That remark was on sum types, not monads. You do not need "compiler support" to have Result or neither monads in C++. There are already plenty of libraries that implement those. I use them in some of my projects. No compiler support needed.

As I said, sum types are not required for Return or Either monads. At best, they are convenient.

(...) what, pray tell, is the point of protocols, other than backward compatibility with historical fragile ducks (at the cost of future backwards compatibility)?

Got both of those wrong. The point of protocols is to have a way to validate duck typing errors by adding a single definition of a duck. This is not something that only applies to backwards compatible, nor does it affects backwards compatibility.

Why are people afraid of using real base classes?

You're missing the whole point of prototypes. The point of a prototype is that you want duck typing, not inheritance. Those are entirely different things, and with prototypes you only need to specify a single prototype and use it in a function definition, and it automatically validates each and any object passed to it without having to touch it's definition or add a base class.