[choeger]

Nope. With the success of Rust, Haskell has won. Finally.

The thing is, designing programming languages is a science, but practitioners often considered a craft. Things like the syntax of C++, the undefined behavior of C, the erasure semantics in Java, the weird semantics of Scala, or the minimal type system of Go all stem from that misconception.

Haskell took the science part serious. It is an academic language, but it tought people what can be done with a thorough design. Rust is the first language, as far as I can tell, that takes that mindset and improves practical programming. Rust is just objectively better than C++ in so many aspects. But it would not exist if it were not for Haskell and a plethora of PL research done in that language.

[pjmlp]

And the work done in Ada/SPARK, Cyclone, ATS.

Most likely Rust wouldn't exist had Java and .NET had been properly AOT native compiled since the first version like Delphi, Oberon, Modula-3, which would have taken away many use cases that people kept choosing C or C++ instead.

Or had AT&T not given up on Cyclone and eventually making into a common UNIX language, like it happened with C++.

[orthoxerox]

> Most likely Rust wouldn't exist had Java and .NET had been properly AOT native compiled since the first version

It's Go who wouldn't then exist, not Rust.

[pjmlp]

Only in the minds of GC haters that cannot grasp the concept of system enabled system programming languages.

Both of them wouldn't exist.

Go because it is basically Java 1.0 with AOT compilation.

Rust because C++ wouldn't have become as widespread as it currently is.

Stil trying to catch up with Xerox PARC,

http://toastytech.com/guis/cedar.html

[higerordermap]

Not to mention C/C++ literally killed compiler optimizations research. C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times and ignorance towards prior art has kept programming world 20 years behind.

[adwn]

> Not to mention C/C++ literally killed compiler optimizations research

They did what now?! I guess that famous 4-letter compilation/optimization library [1], which had its origins in academia, and which is extensively used by computer scientists as a base for their compiler optimization research, and which is written in C++, and which was originally targeted at compiling and optimizing C and C++ code, is just a figment of my imagination.

[1] It's LLVM.

[higerordermap]

You are conflating two different things. LLVM and GCC are __written__ in C++, that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.

The highest gains in optimization come not from bit twiddling transformations on integer arithmetic. They come from interprocedural analysis, especially since cache locality is so important these days. Optimizing compilers being written in X is not same as code in X being well optimizable.

C was considered slower in some cases than Fortran because aliasing information. __restrict flag in C fixed that. But C const is not transitive, and const-ness is convention rather than strictly enforced by compiler. This makes optimization hard across API / ABI boundaries. __restrict is also not transitive. If you analyse asm generated by sufficiently large program, you will sure find missed optimizations. C standard even permits any data to be accessed via a char *.

C++, while is C-speed because of direct compilation, value types and manual memory management, has too much of non-obvious performance traps in form of copy constructors, iterators etc.. std::vector can't use efficient realloc implementations, maps have to keep iterators valid, and you don't know when some copy constructor is going to be invoked and allocate memory. C++ is known as fast because its competitors in enterprise space were Java (which is often written with too many layers of indirection, has a memory hungry VM as most popular implementation and lacks value types) and unscientific [0] languages like python. Any sufficiently large C++ project that involves junior engineers will have undesired performance bottlenecks due to the idiosyncrasies of language and its ecosystem.

The massive layers of template implementations also cause performance bugs deep down, like those found in Microsoft's std::vector::insert implementation. Not to mention API practicess that encourage hidden object initialization / copying.

While I don't like the zealot instagram-ish community surrounding rust, I think the language is well designed and it has strong points in these areas. Any reference being immutable xor writeable provides ample opportunities for optimization[1]. Clone operations are explicit. And iterators are well designed. While there are small things like TrustedLen on iterators being introduced only recently, I think rust is much better optimizable than C++ is.

[1] These optimizations are held back by LLVM bug. No LLVM is not the best compiler possible as some people will make you believe. What it gets you in some more optimization passes, you lose in horrible compile times, and mediocre codebase. LLVM is mostly a proprietary-able version of GCC, while its existence has led to some good clang-based tooling in ecosystem, the monoculture is harming advances in compilers.

[otabdeveloper4]

> ...C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times...

These practical concerns have no place in an ISO standard.

Do you even know what the C++ committee's purpose is?

[higerordermap]

> Do you know what standard committee's purpose is?

Writing and selling more books.

All these are affected by evolution of the language. As the standards committee pushes more and more multi-layer templated library features as modern best practices, debug times suffer, error messages suffer, compile times suffer.

The C++ committee doesn't look at prior art in academic literature[0], they don't even consider many implementation concerns which only become apparent after implementations are widely used in real world. The gap between language designers and implementers is obvious.

There are C++ apologists who claim it is because of legacy. Yeah but I won't be buying those books every three years until they half-fix every misfeature in half broken template library way.

[higerordermap]

Yeah a lot of anti GC misinformation is spread on HN.

[three_legs]

You completely missed exactly my point. You're arguing in terms of programming, which I explicitly state:

> Not in programming terms, but in social terms.

[choeger]

But it is a social aspect. When I started PL research, practitioners scowled upon academia because they considered their legacy issues so much more important than these "Sound typesystems" or even "verification". They basically acted like high schoolers confronted with mathematics: "Yeah, but who needs that stuff? We know how our language parses and we don't care that our compiler is turing-complete as it essentially interprets a half-assed meta language on top, because we cannot see any practical relevance for static analysis besides intellisense. Let us instead discuss this feature here for that special industry use case and how we can abuse some existing keywords to get it implemented."

This attitude has changed drastically nowadays.

[three_legs]

Well even in that regard I'd say Rust still wins.

[otabdeveloper4]

> ...but it tought people what can be done with a thorough design.

Lazy-by-default is clearly wrong and clearly a broken design. If that is 'thorough', I fail to see any advantages to 'thoroughness' compared to just making it up as we go along.

[choeger]

Before you criticise a programming language you should really at least try to learn a bit of terminology. Otherwise you might come across as an uninformed douchebag. There is no such thing as "lazy by default". Haskell is just lazily evaluated, which is one of the well known possible evaluation strategies.

And regarding it being "wrong" and "broken", I presume of course that you found inherent problems in the G-machine that you just never came around to publish.

The alternative would be that you are just mentally unable to make the switch away from a strict call-by-value evaluation.

[tome]

As a big Haskell fan I love laziness and completely disagree with otabdeveloper4. On the other hand, others are entitled to their beliefs and opinions. Even if we think otabdeveloper4's assertion was false I don't think it needs any response as it wasn't an invitation to discussion. I think the Haskell community will come off far better if we avoid petty spats.