16 ms·

What killed Haskell, could kill Rust, too

72 points by donut 6y ago

metreo 6y ago
Whole opinion piece is one long mixed metaphor. The programming styles of Haskell and Rust couldn't be more different. Fails to even mention the generational differences in language design that have occurred since the 1990s. Haskell was inspired by Miranda, Rust has its influence from C++ and Standard ML languages.
bsder 6y ago
Here's a starting difference between the two: Rust code uses "unsafe" and doesn't apologize about not being pure. Rust tries to minimize "unsafe" and encapsulate it, but acknowledges that it must exist. What's the Rust equivalent of "A monad is just a monoid in the category of endofunctors, what's the problem?" I can't really think of one. Maybe there's something in lifetimes (which can be pretty messy). Maybe: "Quit using doubly linked lists or the borrow checker will beat you senseless." In addition, there are lots of alternatives to Haskell that are almost as good. That isn't true of Rust. If you need systems programming, you have C, C++, maybe Ada. Rust is trying to drive a fairly difficult wedge into that area, but if it succeeds, the alternatives are scarce.
- Gibbon1 6y ago
  I think you are onto something. I'm a small brained primate. When I read "A monad is just a monoid in the category of endofunctors, what's the problem?" I feel that someone thinks they are being clever by being confusing and unhelpful. But when I read "Quit using doubly linked lists or the borrow checker will beat you senseless." I feel like someones trying to be helpful.
  - aallen8455 6y ago
    Its confusing because that's the mathematical definition of a monad that you need to know category theory to fully understand. In haskell a monad is just a way to run some effects sequentially, it's actually really basic stuff that every programmer already has an intuition for.
  - dpreed 6y ago
    What's the evidence Haskell has died? It seems to me that a fad has passed. The language is doing well. But the pretentious hipsters have moved on to their next obsession. Rust? Well, talk about hip and groovy blah blah. About as great as C++. Full of complicated features, all pretty much focused on nitpicking, not expressivity. Could become hipster stuff for small projects. Enterprise? It's missing the point. There's no Machine Learning, no UI tools, no communications abstraction, no nothing. Just storage allocation without garbage collection. Haskell will remain solid, but used by its aficionados. Rust will die as a niche language, and C/C++, sadly, will continue to dominate the low level coding, for better or for worse. Python and JavaScript will fill the UI centric space of Enterprise, with Python largely owning data centric stuff, and JS owning phone/tablet UX.
    - XMPPwocky 6y ago
      "Full of complicated features, all pretty much focused on nitpicking, not expressivity." What are a few of those features?
    - bsder 6y ago
      > Rust? Well, talk about hip and groovy blah blah. About as great as C++. I hope Rust winds up as "great" as C++ in terms of popularity. I don't need "web/crud enterprise" (there are a zillion languages for that) with it's infinite tower of abstractions, but I do need "embedded enterprise". And I'm really desperate for a language better than C for that.
      - pjmlp 6y ago
        > And I'm really desperate for a language better than C for that. I got introduced at it with Turbo C++ 1.0 for MS-DOS in 1993, never cared for C ever since, other than when not given any other alternative to chose from.
  - pcstl 6y ago
    "A monad is just a monoid in the category of endofunctors, what's the problem?" is a joke about how the Haskell community often forgets not everyone has a PhD in category theory. It's not a real thing Haskell programmers tell people, in my experience.
- thechao 6y ago
  I learned Haskell pre-Categorization, and modern Haskell tutorials make me sad. Haskell-without-mumbo-jumbo is a great expository language for learning about all sorts of sophisticated programming problem solving techniques, without having to deal with all the noise of Algol-derived languages. I was taught “monads” as: “ok, you wanted mutability? Here is how we program imperatively in Haskell”. Whole thing just hung together.
- srtjstjsj 6y ago
  Haskell has unsafe methods in the standard library. hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html
  - ghostwriter 6y ago
    It also has a strict type-safety compilation flag that disallows these methods https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskell.html#strict-type-safety-good-style https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
- ghostwriter 6y ago
  > In addition, there are lots of alternatives to Haskell that are almost as good. That isn't true of Rust. If you need systems programming, you have C, C++, maybe Ada. Rust is trying to drive a fairly difficult wedge into that area, but if it succeeds, the alternatives are scarce. In terms of purely technical ability to catch certain set of bugs at compile-time, Rust as a language is one-two generations behind ATS, that supports refinement types and theorem proving, whilst staying on the industrial side of the "(industrial) C <-> (academic) Coq" spectrum.
dsabanin 6y ago
My theory, based on a lot of experience, is that average developers are not “smart” enough to learn it, beyond simple tutorials. By smart I don’t mean IQ, but rather drive, intellectual curiosity and desire for a challenge, that I think is required for learning something so different from mainstream languages.
- alexbanks 6y ago
  > drive, intellectual curiosity and desire for a challenge literally none of these is related to intelligence. And even if they did, to assert that not wanting to learn Haskell has anything to do with "drive, intellectual curiosity and desire for a challenge" is ridiculous. There are a million reasons a person that exhibits all three of those qualities could opt not to.
  - tome 6y ago
    > literally none of these is related to intelligence. GP didn't mention the word "intelligence"
    - alexbanks 6y ago
      smart adjective, smart·er, smart·est. - having or showing quick intelligence or ready mental capability They said "smart", I said "intelligence".
      - dllthomas 6y ago
        We could arguably account "drive, intellectual curiosity and desire for a challenge" as particular mental capabilities.
        alexbanks 6y ago
        Every time Haskell is discussed, lots of valid critiques show up as to why it's not more successful, and yet every single time, without fail, the conversation devolves heavily into "People aren't smart enough." The person I was responding to literally said that Haskell wouldn't catch on because most developers aren't smart enough, and then defined "smart" as those three things. I am arguing a series of things. First, that being "smart" does not always mean those three things. Second, that being "smart" does not mean that you'd care to learn Haskell. Third, to suggest a tool isn't catching on because the members of the programming community aren't "smart" enough is so masturbatory it's actually insane. God forbid Haskell isn't catching on because of all the valid critiques that show up in every one of these threads and then gets dismissed under this same "Haskell smart" rhetoric. Haskell will not catch on because the community thinks it is too smart to have to actually accommodate the programming community. Simple as that.
EE84M3i 6y ago
>Some of you might remember the Reddit discussions in the mid 2000s. A bunch of people were there. And they were talking about cool math things there. In those talks, they often were snickering about other languages like Go. Golang was publicly announced at the end of 2009.
- deleted 6y ago
  [deleted]
codygman 6y ago
I've said as much there in the comments already, but this gist doesn't have many useful insights. The problem is that highly valuing "first-principles thinking" is wrongfully attributed to arrogance and seen as "ignoring truths from the 'dirty' mainstream".
- hitekker 6y ago
  After scanning through the linked gist, it looks like the author was trying to discuss your objections in good faith but you kept on trying to provoke him. That kind of behavior is borderline toxic, and I hope it's not representative of the Haskell community.
  - codygman 6y ago
    I was trying to reason with the author in good faith as well. Part of that means questioning large claims with no evidence. If you're going to accuse me of being toxic, please be explicit with quotes and what specifically was toxic rather than unconstructive allegations.
    - hitekker 6y ago
      Well, you argued back-and-forth on the gist for a few hours, wrote a comment on HN disparaging the gist, and then begin arguing with another random, unaffiliated commenter about your behavior in the gist. That's far from constructive and, I think, rather close to toxic.
      - codygman 6y ago
        Are you saying it's toxic that I argued with multiple people in multiple places to verify whether their claims were true or false?
      - saithound 6y ago
        Let me rephrase what you wrote: "Someone had a long conversation on the Internet about a topic that good hackers would find interesting, came to a conclusion, and then shared that conclusion with others." That's not just not toxic, but is the whole purpose of this website.
lacker 6y ago
So what killed Haskell is the parochialism, the inability to address the needs of the Enterprise. I don’t think so. What killed Haskell in mainstream programming is its weird syntax. Rust looks like C so it passed that first sanity check. People hate that something so aesthetically basic could define the success of programming languages, but it seems pretty clear at this point. Languages have to basically look like C in order to be popular.
- metreo 6y ago
  Come to think of it you could take the arguments made here and replace Haskell with Perl, and then also replace Rust with Haskell and it would still make more sense.
  - wolco 6y ago
    Perl was mainstream and exists in many corners. Haskell was never mainstream.
  - moonbug 6y ago
    except that 15 years ago, Perl was everywhere
  - xupybd 6y ago
    I worked with a perl backend for years. The frame work was very good but perl was horrible. I hate the syntax and really hate having to reference and dereference. It is not that hard to do but it's just so annoying.
- Daishiman 6y ago
  What killed Haskell is its obsession with monad-as-burrito tutorials that had nothing to do with getting anything useful done, as well as considering writing a PDF in Latex as an acceptable substitute for a blog post or documentation. Nothing in Haskell was sufficiently interesting to justify overcoming the conceptual barriers and different culture.
  - alexbanks 6y ago
tengbretson 6y ago
> In Go, I can do amazing things with monads. Can you tho?
non-entity 6y ago
Of all the Haskell programers I've met and interacted with both irl and online not one came off as "arrogant" (there is a programming language who's hardcore fans tend to be a bit more, uh, eccentric, in my experience, but im not going to name it at the time).
- xdavidliu 6y ago
  does it rhyme with crisp?
  - msla 6y ago
    No, it rhymes with crust.
  - non-entity 6y ago
    perhaps
- metreo 6y ago
  College professor who was the "biggest" Haskell proponent I've ever met, had a reputation among the department best described in units of micro-Dijkstra's, not undeserved mind you.
srtjstjsj 6y ago
Title is trolling > It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others).
- dang 6y ago
  That talk is https://www.youtube.com/watch?v=YX3iRjKj7C0 https://www.youtube.com/watch?v=YX3iRjKj7C0. Another thread on this article: https://news.ycombinator.com/item?id=24449927 https://news.ycombinator.com/item?id=24449927
platz 6y ago
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. A large proportion of the talk linked below is based on the book “Crossing the Chasm". The book was originally written for startups trying to break into the mainstream, and this talk adopts that book to programming laguage (or tools more generally), particularly regarding Haskell. Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA Gabriel also suggests that in order to "cross the chasm" you have to offer a best-in-class experience in some area, and suggests that Haskellers adapt the language to facilitating building interpreters, which is it particularly well suited for. So, base on the above, I don't think the OP's emphasis on the emotional analysis of Haskell programmers is anything more than the OP's just-so story, although the notion of parochialism may have some crossover with the concept of marketing.
xfer 6y ago
I would say tooling is the main reason haskell is not adopted even in personal projects much. The package manager used to be pretty bad, poor editor support is still the biggest obstacle for new-comers. Combine that with the fact that students are taught a procedural-style language in their school and you have small percentage of new-comers looking at it. Rust have an advantage here since it is procedural-ish language. But these problems require money and expertise and marketing from people who already are in the field, so a bit of chicken-egg problem. Arrogance is the last thing i would say about haskell community and i have interacted with them on reddit and irc. So not sure about that. The thing about ignoring enterprise needs is that the enterprises need to invest in the things they want. Those that do contribute are using haskell in enterprises that fit their needs. Otherwise it is primarily a research driven language. It's not very surprising that Go/Java is doing very well, looking at the investment done by the companies behind it.
- mark_l_watson 6y ago
  I think Haskell tooling is pretty good now. VSCode with the Haskell plugins is simple to setup. I used to use Emacs for Haskell, but the VSCode support is now so good that I just take the easy route. Stack and stackage made package management much easier for me. I am an enthusiastic, but not great Haskell programmer so I like running the ‘hlint’ linter program for hints on improving my code. My heart is really with Common Lisp, but Haskell is also a pleasure to use and the tooling seems much better to me than five years ago.
  - metreo 6y ago
    I think Haskell versioning is highly bifurcated.
    - codygman 6y ago
      You mean like SemVer vs the default whose name I can't remember?
      - metreo 6y ago
throw149102 6y ago
It seems strange to consider Haskell as dead when its motto was "Avoid success at all costs". Haskell wasn't popular in enterprise settings because it didn't want to sacrifice being a good language for being a popular one. Haskell was/is very successful if you base it on it's own terms. Now, that goal can be debated, it could be argued that an unpopular language is never that good because it is unpopular, but that's a different argument.
- erik_seaberg 6y ago
  It’s bittersweet to vaguely know a good language I’ve never been able to use professionally.
- Aeronwen 6y ago
  This. It's the next ALGOL. Let the next dozen popular languages cherry pick the good parts from it and don't worry about people using it directly.
- PCChris 6y ago
  > it didn't want to sacrifice being a good language for being a popular one I think this is the key. The motto that you mentioned is often clarified/refined as something like "avoid 'success at all costs'".
- addicted 6y ago
  Exactly. Haskell has explicitly been run and planned around not being successful because real production usage and success will require the maintainers to limit breaking changes, for example, which defeats its purpose as a language for experimentation and research.
Aerroon 6y ago
We actually had a functional programming class in university, where the focus was on Haskell. The main impression that seemed to permeate the class was "Haskell is hard". There was a lot of grumbling. Nowhere near as much as about Prolog in Logical Programming though. They were both thrown into the same pile of "must get through this class" though. I'm not really sure whether it was because of the way it was taught or whether Haskell is inherently more difficult. I do think that a class like that might've hurt the language's adoption among the students though. (Or maybe my impression is simply biased by my own experience.)
kovac 6y ago
I think for a language to gain traction today in the mainstream, it needs to be backed by a large company. If the language is web technologies oriented, it's all the more likely. The reason is because lots of developers nowadays are working in web related stuff. And when it's backed by a big company like Google or Microsoft, kids will at least learn it to try and land a job at one of those companies. Also, these big companies will support many useful apis in that language which will attract mainstream developers as they can start building useful stuff quickly. I wanted to learn a functional programming language and did a lot of research about which language to start with. Initially I looked at Haskell but ended up going with F# because the tooling was a lot better and the documentation from Microsoft was really good. Also, I read quite a few posts by those who worked fulltime, paid F# jobs. I loved the functional style. I think it's a shame that it's not mainstream. But then when I tried to do something non trivial, like network programming, I had to use OOP C# style types in F#. That was just fugly and made the paradigm look weak because OOP constructs could do it more easily than functional constructs. Other than the elegance of the functional programming paradigm, it didn't seem to offer much in terms of jobs because I can't really see large numbers of people suddenly picking up functional programming (which isn't easy) and building massive applications specially with the whole cloud based SaaS stuff that's happening right now.
- xupybd 6y ago
  I'm learning F# now for similar reasons. I'm guessing that the industry is moving in a more functional direction. I want to learn a functional language to keep up. I also like the claims that you can lower runtime bugs with good functional style.
benreesman 6y ago
I’m far from an expert Haskell programmer, but I have written it for money and had the code run on big fleets. Haskell is really cool, but IMHO is held back from practical adoption by two things, one technical, one cultural: - Lazy by default maps weirdly onto von Neumann machines. Laziness is cool but doesn’t pull it’s weight as the default. Performance in time and space is even harder to reason about than it already is on modern architectures, and debugging is...different. - GHC extensions are like crack for the kind of people who overdo it with C++ templates. Pragmatic, legible Haskell in the RWH tradition isn’t safe from the type-theory zealots even in a production system. Cool research goes on in GHC, but it’s hard to keep everyone’s hand out of that cookie jar in prod.
- Joker_vD 6y ago
  I've briefly looked into the implementation details of lazy languages and yeah, while that Spineless, Tagless G-Machine is a pretty neat thing, it results in rather unorthodox code representation. And yes, reasoning about memory consumption and having each library give you 2 versions (strict and lazy) of their data structures is tiresome. Why can't strictness/lazyness be parameterized away?
tome 6y ago
What is killing Haskell, according to this discussion * marketing failure * lazy by default * GHC extensions * its weird syntax * its obsession with monad-as-burrito tutorials * pretty hostile haskell-centric spaces * not backed by a large company * bad university classes * tooling * average developers are not “smart” enough to learn it * no payback for learning Haskell skills
heavenlyblue 6y ago
I think comparing Rust to Haskell for their "similar" success is kind of dumb. Everybody wanted to program in Haskell, yet nobody build a proper package management and/or compiler version management solution for Haskell up until very late. If Haskell was indeed one of those "everybody wants to do it" languages, then making it easy to approach from the infrastructure perspective would be the first thing to do.
sklarsa 6y ago
Rust will be fine, as long as people continue using it to produce high-quality tools like ripgrep (rg) and xsv
StillBored 6y ago
I've assumed that rust is going to be killed by a "-enforce-no-mutate-single-owner" or similar flag to gcc (or some linter) that restricts C++ code to some subset/style that nails the majority of what rust brings to the table. IMHO, like many other language paradigms, once you understand the core tenents of rust you could write "rust code" in many other languages. The difference being that those other languages don't _yet_ have flags/etc to enforce a rust like style.
- pjmlp 6y ago
  Actually they do, it just happens to be WIP on clang and MSVC++. CppCon 2019: “Lifetime analysis for everyone” https://www.youtube.com/watch?v=d67kfSnhbpA https://www.youtube.com/watch?v=d67kfSnhbpA
- rcxdude 6y ago
  I wouldn't bet on it. Firstly, rust has value as a "C++ without the cruft" language even without safety as a USP, and secondly rust had to do a huge amount of design work to get the language to work in a way such that the kind of static analysis it does is reasonbaly feasible. C++ would need to adopt more paradigms and then create a subset of itself in order for this to work (there are such designs in the works like 'C++ Core', but they have already had to give up achieving the same level of safety as Rust gives).
smabie 6y ago
Though Haskell is nice in many ways, I would choose OCaml for a commercial project over Haskell any day. OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism. Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that. If something was going to kill Haskell, it would OCaml, not Javascript or some other language. I would feel very comfortable running a business on OCaml, Haskell, not so much.
- codygman 6y ago
  > Though Haskell is nice in many ways, I would choose OCaml for a commercial project over Haskell any day. As a counter-point I'd say the opposite: I choose Haskell :) > OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism. Is this a plus? Practical and pragmatism seem to be unlaterally considered a positive, but when does "pragmatism" just start to mean "unprincipled"? There's much talk about when being too principled gets in the way of getting things done, but I'm wondering what your position on the opposite is here. What are your thoughts on 1) Real-world thinking 2) first-principles thining and 3) the balance of each that is ideal in software-engineering? > Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that. Haskell was designed to get stuff done too, just maybe not quite the same way. If you ever had an inkling of "maybe people in industry are outright dismissing research too fast" you might like it. >> If something was going to kill Haskell, it would OCaml, not Javascript or some other language. > I would feel very comfortable running a business on OCaml, Haskell, not so much. I'd feel comfortable with either. I agree it'd have to be something at least as strongly typed as Ocaml to kill Haskell as well.
  - smabie 6y ago
    I think I came off as too pro-Ocaml. I personally think OCaml has a ton of problems, and like you suggest, is unprincipled. Features are added with very little thought, and OCaml code can get very ugly trying to replicate the kind of power Haskell has built in. But, all in all, I like OCaml more than Haskell. Laziness by default is a mistake and GHC's ever growing list of language variants is kind of stupid. Moreover, Haskell's monad based effect system is a lot less useful than people think it is. In my mind, the main benefit of tracking effects is to enable aggressive compiler optimization, not increased safety. Haskell's effect system imposes a heavy burden on the developer, with little benefit. Ocaml imposes almost no burden in doing whatever the hell you want, but the language is messy and full of decades of hacks and eye sores. I'm one of the rare souls that actually likes OCaml's OO system and I actually think that the language would be a lot better if the standard library and other code leveraged it. As it stands, functors aren't expressive enough for many use cases and function as shitty classes. Here's what I want from a functional language: Something that looks like OCaml, but get rid of the functors, cleans up the syntax, supports HKT, supports function polymorphism, supports easy to write macros (ppx is so fucking shitty), and make it have Nim like OO call syntax. Every function that takes a type as it's first argument can be called as a method using the dot syntax. Also, have the language compile to a native executable, and make the executable and runtime really really small. OCaml gets a lot about performance right, but the 20mb executables (no tree shaking) is unacceptable.
dpc_pw 6y ago
What does it have to do with Rust? I mean Rust shows absolutely no sign of problems that Haskell had. It's very practical, learns from everywhere it can find a good idea, tooling is great, marketing is great, community is nice and inclusive.
TheGoddessInari 6y ago
I don't feel like I can take it seriously when it talks about Haskell devs on Reddit snickering about Go "in the mid 2000s".
deleted 6y ago
[deleted]
brundolf 6y ago
> 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. No wonder it felt like the author was living in a different universe.
axilmar 6y ago
My personal experience with Haskell hackers went like this: -I used to hang out at lambda-the-ultimate, in which haskell was considered god sent and c++ a toy language. At the time, I was heavy into writing simulation software, which meant c++ all the way, so I tried to understand haskell and its advantages over c++, but my attempts ended up being mocked. I stopped visiting that site. -I tried to open some debates about Haskell on reddit, where someone told me they will answer my haskell questions only if I told them a specific mathematical definition on some properties of functions. I didn't know the reply, I was a programmer after all, not a mathematician. Said person left me in the cold. -again on reddit, I was trying the debate the usefulness of haskell regarding simulation software, which relies heavily on updating variables, but I never got straight answers. To this day, I still do not know if haskell code actually can update variables in place or it only simulates updating of variables. Someone suggested using lens, and although I understand the abstraction, it still has not solved my question if haskell can update variables in place. Why I was so interested in this aspect, i.e. in place updating? I wrote simulation software and after that game software for a living, and it matters to me because I want to be able to reason about the performance of my program. I don't want to have data be duplicated behind my back. To cut the long story short, my haskell questions go unanswered to this day, I was very disappointed, and since I have great experience in imperative programming languages, I usually write programs that are correct as soon as they are compiled, which is what the haskell advantage is supposed to be. So I don't see any benefit from haskell, and I won't recommend it to my company or my colleagues. Am I wrong regarding haskell? perhaps, but I am not interested any more in 'trying out' languages of dubious gains, nor am I interested in dealing with juvenile behaviors. I tried Rust because it had a serious advantage over C++ (namely, object lifetimes), and I will recommend Rust, but my patience for and interest in haskell is virtually non-existent at this point.
- shirogane86x 6y ago
  I personally haven't had the same experience as you (I personally find the Haskell community quite pleasant, especially in the functional-programming slack server), but I'll try and answer (probably in an incomplete way) your question about updates. Haskell can, in fact, update variables. Mostly through 2 mechanisms: - ST (a computation containing local, mutable state, that cannot escape its scope) [1] - IORef (mutable, thread-safe variables that only work in IO). [2] The other (and usually more common way) of doing "mutable" state in Haskell is through State, which technically doesn't update the variable in-place, but simply modifies the variable and passes a copy to the rest of the computation (although, as far as I'm aware, a lot of the time this step gets optimized away). That said, if your main field of expertise is simulation programs where performance and space efficiency are very important, then Haskell is probably not a great fit (cause not only is it based on a GC, it's also lazy, which can sometimes mess with the performance of your code, not speed-wise but memory usage-wise). Hopefully this could be mitigated in some way in the coming years when Linear types become viable for efficient resource usage (Linear types ideally could grant us some sort of Rust-like resource management) [1] https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad-ST.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr... [2] https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-IORef.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-...

72 points by donut 6y ago

Whole opinion piece is one long mixed metaphor. The programming styles of Haskell and Rust couldn't be more different. Fails to even mention the generational differences in language design that have occurred since the 1990s. Haskell was inspired by Miranda, Rust has its influence from C++ and Standard ML languages.

bsder 6y ago

Here's a starting difference between the two: Rust code uses "unsafe" and doesn't apologize about not being pure. Rust tries to minimize "unsafe" and encapsulate it, but acknowledges that it must exist. What's the Rust equivalent of "A monad is just a monoid in the category of endofunctors, what's the problem?" I can't really think of one. Maybe there's something in lifetimes (which can be pretty messy). Maybe: "Quit using doubly linked lists or the borrow checker will beat you senseless." In addition, there are lots of alternatives to Haskell that are almost as good. That isn't true of Rust. If you need systems programming, you have C, C++, maybe Ada. Rust is trying to drive a fairly difficult wedge into that area, but if it succeeds, the alternatives are scarce.

Gibbon1 6y ago
I think you are onto something. I'm a small brained primate. When I read "A monad is just a monoid in the category of endofunctors, what's the problem?" I feel that someone thinks they are being clever by being confusing and unhelpful. But when I read "Quit using doubly linked lists or the borrow checker will beat you senseless." I feel like someones trying to be helpful.
- aallen8455 6y ago
  Its confusing because that's the mathematical definition of a monad that you need to know category theory to fully understand. In haskell a monad is just a way to run some effects sequentially, it's actually really basic stuff that every programmer already has an intuition for.
- dpreed 6y ago
  What's the evidence Haskell has died? It seems to me that a fad has passed. The language is doing well. But the pretentious hipsters have moved on to their next obsession. Rust? Well, talk about hip and groovy blah blah. About as great as C++. Full of complicated features, all pretty much focused on nitpicking, not expressivity. Could become hipster stuff for small projects. Enterprise? It's missing the point. There's no Machine Learning, no UI tools, no communications abstraction, no nothing. Just storage allocation without garbage collection. Haskell will remain solid, but used by its aficionados. Rust will die as a niche language, and C/C++, sadly, will continue to dominate the low level coding, for better or for worse. Python and JavaScript will fill the UI centric space of Enterprise, with Python largely owning data centric stuff, and JS owning phone/tablet UX.
  - XMPPwocky 6y ago
    "Full of complicated features, all pretty much focused on nitpicking, not expressivity." What are a few of those features?
  - bsder 6y ago
    > Rust? Well, talk about hip and groovy blah blah. About as great as C++. I hope Rust winds up as "great" as C++ in terms of popularity. I don't need "web/crud enterprise" (there are a zillion languages for that) with it's infinite tower of abstractions, but I do need "embedded enterprise". And I'm really desperate for a language better than C for that.
    - pjmlp 6y ago
      > And I'm really desperate for a language better than C for that. I got introduced at it with Turbo C++ 1.0 for MS-DOS in 1993, never cared for C ever since, other than when not given any other alternative to chose from.
- pcstl 6y ago
  "A monad is just a monoid in the category of endofunctors, what's the problem?" is a joke about how the Haskell community often forgets not everyone has a PhD in category theory. It's not a real thing Haskell programmers tell people, in my experience.
thechao 6y ago
I learned Haskell pre-Categorization, and modern Haskell tutorials make me sad. Haskell-without-mumbo-jumbo is a great expository language for learning about all sorts of sophisticated programming problem solving techniques, without having to deal with all the noise of Algol-derived languages. I was taught “monads” as: “ok, you wanted mutability? Here is how we program imperatively in Haskell”. Whole thing just hung together.
srtjstjsj 6y ago
Haskell has unsafe methods in the standard library. hackage.haskell.org/package/base-4.14.0.0/docs/System-IO-Unsafe.html
- ghostwriter 6y ago
  It also has a strict type-safety compilation flag that disallows these methods https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskell.html#strict-type-safety-good-style https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
ghostwriter 6y ago
> In addition, there are lots of alternatives to Haskell that are almost as good. That isn't true of Rust. If you need systems programming, you have C, C++, maybe Ada. Rust is trying to drive a fairly difficult wedge into that area, but if it succeeds, the alternatives are scarce. In terms of purely technical ability to catch certain set of bugs at compile-time, Rust as a language is one-two generations behind ATS, that supports refinement types and theorem proving, whilst staying on the industrial side of the "(industrial) C <-> (academic) Coq" spectrum.

dsabanin 6y ago

My theory, based on a lot of experience, is that average developers are not “smart” enough to learn it, beyond simple tutorials. By smart I don’t mean IQ, but rather drive, intellectual curiosity and desire for a challenge, that I think is required for learning something so different from mainstream languages.

alexbanks 6y ago
> drive, intellectual curiosity and desire for a challenge literally none of these is related to intelligence. And even if they did, to assert that not wanting to learn Haskell has anything to do with "drive, intellectual curiosity and desire for a challenge" is ridiculous. There are a million reasons a person that exhibits all three of those qualities could opt not to.
- tome 6y ago
  > literally none of these is related to intelligence. GP didn't mention the word "intelligence"
  - alexbanks 6y ago
    smart adjective, smart·er, smart·est. - having or showing quick intelligence or ready mental capability They said "smart", I said "intelligence".
    - dllthomas 6y ago
      We could arguably account "drive, intellectual curiosity and desire for a challenge" as particular mental capabilities.
      - alexbanks 6y ago
        Every time Haskell is discussed, lots of valid critiques show up as to why it's not more successful, and yet every single time, without fail, the conversation devolves heavily into "People aren't smart enough." The person I was responding to literally said that Haskell wouldn't catch on because most developers aren't smart enough, and then defined "smart" as those three things. I am arguing a series of things. First, that being "smart" does not always mean those three things. Second, that being "smart" does not mean that you'd care to learn Haskell. Third, to suggest a tool isn't catching on because the members of the programming community aren't "smart" enough is so masturbatory it's actually insane. God forbid Haskell isn't catching on because of all the valid critiques that show up in every one of these threads and then gets dismissed under this same "Haskell smart" rhetoric. Haskell will not catch on because the community thinks it is too smart to have to actually accommodate the programming community. Simple as that.

EE84M3i 6y ago

>Some of you might remember the Reddit discussions in the mid 2000s. A bunch of people were there. And they were talking about cool math things there. In those talks, they often were snickering about other languages like Go. Golang was publicly announced at the end of 2009.

deleted 6y ago
[deleted]

codygman 6y ago

I've said as much there in the comments already, but this gist doesn't have many useful insights. The problem is that highly valuing "first-principles thinking" is wrongfully attributed to arrogance and seen as "ignoring truths from the 'dirty' mainstream".

hitekker 6y ago
After scanning through the linked gist, it looks like the author was trying to discuss your objections in good faith but you kept on trying to provoke him. That kind of behavior is borderline toxic, and I hope it's not representative of the Haskell community.
- codygman 6y ago
  I was trying to reason with the author in good faith as well. Part of that means questioning large claims with no evidence. If you're going to accuse me of being toxic, please be explicit with quotes and what specifically was toxic rather than unconstructive allegations.
  - hitekker 6y ago
    Well, you argued back-and-forth on the gist for a few hours, wrote a comment on HN disparaging the gist, and then begin arguing with another random, unaffiliated commenter about your behavior in the gist. That's far from constructive and, I think, rather close to toxic.
    - codygman 6y ago
      Are you saying it's toxic that I argued with multiple people in multiple places to verify whether their claims were true or false?
    - saithound 6y ago
      Let me rephrase what you wrote: "Someone had a long conversation on the Internet about a topic that good hackers would find interesting, came to a conclusion, and then shared that conclusion with others." That's not just not toxic, but is the whole purpose of this website.

lacker 6y ago

So what killed Haskell is the parochialism, the inability to address the needs of the Enterprise. I don’t think so. What killed Haskell in mainstream programming is its weird syntax. Rust looks like C so it passed that first sanity check. People hate that something so aesthetically basic could define the success of programming languages, but it seems pretty clear at this point. Languages have to basically look like C in order to be popular.

metreo 6y ago
Come to think of it you could take the arguments made here and replace Haskell with Perl, and then also replace Rust with Haskell and it would still make more sense.
- wolco 6y ago
  Perl was mainstream and exists in many corners. Haskell was never mainstream.
- moonbug 6y ago
  except that 15 years ago, Perl was everywhere
- xupybd 6y ago
  I worked with a perl backend for years. The frame work was very good but perl was horrible. I hate the syntax and really hate having to reference and dereference. It is not that hard to do but it's just so annoying.
Daishiman 6y ago
What killed Haskell is its obsession with monad-as-burrito tutorials that had nothing to do with getting anything useful done, as well as considering writing a PDF in Latex as an acceptable substitute for a blog post or documentation. Nothing in Haskell was sufficiently interesting to justify overcoming the conceptual barriers and different culture.
- alexbanks 6y ago

tengbretson 6y ago

> In Go, I can do amazing things with monads. Can you tho?

non-entity 6y ago

Of all the Haskell programers I've met and interacted with both irl and online not one came off as "arrogant" (there is a programming language who's hardcore fans tend to be a bit more, uh, eccentric, in my experience, but im not going to name it at the time).

xdavidliu 6y ago
does it rhyme with crisp?
- msla 6y ago
  No, it rhymes with crust.
- non-entity 6y ago
  perhaps
metreo 6y ago
College professor who was the "biggest" Haskell proponent I've ever met, had a reputation among the department best described in units of micro-Dijkstra's, not undeserved mind you.

srtjstjsj 6y ago

Title is trolling > It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others).

dang 6y ago
That talk is https://www.youtube.com/watch?v=YX3iRjKj7C0 https://www.youtube.com/watch?v=YX3iRjKj7C0. Another thread on this article: https://news.ycombinator.com/item?id=24449927 https://news.ycombinator.com/item?id=24449927

platz 6y ago

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. A large proportion of the talk linked below is based on the book “Crossing the Chasm". The book was originally written for startups trying to break into the mainstream, and this talk adopts that book to programming laguage (or tools more generally), particularly regarding Haskell. Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA Gabriel also suggests that in order to "cross the chasm" you have to offer a best-in-class experience in some area, and suggests that Haskellers adapt the language to facilitating building interpreters, which is it particularly well suited for. So, base on the above, I don't think the OP's emphasis on the emotional analysis of Haskell programmers is anything more than the OP's just-so story, although the notion of parochialism may have some crossover with the concept of marketing.

xfer 6y ago

I would say tooling is the main reason haskell is not adopted even in personal projects much. The package manager used to be pretty bad, poor editor support is still the biggest obstacle for new-comers. Combine that with the fact that students are taught a procedural-style language in their school and you have small percentage of new-comers looking at it. Rust have an advantage here since it is procedural-ish language. But these problems require money and expertise and marketing from people who already are in the field, so a bit of chicken-egg problem. Arrogance is the last thing i would say about haskell community and i have interacted with them on reddit and irc. So not sure about that. The thing about ignoring enterprise needs is that the enterprises need to invest in the things they want. Those that do contribute are using haskell in enterprises that fit their needs. Otherwise it is primarily a research driven language. It's not very surprising that Go/Java is doing very well, looking at the investment done by the companies behind it.

mark_l_watson 6y ago
I think Haskell tooling is pretty good now. VSCode with the Haskell plugins is simple to setup. I used to use Emacs for Haskell, but the VSCode support is now so good that I just take the easy route. Stack and stackage made package management much easier for me. I am an enthusiastic, but not great Haskell programmer so I like running the ‘hlint’ linter program for hints on improving my code. My heart is really with Common Lisp, but Haskell is also a pleasure to use and the tooling seems much better to me than five years ago.
- metreo 6y ago
  I think Haskell versioning is highly bifurcated.
  - codygman 6y ago
    You mean like SemVer vs the default whose name I can't remember?
    - metreo 6y ago

throw149102 6y ago

It seems strange to consider Haskell as dead when its motto was "Avoid success at all costs". Haskell wasn't popular in enterprise settings because it didn't want to sacrifice being a good language for being a popular one. Haskell was/is very successful if you base it on it's own terms. Now, that goal can be debated, it could be argued that an unpopular language is never that good because it is unpopular, but that's a different argument.

erik_seaberg 6y ago
It’s bittersweet to vaguely know a good language I’ve never been able to use professionally.
Aeronwen 6y ago
This. It's the next ALGOL. Let the next dozen popular languages cherry pick the good parts from it and don't worry about people using it directly.
PCChris 6y ago
> it didn't want to sacrifice being a good language for being a popular one I think this is the key. The motto that you mentioned is often clarified/refined as something like "avoid 'success at all costs'".
addicted 6y ago
Exactly. Haskell has explicitly been run and planned around not being successful because real production usage and success will require the maintainers to limit breaking changes, for example, which defeats its purpose as a language for experimentation and research.

Aerroon 6y ago

We actually had a functional programming class in university, where the focus was on Haskell. The main impression that seemed to permeate the class was "Haskell is hard". There was a lot of grumbling. Nowhere near as much as about Prolog in Logical Programming though. They were both thrown into the same pile of "must get through this class" though. I'm not really sure whether it was because of the way it was taught or whether Haskell is inherently more difficult. I do think that a class like that might've hurt the language's adoption among the students though. (Or maybe my impression is simply biased by my own experience.)

kovac 6y ago

I think for a language to gain traction today in the mainstream, it needs to be backed by a large company. If the language is web technologies oriented, it's all the more likely. The reason is because lots of developers nowadays are working in web related stuff. And when it's backed by a big company like Google or Microsoft, kids will at least learn it to try and land a job at one of those companies. Also, these big companies will support many useful apis in that language which will attract mainstream developers as they can start building useful stuff quickly. I wanted to learn a functional programming language and did a lot of research about which language to start with. Initially I looked at Haskell but ended up going with F# because the tooling was a lot better and the documentation from Microsoft was really good. Also, I read quite a few posts by those who worked fulltime, paid F# jobs. I loved the functional style. I think it's a shame that it's not mainstream. But then when I tried to do something non trivial, like network programming, I had to use OOP C# style types in F#. That was just fugly and made the paradigm look weak because OOP constructs could do it more easily than functional constructs. Other than the elegance of the functional programming paradigm, it didn't seem to offer much in terms of jobs because I can't really see large numbers of people suddenly picking up functional programming (which isn't easy) and building massive applications specially with the whole cloud based SaaS stuff that's happening right now.

xupybd 6y ago
I'm learning F# now for similar reasons. I'm guessing that the industry is moving in a more functional direction. I want to learn a functional language to keep up. I also like the claims that you can lower runtime bugs with good functional style.

benreesman 6y ago

I’m far from an expert Haskell programmer, but I have written it for money and had the code run on big fleets. Haskell is really cool, but IMHO is held back from practical adoption by two things, one technical, one cultural: - Lazy by default maps weirdly onto von Neumann machines. Laziness is cool but doesn’t pull it’s weight as the default. Performance in time and space is even harder to reason about than it already is on modern architectures, and debugging is...different. - GHC extensions are like crack for the kind of people who overdo it with C++ templates. Pragmatic, legible Haskell in the RWH tradition isn’t safe from the type-theory zealots even in a production system. Cool research goes on in GHC, but it’s hard to keep everyone’s hand out of that cookie jar in prod.

Joker_vD 6y ago
I've briefly looked into the implementation details of lazy languages and yeah, while that Spineless, Tagless G-Machine is a pretty neat thing, it results in rather unorthodox code representation. And yes, reasoning about memory consumption and having each library give you 2 versions (strict and lazy) of their data structures is tiresome. Why can't strictness/lazyness be parameterized away?

tome 6y ago

What is killing Haskell, according to this discussion * marketing failure * lazy by default * GHC extensions * its weird syntax * its obsession with monad-as-burrito tutorials * pretty hostile haskell-centric spaces * not backed by a large company * bad university classes * tooling * average developers are not “smart” enough to learn it * no payback for learning Haskell skills

heavenlyblue 6y ago

I think comparing Rust to Haskell for their "similar" success is kind of dumb. Everybody wanted to program in Haskell, yet nobody build a proper package management and/or compiler version management solution for Haskell up until very late. If Haskell was indeed one of those "everybody wants to do it" languages, then making it easy to approach from the infrastructure perspective would be the first thing to do.

sklarsa 6y ago

Rust will be fine, as long as people continue using it to produce high-quality tools like ripgrep (rg) and xsv

StillBored 6y ago

I've assumed that rust is going to be killed by a "-enforce-no-mutate-single-owner" or similar flag to gcc (or some linter) that restricts C++ code to some subset/style that nails the majority of what rust brings to the table. IMHO, like many other language paradigms, once you understand the core tenents of rust you could write "rust code" in many other languages. The difference being that those other languages don't _yet_ have flags/etc to enforce a rust like style.

pjmlp 6y ago
Actually they do, it just happens to be WIP on clang and MSVC++. CppCon 2019: “Lifetime analysis for everyone” https://www.youtube.com/watch?v=d67kfSnhbpA https://www.youtube.com/watch?v=d67kfSnhbpA
rcxdude 6y ago
I wouldn't bet on it. Firstly, rust has value as a "C++ without the cruft" language even without safety as a USP, and secondly rust had to do a huge amount of design work to get the language to work in a way such that the kind of static analysis it does is reasonbaly feasible. C++ would need to adopt more paradigms and then create a subset of itself in order for this to work (there are such designs in the works like 'C++ Core', but they have already had to give up achieving the same level of safety as Rust gives).

smabie 6y ago

Though Haskell is nice in many ways, I would choose OCaml for a commercial project over Haskell any day. OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism. Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that. If something was going to kill Haskell, it would OCaml, not Javascript or some other language. I would feel very comfortable running a business on OCaml, Haskell, not so much.

codygman 6y ago
> Though Haskell is nice in many ways, I would choose OCaml for a commercial project over Haskell any day. As a counter-point I'd say the opposite: I choose Haskell :) > OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism. Is this a plus? Practical and pragmatism seem to be unlaterally considered a positive, but when does "pragmatism" just start to mean "unprincipled"? There's much talk about when being too principled gets in the way of getting things done, but I'm wondering what your position on the opposite is here. What are your thoughts on 1) Real-world thinking 2) first-principles thining and 3) the balance of each that is ideal in software-engineering? > Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that. Haskell was designed to get stuff done too, just maybe not quite the same way. If you ever had an inkling of "maybe people in industry are outright dismissing research too fast" you might like it. >> If something was going to kill Haskell, it would OCaml, not Javascript or some other language. > I would feel very comfortable running a business on OCaml, Haskell, not so much. I'd feel comfortable with either. I agree it'd have to be something at least as strongly typed as Ocaml to kill Haskell as well.
- smabie 6y ago
  I think I came off as too pro-Ocaml. I personally think OCaml has a ton of problems, and like you suggest, is unprincipled. Features are added with very little thought, and OCaml code can get very ugly trying to replicate the kind of power Haskell has built in. But, all in all, I like OCaml more than Haskell. Laziness by default is a mistake and GHC's ever growing list of language variants is kind of stupid. Moreover, Haskell's monad based effect system is a lot less useful than people think it is. In my mind, the main benefit of tracking effects is to enable aggressive compiler optimization, not increased safety. Haskell's effect system imposes a heavy burden on the developer, with little benefit. Ocaml imposes almost no burden in doing whatever the hell you want, but the language is messy and full of decades of hacks and eye sores. I'm one of the rare souls that actually likes OCaml's OO system and I actually think that the language would be a lot better if the standard library and other code leveraged it. As it stands, functors aren't expressive enough for many use cases and function as shitty classes. Here's what I want from a functional language: Something that looks like OCaml, but get rid of the functors, cleans up the syntax, supports HKT, supports function polymorphism, supports easy to write macros (ppx is so fucking shitty), and make it have Nim like OO call syntax. Every function that takes a type as it's first argument can be called as a method using the dot syntax. Also, have the language compile to a native executable, and make the executable and runtime really really small. OCaml gets a lot about performance right, but the 20mb executables (no tree shaking) is unacceptable.

dpc_pw 6y ago

What does it have to do with Rust? I mean Rust shows absolutely no sign of problems that Haskell had. It's very practical, learns from everywhere it can find a good idea, tooling is great, marketing is great, community is nice and inclusive.

TheGoddessInari 6y ago

I don't feel like I can take it seriously when it talks about Haskell devs on Reddit snickering about Go "in the mid 2000s".

deleted 6y ago

[deleted]

brundolf 6y ago

> 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. No wonder it felt like the author was living in a different universe.

axilmar 6y ago

My personal experience with Haskell hackers went like this: -I used to hang out at lambda-the-ultimate, in which haskell was considered god sent and c++ a toy language. At the time, I was heavy into writing simulation software, which meant c++ all the way, so I tried to understand haskell and its advantages over c++, but my attempts ended up being mocked. I stopped visiting that site. -I tried to open some debates about Haskell on reddit, where someone told me they will answer my haskell questions only if I told them a specific mathematical definition on some properties of functions. I didn't know the reply, I was a programmer after all, not a mathematician. Said person left me in the cold. -again on reddit, I was trying the debate the usefulness of haskell regarding simulation software, which relies heavily on updating variables, but I never got straight answers. To this day, I still do not know if haskell code actually can update variables in place or it only simulates updating of variables. Someone suggested using lens, and although I understand the abstraction, it still has not solved my question if haskell can update variables in place. Why I was so interested in this aspect, i.e. in place updating? I wrote simulation software and after that game software for a living, and it matters to me because I want to be able to reason about the performance of my program. I don't want to have data be duplicated behind my back. To cut the long story short, my haskell questions go unanswered to this day, I was very disappointed, and since I have great experience in imperative programming languages, I usually write programs that are correct as soon as they are compiled, which is what the haskell advantage is supposed to be. So I don't see any benefit from haskell, and I won't recommend it to my company or my colleagues. Am I wrong regarding haskell? perhaps, but I am not interested any more in 'trying out' languages of dubious gains, nor am I interested in dealing with juvenile behaviors. I tried Rust because it had a serious advantage over C++ (namely, object lifetimes), and I will recommend Rust, but my patience for and interest in haskell is virtually non-existent at this point.

shirogane86x 6y ago
I personally haven't had the same experience as you (I personally find the Haskell community quite pleasant, especially in the functional-programming slack server), but I'll try and answer (probably in an incomplete way) your question about updates. Haskell can, in fact, update variables. Mostly through 2 mechanisms: - ST (a computation containing local, mutable state, that cannot escape its scope) [1] - IORef (mutable, thread-safe variables that only work in IO). [2] The other (and usually more common way) of doing "mutable" state in Haskell is through State, which technically doesn't update the variable in-place, but simply modifies the variable and passes a copy to the rest of the computation (although, as far as I'm aware, a lot of the time this step gets optimized away). That said, if your main field of expertise is simulation programs where performance and space efficiency are very important, then Haskell is probably not a great fit (cause not only is it based on a GC, it's also lazy, which can sometimes mess with the performance of your code, not speed-wise but memory usage-wise). Hopefully this could be mitigated in some way in the coming years when Linear types become viable for efficient resource usage (Linear types ideally could grant us some sort of Rust-like resource management) [1] https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad-ST.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr... [2] https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-IORef.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-...