
What killed Haskell, could kill Rust, too - signa11
https://gist.github.com/graninas/22ab535d2913311e47a742c70f1d2f2b/c4e1b25cefe673a0c1d1bec4c24690121f31fa21
======
platz
this article was just posted 4 days ago:

[https://news.ycombinator.com/item?id=24401748](https://news.ycombinator.com/item?id=24401748)

see my comment there:

[https://news.ycombinator.com/item?id=24404593](https://news.ycombinator.com/item?id=24404593)

in summary: The reason why Haskell still doesn't really break through in the
corporate world is not a failure of arrogance, but a marketing failure in the
strictest sense of the word 'marketing'—which means prioritizing the right
features to target the right market.

~~~
bontaq
It's not targeted towards that. It's a 30 year old research language that is
still ahead, and I don't really see a reason why it should change in any way
towards businesses. If anything, it should lean more into research to keep
ahead. I do not believe catering to anything in the corporate area will result
in anything equivalent to the decades of research.

------
chillee
> As one might have guessed, this is not an essay. It's a transcript of the
> following talk by R. Martin with some substitutions made (SmallTalk ->
> Haskell, Ruby -> Rust, and others). You are free to make any conclusions
> from this.

I don't find this particularly interesting. Starting from the first
questionable statement,

> Not because Rust is Haskell without HKTs

I was wondering why the article had so many inaccuracies.

Fundamentally, Haskell did not clearly solve any particular problem with other
languages. There are a lot of cool things you can do in Haskell, and arguably,
there are problems in other languages that aren't issues in Haskell. But the
advantages of Haskell were never as clear cut as Rust.

In addition, Rust has already seen uptake on a level that Haskell never has.
What's the most important Haskell project? Pandoc? Haxl? On the other hand,
many companies have already started building core infra in Rust. Facebook with
Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with
Firefox.

I think Rust has a bright future, and I don't think the analogy with Haskell
is right at all.

EDIT: Judging from some of the other comments, I'm perhaps not surprised that
GPT-3 achieved some success on HN.

~~~
fluffything
> many companies have already started building core infra in Rust. Facebook
> with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla
> with Firefox.

You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big
company isn't using Rust at this point in production?

The main difference between Rust as Haskell is that, while I really like doing
competitive programming with Haskell, what I really like doing with Rust is
shipping products to customers.

In my free time, I don't use Rust, right now I mostly use Idris2. But the main
reason I can do that is that since we moved from C++ to Rust, nobody really
call us on the weekend anymore to fix something that can't wait till monday.

~~~
mkl
The Linux kernel isn't using Rust in production. They've said they're open to
the possibility, but that isn't even a start.

~~~
fluffything
All our linux kernel module and driver development have been using Rust for a
while. I've written a Linux kernel module in Rust that we use in production,
and so have many others.

What the Linux kernel is discussing is how to integrate these kernel modules
and drivers into the Linux tree. They are not discussing whether this is worth
doing, but how to do it. Linux is quite stable if you stick to the right APIs,
and maintaining these out-of-tree is not too bad, but the current situation is
not sustainable in general.

For us it doesn't matter, because our code is not open source. But it matters
to quite a bit of people.

~~~
mkl
Sure, but out-of-tree third party modules and drivers is not what the comment
I replied to said.

------
bad_user
> " _It 's a transcript of the following talk by R. Martin with some
> substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others)_"

I kept wondering why I'm wasting my time reading this, until the end, only to
find that this is the style of Uncle Bob.

------
CJefferson
I agree with this story, but I would add one more thing (which so far, Rust
doesn't suffer from, but is starting to sneak in with const functions).

Haskell suffered from people showing some great idea could be implemented in
Haskell, without actually producing working finished code people could see.

For me the classic example is ripgrep. I remember seeing tutorials about how
regexes could be nearly and efficently done in Haskell, but it was Rust and
ripgrep which made a day-to-day useful tool, which gives me confidence I can
also use Rust to do useful things.

Of course, I'm not saying everything has to be useful code, but having some
commonly used programs in your language does help it seem practical. Haskell
does have some great stuff (pandoc comes to mind), but very little considering
its age, and compared to Rust.

------
eecc
Ahm, last time I checked Haskell was alive and well. Nothing killed Haskell
because Haskell isn’t dead at all.

I guess what commercial-driven people don’t understand is that something isn’t
a failure if it simply doesn’t play their “market domination” success game and
doesn’t win by its metrics.

Go look at the photos of the first Haskell working groups; it’s an academic
tool. It can be used for commercial workloads but it was never developed with
that sole purpose in mind.

Haskellers play another game.

~~~
rfw300
Read the article. It’s a fictionalized dispatch from the 2030s.

------
the_mitsuhiko
I feel like this is overstating the popularity of Haskell greatly. I don’t
think Haskell was ever as popular as the article implies.

//edit: i just now realized that this post was not originally about Haskell
but Smalltalk. That makes more sense to me.

------
sn41
As a person who occasionally teaches programming languages, including Haskell,
I have found the PHP community to be exceptionally supportive when it comes to
documentation and examples. It has a very respectful attitude towards comments
on the documentation website as well, where good examples contributed by users
are eventually absorbed into the official documentation.

One of the least rigorous language in wide deployment has the best attitude
towards its users.

If other languages also adopt a friendly and approachable attitude towards
helping beginning, intermediate and advanced programmers, then I think that
the ecosystems of languages would be much healthier.

------
blaisio
Realistically the biggest problem with Rust today is the biggest problem it
has always had - it is too hard to write useful programs. Rust has seen some
success in very targeted use cases, but that isn't enough. I am 100% confident
that introducing Rust to my company would be a huge mistake.

~~~
Ar-Curunir
I mean, given that Amazon, Google, Facebook, Apple, Dropbox, Mozilla, etc are
all using Rust for important parts of their infrastructure, I think "making it
easy to write useful programs" is not one of Rust's weaknesses.

Yes, it's not as "easy" to pick up as C or Python, but it also prevents
footguns introduced by those languages.

~~~
tasogare
No, the companies you listed wrote a PR blog posts or two saying they use Rust
for a component or two, for a minor or internal product. Saying they are using
it for "important parts of their infrastructure" is quite a stretch...

~~~
lights0123
Is Dropbox's sync engine a minor product? The entire reason why Firefox has
gotten much faster over the past few years? Linkerd? What about Amazon's
Firecracker, powering Lambda and Fargate?

------
natertux
Can people tell me what useful program were produced in Haskell ? I know a few
for Ocaml but I dont know much Haskell, so dont know yet any useful program
written in Haskell. The program I know for Ocaml are: \- coccinelle (semantic
patching used by linux kernel devs) \- FramaC (formal verification) \- Coq
(proof assistant) \- Rust compiler (I think they bootstraped the language by
writting a compiler in ocaml first, now the compiler is written in rust
itself)

I just saw pandoc. It seems nice. I know parsec. But I would like to know what
kind of haskell programs are actually used in real life ? I know Jane Street
does all their dev in Ocaml. Is there similar company for Haskell ?

~~~
unhammer
One that I use all the time is shellcheck, and git-annex. Others in the
mainly-used-by-programmers-category include xmonad and hledger.
[https://github.com/owickstrom](https://github.com/owickstrom) has some GUI
Haskell apps.

Facebook's Sigma and [https://github.com/wireapp/wire-
server](https://github.com/wireapp/wire-server) may be the ones with the most
non-programmer users?

[http://postgrest.org/](http://postgrest.org/) and
[https://hasura.io/](https://hasura.io/) seem interesting.

[https://www.quora.com/What-is-the-largest-commercial-
program...](https://www.quora.com/What-is-the-largest-commercial-program-
written-in-Haskell?share=1) says the largest Haskell code-base is probably
Standard Chartered trading system.

more at [https://github.com/topics/haskell](https://github.com/topics/haskell)
and [https://serokell.io/blog/top-software-written-in-
haskell](https://serokell.io/blog/top-software-written-in-haskell)

------
cannabis_sam
Uncle bob’s original essay is largely worthless, and I’m genuinely struggling
to understand what value is to be extracted by transplanting a terrible
argument, onto an even less applicable programming language situation.

If anyone reading this has published anything resembling this tripe, please
stop programming and start crocheting, or some other, more useful hobby.

------
theonemind
I can see the use for Rust in writing an operating system or device
driver...but manual memory management for application software? That's a huge
step backwards. I really don't get why anyone uses Rust outside of low-level
or very performance-driven problem domains. Seems like a cargo cult or hype
machine, though certainly an improvement over C, it should be replacing C. It
might be better than Java, but what replaces Java should look more Haskelly.

I don't get it.

~~~
DasIch
You manage memory in Rust about as manually as you manage memory in Python, at
least in normal application code.

If you do very low level stuff, you might think about that a bit more but then
you have to in any case.

~~~
perryizgr8
> You manage memory in Rust about as manually as you manage memory in Python,

That's not true in my experience. Every single error the borrow checker throws
at you is in a sense "memory management". Rust forces me to think very hard
about memory, in all but the simplest toy programs.

You want anything to do with threads? Gear up for a long afternoon of fighting
the compiler before you fully understand your memory model and use it
properly. You want anything to do with linked lists? Same deal. You want
anything to do with async. Plan to spend 3 hours just to figure out what you
want to really do.

All this is memory management. Just in a different form compared to C/C++.
Python OTOH simply lets you forget that the computer exists. It's just you and
the problem you're solving. You pay for that with lack of speed and bloated
memory usage.

~~~
ufmace
I haven't written a huge amount of Rust, but I feel like I understand it well
enough to not have much of an issue with this. It seems like what Rust really
want you to think about is not so much memory management directly, but
ownership.

Linked lists? Rust just really doesn't like them. Better to use something else
instead. I can't remember ever wanting to use a linked list in a program I've
written though. I think you could argue that it's tough to write a linked list
implementation that really never leaks memory without a GC.

Threads? I'd argue that the stuff that Rust prevents are usually real bugs.
You might not hit those bugs right away, especially in a language with a GIL,
but they're there. Better to know they'll just never happen, no matter how
hard you push your threads.

For async, I guess I've had good luck with it so far. I still feel like I
don't really understand what's going on with Rust async and runtimes, but most
of the code I've written with it just works.

------
tapirl
What's the weak points (except not-very-easy-to-learn and complication speed)
of Rust? It listens perfect in every other aspect from the Rust promotion
articles.

~~~
higerordermap
You have to think about memory management. No matter what rust evangelists
say, you have to think about it. Well you don't have to worry about it like in
C. Of course rust is intended for safe performance-critical programming. GC is
fine for a significant portion of software.

The ruby / javascript webshit culture creeping in - lot of microdependencies
which can often be hard to audit. Projects like cargo-crev aren't getting any
traction.

Crates.io - the package registry lacks namespacing. That means package names
have to be choosen carefully and you might here phrases like "import data from
cabbage to rabbit using chickenshit crate" etc..

Async runtime fragmentation because stdlib doesn't provide one.

Very small standard library. Many things need you install a crate which might
come with 40 other dependencies. This kind of dependency counts are fine for
creating webshit but sometimes you need to audit your dependencies, especially
rust is intended for low level programming.

Horrible compile times. You might think rust has better compile times than C++
because it has a module system. But compile times are similar. Rustc emits
large chunks of LLVM IR. Not faulting people working on rust for this - but
they have a shortage of talent. And rust community's zealotry makes lot of
people sceptical.

A very zealot community which also happens to be very active on programming
link aggregators. You might get downvoted irrationally for simply critisizing
some flaw of rust. You keep on hearing zero-information / out of context
statements heralding rust. This is partly a consequence of influx of people
from blogging-heavy ruby and javascript communities. Especially the javascript
crowd has an Instagram feel to it. Some people among these have marginal
knowledge of computer science concepts and still show up everywhere heralding
rust.

No structural typing. This may be flaw or virtue - people from dynamic typed
languages may like structural typing as in Go or OCaml than nominal typing.

~~~
Aeolun
I cannot wrap my head around the uses of structural typing. Unless I tell
something to be a certain type I expect it not to be.

~~~
higerordermap
Well it is subjective. That's why I wrote it may be good or bad. But those
from dynamic typing backgrounds may find structural typing more natural. I
don't bother as long as there is a way to implement an interface without lot
of subclassing boilerplate.

------
tobyhinloopen
Is Rust a “times 5” language? Is it that good?

I can’t imagine any language being 5 times as productive as current mainstream
projects.

~~~
zik
Rust is approximately a 0.5 language. It takes longer to write but results in
more reliable code.

~~~
AstralStorm
Compared to what?

Java with its verbosity and relative lack of language features, partly hidden
by powerful but complex libraries? (Partly shared by more potent C#.)

C++ which is only slightly faster to write safely than Rust, you have to be
careful to not use unsafe subset, and generic code is more verbose?

C which has even fewer language features than Java and is harder to make safe
than C++?

Javascript where it is easy to write bugs, mostly of the null object kind, and
hard to handle exceptional situations? With mediocre debuggers? (Also thus
used with complex frameworks and libraries.)

Python or Ruby, where instead performance may require dirty tricks using extra
time?

Perl? PHP? (Do these even have well working debuggers?)

(Last 5 require additional code for tests due to dynamic nature to ensure
correctness too.)

Lisp, Haskell, SML or OCaml where there are fewer quality resources and
libraries available to programmers?

Perhaps the less used JVM/CLR or JS languages? (Groovy, Kotlin, CoffeeScript,
F# come to mind.)

~~~
perryizgr8
I find this sort of comparisons dubious. For me, who's a total rust noob, C is
10x faster than rust, because I need to keep looking up rust syntax for basic
things like for loop.

If I ever learn rust as well as I know C, I'm sure my speed won't be any
faster or slower. For me, the time to think up a solution is the major chunk,
writing it out seems to be nothing in comparison. So why would the language
affect that in a meaningful way?

Now, the one way rust can really give you time savings is the lack of entire
classes of bugs. I spend 90% of my time fixing bugs in the code my coworkers
and I have written over the past year. And most of them are really subtle
memory and thread safety problems that are difficult to track down. If rust
can eliminate that, I am willing to spend a year getting comfortable with the
language.

~~~
AstralStorm
I agree, if you're learning a language you will be slower with it. I wrote
this from a perspective of having used them for a reasonable time, and I used
most of the above fluently, except C#, Ruby, Perl, functional bunch, which
I've only used for small side projects. (And I have not mentioned Fortran
which we also used a bit, Borland Pascal, Object Pascal AKA Delphi, Visual
Basic, C64 Basic, QBasic, x86 and ARM assembly.)

I also know and are fluent in much weirder, atypical languages, almost
esolang, of CRM114 and Faust, and rare ones like Nemerle and Vala.

Rust is pretty pedestrian compared to some of these, rather powerful and
generally nice. Writing in Rust feels like writing in a cross of C# and C++20
(less verbose) with a sprinkling of SML/OCaml inspired syntax.

Main slowdown I got was having to write some foreign function interfaces, but
it was as nice at it as Python with Cython, nicer than say Vala or Haskell.
Much nicer than Java FFI - JNI. Also the common build and package system Cargo
was a bit different from what I'm used to, but not altogether bad.

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

~~~
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](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.

~~~
adwn
> _You are conflating two different things._

No, I'm not conflating anything. Your claim was hyperbolic and completely
false, and I refuted it.

> _[...] that doesn 't mean C++ is best language for optimizing i.e code
> written in C++ provides best opportunities for optimization._

You're moving the goalpost.

~~~
higerordermap
You didn't understand what I meant. I didn't move the goalpost. You understood
what I meant only after reading that sentence.

It is hard for one to claim compiler research is affected because of most
common implementation language. I don't know why you got that interpretation.

> Your claim was hyperbolic and completely false, and I refuted it.

Even GPT3 writes this after getting trained on some HN pages.

~~~
adwn
> _I didn 't move the goalpost._

Your original claim was: " _C /C++ literally killed compiler optimizations
research._" Your updated claim is: " _C++ is [not the] best language for
optimizing._ "

------
978e4721a
IMHO

The only problem with Haskell is that it's on a journey to dependent types and
they haven't released new standard yet.

It's future will depend on how good that future standard will be.

Rust is becoming more popular than Haskell because It's in a different niche
(no gc). Not because it's more productive to write Rust code.

Haskell is still much easier and faster to write than any other production
language.

Try to compare merge function for merge sort in Haskell and in other
languages.

~~~
jokethrowaway
As much as I love Haskell, once you start caring about performance, laziness
and GC gets in the way. Records are still a pain to deal with. Prelude is not
safe. Async exceptions bit you like in most other languages. String,
bytestring, text exist. There's also tons of extensions which I hope were a
default in a production language. The language is huge. I doubt having
dependent types is a factor.

Haskell is definitely my favourite language but I don't think it's the easiest
language to write. It could be, with the right set of defaults but it's not -
and it's by choice: Haskell wants to be a language to explore language design.

Rust is a production language and solves an interesting set of problems
(safety, gc spikes). I don't like the language particularly, but it's concise
and it has modern features. It gets stuff done and that's why it's getting
popular.

------
02020202
Rust is the language that everyone loves to talk about but no one really uses.

~~~
dochtman
Except Google, Microsoft, Apple, Amazon, Facebook, Mozilla, Dropbox, npm,
Discord and a whole bunch of other companies.

~~~
Annatar
You mean the Silicon Valley bubble of reality distortion. It's become so far
disconnected from the information technology industry that it's rapidly
becoming irrelevant. Outside, in the trenches, one won't find much Rust. Or
Haskell.

~~~
rapsey
Every one of those companies have extremely robust business models (ok npm I
have no idea about), high profits and are not going anywhere. You are
mistaking them for loss leader unicorn startups.

Rust is present in quite a lot of spaces. But companies outside sillicon
valley or even the US do not advertise what they are doing as much.

I am as far from SV as possible and a fulltime Rust dev.

~~~
brabel
You need to consider most of those companies are so big they probably use
every one of the top 20 languages. You argue as if they were ONLY using Rust.

~~~
Ar-Curunir
No, but they are using it in critical parts of some key products, and in those
parts, Rust is enabling them to write better code that requires less
maintenance.

------
devit
I don't think Haskell was ever successful other than as an inspiration for
parts of other programming languages like Rust.

They chose an unfamiliar syntax for no reason (and one that makes it hard to
learn abstractions, e.g. the practice to not distinguish between a -> (b -> c)
and (a x b) -> c), and non-strictness/space-leaks makes it unusable for
anything serious; plus, it doesn't support dependent types, so it's not even
good as a "theoretically perfect" language.

The only thing that can kill Rust is a better Rust, which means either a Rust
with dependent types, or a Rust that is somehow much easier to learn while not
sacrificing power and zero-cost abstraction (I believe the latter is likely
impossible, but maybe I'm wrong).

There is also the possibility of limited success for Rust, i.e. the fact that
it will kill C/C++ (which is inevitable), but fail to kill JavaScript and
Java/Go/C#.

~~~
tasogare
> There is also the possibility of limited success for Rust, i.e. the fact
> that it will kill C/C++ (which is inevitable), but fail to kill JavaScript
> and Java/Go/C#.

This is the most probable issue. Rust doesn’t offer anything new or useful for
a C# developer, yet have quite a number of drawbacks. Memory safety? Heck,
this is exactly what the CLR is about, hence the usual name of "managed code".

~~~
devit
Rust offers data-race freedom and in general correct concurrency (e.g. it's
impossible to access mutex-protected data if you don't hold the mutex),
correct handling of objects and invariant preservation due to shared xor
mutable (e.g. can't pass an array to a constructor that stores it in a field,
and then modify the array in unrelated code that kept a reference, breaking
the class invariants), better exception safety since exception propagation is
explicit, a macro system, deterministic finalization, no GC latency, reduced
memory utilization, better code generation, better cross-platform support,
ability to produce lighter C ABI dynamic libraries.

Rust doesn't really have fundamental drawbacks other than the fact that there
are more ways to store and refer to data (e.g. owned, borrowed, boxed,
reference-counted, etc.) and thus you need additional code where you want to
support more than one of them.

Of course there are ecosystem differences and learning curves.

------
m0zg
IMO what killed Haskell was weird syntax, and the lack of examples of
practical problems that are solved in Haskell. No matter which tutorial you
look at, it'd be this impenetrable high brow solution to some really trivial
problems that do not exist in the real world. Spherical cow in a vacuum, if
you will. If you wanted to learn by example, there, by and large, wasn't an
example to learn from. There still isn't. Epic fail.

Rust is in no danger of that. Lots of practical problems are being solved in
Rust. Lots of great examples are available. And while syntax around
borrow/reference annotations can be difficult to grasp, the rest of the syntax
is not too bizarre and is largely conformant to what people are used to.

------
johndoe42377
Unnecessary, redundant abstractions to impress other people is what plagued
Haskell libraries and therefore the whole ecosystem.

Language itself is a miracle of software engineering, and GHC and cabal are
decent.

~~~
jedisct1
The same thing is happening with Rust.

Many Rust crates are very difficult to understand and use, due to them using
tons of abstractions. Macros don’t help either.

As people get more and more familiar with Rust, they write more and more code
that only them can understand.

Languages such as Zig and Go are way more limited, and may require typing more
characters to achieve the same thing as in Rust, but they force people to
write simple, readable, maintainable code.

~~~
ahartmetz
The same thing is happening in C++. Just have a look at certain Boost
libraries. The thing is, usually you can use something else instead.

------
pmoriarty
_" Haskell in its time was at the forefront of functional programming. It was
the language that kind of characterized or epitomized what FP was really
about. There were other languages that were functional, but they were only
sort of functional. And of course, I'm talking about languages like Scala, or
JavaScript. Those were the two major competitors during the same mid 2000s."_

I guess this guy has never heard of OCaml or SML.

Though Haskell was a leader in the FP field, it was never the only language to
epitomize FP.

------
ColeyG
> Not because Rust is Haskell without HKTs. (Some of you know what that means,
> and the rest of you will wonder for a very long time)

It would make the paper more readable to newcomers to explain this. The author
was too smug and as a newer person in the Rust community I wish people who
cared enough about writing papers also cared about making them accessible :/

~~~
steveklabnik
They're not trying to make a real argument, see the very last bit. It's a
completely different talk with some words substituted.

(It stands for "higher kinded types", which is a feature Haskell is well-known
for that Rust lacks.)

------
hg35h4
Actually what kills it is Yet Another F... Language. Most new languages are
barely better then anything that already exists. After the initial
cheerleaders that started the project moved on, the company realizes it's hard
to find coders for the niche fad language of the period.

~~~
hg35h4
I must have angered fad language of the year fans :)

------
ur-whale
:%s/Haskell/Lisp/g

and get a valid story

------
KingOfCoders
Haskell didn't solve a real problem.

~~~
KingOfCoders
Hahahahaha - sure this got karma-killed on HN where people love Haskell
without having written one line of code. I've been paid for writing code in
10+ languages over 35 years, I have written Haskell code and Haskell does not
solve any real problem. Same goes for F# so no one uses it.

~~~
codygman
> I have written Haskell code and Haskell does not solve any real problem.
> Same goes for F# so no one uses

You are being down-voted for either lying or using such a ridiculous
definition of "no one" to push your agenda while disregarding facts.

~~~
tome
I don't think this kind of thing really needs to be engaged with. Let such
commenters stew in their own juice. Pushing back only adds flames to the fire.

~~~
KingOfCoders
Thanks though for helping my point. No argument that counters my post but an
ad hominem attack [1]. The state of our industry in 2020.

If you disagree with my point of

"Haskell didn't solve a real problem."

you could have a counter argument. Like "From my experience many companies
struggle with X, which is essential to their development effort. Haskell does
solve X nicely, a magnitude better than competing efforts like A, B and C from
working with Haskell in a larger company and B in a startup. My opinion that
companies do not use Haskell though is not that it doesn't solve a real
problem - as shown above - but because of S and T".

Or you could downvote

"Haskell didn't solve a real problem."

[1] I like to be labeled "such commenters" \- though I would prefer "such
people", it's meaner and has more punch. So if you go ad hominem, go right for
it.

------
ausjke
c++ advances fast there days and it has no problem to fend off rust to me. for
C, there is no way, it is the root of so many systems, imperfect, but worked
well so far.

plus rust is not as safe as expected in practice, the unsafe mode is
underrated.

