If you deploy the code on a large number of machines, especially out of your control, most of those don't apply. There is a large scale of problems that require/benefit from optimised non-GPU code: - OS and related tools - applications (e.g. image processing, spreadsheets, engineering applications) - browsers - games - compilers - low level libraries - databases

Yyou are probably using many of those and would not enjoy them being slower.

Even though I do like C++, I kind of agree.

As Wirth languages fanboy, I belive that if Java 1.0 had AOT compilation from day one, instead of leaving it to commercial third parties, and proper value types, the amount of C and C++'s adoption would have looked much different.

I wonder what Wirth would have to say about Java...

As you might imagine, not kind words.

"Modern languages like Java and C# may well be superior to old ones like Fortran, PL/I, and C, but they are far from perfect, and they could be much better. Their manuals of several hundred pages are an unmistakable symptom of their inadequacy. Engineers in industry, however, are rarely free from constraints. They supposedly they must be compatible with the rest of the world, and to deviate from established standards might be fatal."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/IEEE-An...

"In 1995 Sun Microsystems presented its language Java , fully 6 years after Oberon. It incorporated much of the "philosophy" of Oberon, but, alas, chose the style and syntax of C. Around 2000 Microsoft released its language C# as a strong competitor of Java, and Google followed in 2007 with its language Go, even more strongly following (the 18 years old) Oberon. The crux with these languages, which all became wide-spread due to strong industrial support, is their size and complexity. The ambition to provide everything to everybody prevailed and let them grow into complex bodies difficult to master."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/Compute...

Using complexity as an argument against Go is not really accurate in my point of view.

It is, because after Modula-2, Wirth's goals have been to produce the minimalist, type safe, systems programming language.

Oberon-2, Concurrent Pascal, Active Oberon and Zonnon variants were designed by students or together with ETHZ fellow researchers.

Oberon is smaller than Modula-2, and Oberon-07 lost features on each language revision.

So from our point of view Go isn't complex.

From my point of view Go still lacks several features, which Go 2.0 will kind of address.

However, from Wirth's point of view, which after being retired was still trying to design such minimal language, Go is indeed complex.

You can see this by reading the language reports.

https://www.inf.ethz.ch/personal/wirth/Oberon/index.html

This shouldn't have been downvoted.

I totally disagree, I think that era has been over for the last 20 years.

I keep coming back to a talk by Daniel J. Bernstein, that the assumptions computer science teaches about performance are wrong. His claim is for real programs most code is ice cold and a tiny percentage is hot. And that's getting worse not better as time goes on.

What important is; correctness, latency, compile time. Not raw speed.

In my experience that claim is very true before you fire up your profiler. But once you've optimized your program for a bit the profile gets a lot flatter.

I think if your programs profile is flat it means none of your code is actually in the hot path. It's buried behind library functions and OS calls.