This felt a bit off but the note at the bottom explains it:<p>> 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.<p>If there's a thing that has arguably "killed" haskell and could potentially kill rust too it's probably not this but rather packages bifurcating into a million different incompatible implementations of everything because so little is in the standard library.
Haskell is neat, and is one of those things I'll regularly come back to play with in my spare time. A lot of the ideas behind it have made me a better programmer. Rust I've never touched, though it looks interesting. But:<p>- In my daily work, the work that pays my bills, I regularly use software built in Rust, eg ripgrep.<p>- About the only time I ever cross paths with Haskell is in those times when I'm going out of my way to do so as part of my tech hobbying.<p>I think that's an important difference
Nothing sets off Rust fans quite like hinting it might still fizzle.<p>(Fizzling is a likely outcome for any new language, and does not suffer the mess of interpretation that "dying" carries.)<p>The thing is, there was a time when Ada had a lot more industry support and investment than Rust has today. OS kernels were coded in it. Aircraft and satellite instrumentation was coded in it, with billion-dollar contracts. Ada fizzled.<p>Erlang had rapidly growing support in the '90s. It had unique strengths. Erlang fizzled, too.<p>As hot as Rust is on HN, it could still fizzle in exactly the same way, for the same reasons. You might code something good in your work, but when you move on, will anybody be found to maintain it? People with Erlang skills today are most in demand to rewrite Erlang systems in something, <i>anything</i> not Erlang.<p>The rabid response and reflexive downvoting seen for anything even slightly critical of Rust betrays a level of insecurity that does not bode well for Rust.<p>For Rust to succeed, it probably needs at least a 10x improvement to compilation speed. That will probably require uncomfortable and difficult changes to the language and core libraries. Is there appetite for such changes among the faithful, who have come to terms with extremely slow builds already? To succeed, Rust needs to attract hundreds more for each current user. They have not accepted its weaknesses yet, and might never.<p>Rust needs to be easier to adopt. Rust is already as complicated to learn and use effectively as C++, but with nowhere near the level of industry support. Rust enthusiasts are little islands in the ocean; you have to go online to talk over design details, most places. It needs to not demand arcane, abstruse apparatus for ordinary things. (C++ has been good at sealing off difficult apparatus in easy-to-use libraries.)<p>When you think Rust must be really taking off already, consider that more people pick up C++ for the first time, in any week, than the total who are employed full time coding Rust. Rust really can still fizzle, as unpleasant as that is to consider. Vociferous advocacy is not what will save it. It needs much harder measures, that will appeal much more to people <i>not</i> now coding Rust than to those scattered few who already do. For now.
This is another screed by someone who thinks Rust's success is due to marketing or branding or devs who throw great parties.<p>Rust is the first memory-safe language without a garbage collector [*].<p><i>That</i> is why it is a big deal. Those are table stakes now.<p>Everything else is just styling and bonus points.<p>As for the article title: what killed Haskell was deviously unpredictable performance from large-scale programs. Haskell performance analysis is intractable for big programs. Rust's "just say no to GC" is about as diametrically opposed to that as you can possibly get.<p>[*] aside from research prototypes -- much respect to MLKit and Cyclone: <a href="https://elsman.com/mlkit/pdf/mlkit-4.3.0.pdf" rel="nofollow">https://elsman.com/mlkit/pdf/mlkit-4.3.0.pdf</a>
There never really seemed to be much of a hacker culture around haskell. People liked to talk about it much more than they liked to build things with it.<p>By contrast people really do seem to love building things in rust.
Haskell was always intended as a research language to promote innovation in computer science rather than as a general-purpose language trying to achieve mass adoption. In fact, "avoid success at all costs"[1] was the slogan they chose to reinforce the idea that the goal was not to achieve widespread usage. I'm not a serious haskell programmer, but I would heartily recommend messing around with it for a few weeks to anyone who wants to learn more about functional programming. It will expand your mind. One of my favourite ever hacking experiences was putting together a toy relational algebra in haskell over a weekend inspired by the string and list fusion papers (never actually managed to persuade ghc to actually optimise the fusion parts properly but that's another story).<p>Rust appears to have an entirely different goal, which is to take everything that has been learned over the last 40+ years of practical systems programming, and make a language that provides safety, speed and concurrency and works well for teams of programmers on large projects. [2] In that sense, it really is looking for wide adoption for the sorts of projects C and C++ have been used for during that time.<p>In its original version (Smalltalk and Ruby), this talk always struck me as a sort of fun polemic that probably didn't warrant too much serious thought, but here it's been stretched beyond belief, so I'm pretty surprised it's being posted here. Just as an example from the first paragraph, is there really anyone who seriously thinks rust is "Haskell without higher-kinded types"? That substitution has just been made because it vaguely fits the format of the original talk, but is just wildly off-base.<p>[1] <a href="https://haskell.foundation/whitepaper/" rel="nofollow">https://haskell.foundation/whitepaper/</a>
[2] I'm paraphrasing here, but check out <a href="https://doc.rust-lang.org/book/ch00-00-introduction.html" rel="nofollow">https://doc.rust-lang.org/book/ch00-00-introduction.html</a> for their explanation
Haskell is intentionally niche and experimental. This is the opposite ethos of Rust which aims for popularity and wants to be a mainstream language. They don't seem comparable at all and the parallels the author draws seem arbitrary and irrelevant.
TL;DR don't waste your time.<p>This is a transcript of a Robert C. Martin (Uncle Bob) talk with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others). The original talk was mediocre; the changes haven't improved it.
I still use haskell and like it. It has a nice incremental development style, a tiny bit like lisp, where you can grow a program step by step in the repl, guided by the types. It’s great. I think I’ve been using it for long enough that it just feels comfy so I won’t be stopping. I don’t really care if it’s not popular.
r/Haskell/Lisp -> same problems<p>The functional language conceit exists and its a problem.<p>It's interesting that Go is mentioned as a target of the conceit. Well, there is a LOT of important software in modern IT systems that is golang based. There has been impressive productivity from that language and its programmers, and I'm someone that doesn't like golang.<p>Functional languages just haven't produced something on the scale of Kubernetes, or a database, or a web framework, or... really anything. Not even something like Ruby on Rails, which is now replaced with JS flotsam/React, but was significant.<p>Functional languages seem to assume that you build it and they will come. It hasn't happened.... like ever. The quip is if you keep doing the same thing expecting a different outcome, then that is insanity.<p>What functional languages need is a significant application. Since they are (theoretically) better for multicore and we are in the age of core scaling rather than serial speed improvement, and have been for a decade... WHERE IS YOUR APP?<p>It has to be the IQ filter. I simply think that FP requires higher IQ people, and that filters out a massive amount of people that just want to get stuff done and go home to their families or rave. Once you get over a certain IQ threshold, then the people in that cohort actually repel other people. If you've ever been to a Mensa meeting, you should know what I mean.<p>I think Rust is fine, it is focused on practical goals: rewriting vulnerable C programs, improving Firefox speed and safety, etc.