Hacker News new | ask | show | jobs
by three_legs 2112 days ago
Rust is already greater than Haskell. Not in programming terms, but in social terms. Rust won't die, or at least won't die the same death as Haskell. Rust, compared to Haskell, has already won.
1 comments

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.

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++.

> 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.

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

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.
> 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.

> ...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?

Yeah a lot of anti GC misinformation is spread on HN.
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.

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.

Well even in that regard I'd say Rust still wins.
> ...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.

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.

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.