1. 33

  2. 22

    When I saw the text “At the beginning of 2030”, I thought this essay was going to use the narrative conceit of claiming to be a historical retrospective on the present day, published in the future. But the essay doesn’t do anything with that premise, so now I suspect it’s just a typo for 2020. I see that at the end it claims to be an existing talk about Smalltalk with Haskell and Rust substituted in appropriately. I’m not familiar with that original Smalltalk talk though.

    In any case, I don’t think the object-level point this essay is making holds. In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”. It’s easy for an essay-writer or internet commenter to remember a small number of particular interactions with a particular group of people who happened to be advocating for the merits of some programming language over another, and incorrectly attribute this to a property of that programming language. Note the argument in the comments about whether it’s actually Go users who are prototypical examples of arrogance. I don’t generally expect to agree with programming language essayists over whether some example of discourse actually constitutes arrogance - it’s a common trait for people who are arrogant themselves, to accuse others of being arrogant.

    Haskell also has some important differences from Rust in design and and purpose, that do a lot to explain why Rust is more popular among industry developers than Haskell is. Haskell is fundamentally a research project in lazy functional programming design, whereas Rust is fundamentally a project to make well-established ideas from programming language research readily available to industry programmers, particularly ideas for statically-checking memory safety (which isn’t a research concern of Haskell’s). Rust notably borrowed some ideas from Haskell, such as traits (Haskell typeclasses), and I don’t think anyone working on Haskell would consider it a failure of theirs that an industry-focused language that borrowed ideas from their work happens to be more widely used in industry.

    Still, I don’t think it’s accurate to say that Haskell is “killed” (certainly it’s a lot easier to get a job in 2020 writing Haskell than writing Smalltalk!). It’s not among the most popular programming languages, but software-writing organizations do in fact use it. The language is being actively developed, (better) tooling around the language is being actively developed. People who care about functional programming reference it quite a bit, even if it’s in the context of applying Haskell ideas to non-Haskell programming languages.

    1. 7

      In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”. It’s easy for an essay-writer or internet commenter to remember a small number of particular interactions with a particular group of people who happened to be advocating for the merits of some programming language over another, and incorrectly attribute this to a property of that programming language.

      Plus, of course, the trolls: There’s plenty of people on Reddit, for example, who are “advocating for Rust” in a way that makes Rust advocates seem unhinged, which is the point. Maybe some of them hate the language, but most of them are downvote trolls (“Look at me! Downvote me! LOOK! AT! ME!”) riding a fad.

      1. 13

        I’m not so blind as to confuse the arrogance of Rust users with a flaw in the language itself, but I have noticed a fair amount of arrogance from the Rust community. This isn’t just “a few bad experiences in a sea of good ones”: every time I’ve interacted with the Rust community, I’ve had at least one or two responses that would be considered unwelcoming and arrogant. It’s not just trolling, I don’t think.

        I’ve had this happen on Twitter, here on lobste.rs, Stack Overflow, and various other places.

        (I avoid Reddit for the most part; if I wanted to know that COVID-19 was a hoax designed to destroy Trump or find out that same-sex marriage is Satanism, I’d just talk to my mother’s side of the family.)

        I think the perceived arrogance of the Rust community has some basis in reality, and I also think that it comes from Rust being a relatively new community, a relatively small community, a relatively technically-superior community, and a relatively unsupported community.

        Rust is technically superior compared to many other languages. Rust is the new kid on the systems-programming block. Rust has a relatively small community. Rust is not supported by Google or Oracle or Microsoft or Apple (yeah, Mozilla, but Mozilla is peanuts compared to those guys). All of this adds up to a “siege” mentality. The Amiga community was and is like that, and for often very similar reasons. I think a lot of the Rust community’s arrogance is perhaps a degenerate case of Amiga Persecution Complex.

        That being said, while I like Rust and I’m learning it and I plan to make it my next big language for major projects…the community needs to get better. I think that will happen with time, as it grows and the ratio of True Believers to Just Want To Get Work Done people shifts.

        1. 6

          I think the perceived arrogance of the Rust community has some basis in reality, and I also think that it comes from Rust being a relatively new community, a relatively small community, a relatively technically-superior community, and a relatively unsupported community.

          I agree with all of this, but I think there’s another thing at play: Rust is a technically different community in a way that matters. It isn’t GC’d, it’s ownership-managed, and that isn’t unimpeachable yet. If Rust fails, ownership-management fails, too, at least in terms of mainstream adoption, so your intellectual investment in that paradigm begins to look like getting taken for a ride by a silver-tongued scammer. OTOH, if Go fails, nobody’s going to Seriously Reevaluate the value of GC’d programming languages.

          1. 5

            Don’t worry, linear types failed many times before they had their first glimpse of mainstream success in Rust. ;)

            And so did GC, it failed even more times before it finally succeeded.

            1. 2

              I’m not waiting another 10-20 years.

          2. 4

            It’s interesting that you say this, as I’ve actually found the community very approachable. Almost every major project has a Discord (pour one out for IRC…) and I’ve yet to have a really negative experience in one of them. I contrast this with older communities like the extremely toxic C and Linux IRC channels, where it was more of a surprise not to have a bad experience (at least as a beginner). General discussion forums vary, of course, particularly on sites like Reddit, but I’ve also never seen anything in Rust to rival the little nucleus of horrible people who floated around the Haskell and Scala communities for a long time. Even on Github issues, I’ve had pretty good reception and discussion, whereas in more mainstream communities like Python or Javascript I’ve seen (or been on the receiving end of) very negative behavior.

            The only really bad community behavior I’ve seen was surrounding actix, where I actually think the community was too nice. The maintainer’s behavior was extremely abrasive and negative, but people in the community acted like the reactions to this toxicity were themselves problematic. It reminded me of someone getting suspended from school for punching their bully.

            1. 5

              Rust is very interesting in that it is a language in which – in terms of community – there is a massive delta between those who use it and those who are hobbiests and even more strangely, non-user evalgenlists.

              Those I have spoken to / worked with who either touch Rust core or ship real-world code have been extremely kind, aware of language pros and cons and more than willing to discuss both.

              But, as you go outside of the that group you reach a group of people who are – borderline non-users. These people have never shipped Rust code anywhere, open-source or elsewhere. Yet they will promote it as being world-saving or viciously attack those who dare slander it.

              What makes me suspect Rust will overcome is that delta, as the community of active users grows, hopefully, the voices of those who are more on the fringes will be less noticeable, or in the best case, they will start to emulate those they respect in the community.

              1. 1

                That’s interesting, and would explain my experience. I very rarely interact with “fringe” communities, instead primarily interfacing with the community as a question of practice while writing code (e.g. if I find a bug or non-obvious behavior in a library, I go and ask about it). In your assessment I would therefore be interacting only with the “core” of the community, and avoiding the “fringe.” Hopefully this core – which, again, I’ve had nothing but positive experiences with – can overcome whatever horribleness newcomers are encountering at the edges.

                1. 1

                  Well – the risks are two-fold. The first is the “fringe” in this case might well be the majority (in raw numbers). The second is the “fringe” is often the first point of contact someone has with the community as they explore the idea of using Rust. Unfortunately, many people first explore a language, not via important projects, but via subreddits and various medium articles about the language.

                  1. 1

                    This honestly makes me think that we (e.g. people actually using Rust for things) need to write more articles focused on presenting Rust in a friendly/conceptual way besides just the usual beginner texts. It’s hard, though, because I think there’s a kind of analogue of the “explaining monads” problem: Rust changes the way you think about programming somewhat, but there isn’t a real language of practice around it yet. Developing those metaphors will be a challenge.

                    1. 2

                      I think you nailed it. The practice of being a Rust developer is still rather new. Additionally, Rust due to its differences with other languages makes it hard to tell someone just to “dive in and get involved” with a project they like. It can feel absolutely intractable at first. That is a benefit that Go tends to have – you find an interesting project, jumping in is easy and the distance from completely lost to enlightened tends to be a fairly straight line.

            2. 2

              I’m not so blind as to confuse the arrogance of Rust users with a flaw in the language itself

              that’s kinda like a foundational line of thinking in media studies in general; the notion that the specific affordances of a medium affect the users of that medium, and that the affordances of the medium are expressed through the content made in that medium. Hence the saying “the medium is the message”. McLuhan takes it pretty far (much farther and more literally than I would be thrilled to support), but the idea that a specific medium (a programming language, in this case) has a character and has its own message is … a widely studied concept worthy of consideration, and shouldn’t be disposed of so casually. For programming languages, the question then becomes: what is the language’s character and what is expressed by the language itself?

              1. 1

                This line of thinking permeates HCI, even back when it was just “human factors” research. But the oldest and perhaps deepest form I know is the venerable and well-worn Sapir-Worf hypothesis. It’s a difficult subject to study rigorously. Experiments are almost impossible to conduct, factors hard to control for… but there is nonetheless a rich body of perhaps-not-entirely-useless scholarship.

                One need not be a scholar to observe that language and culture are everywhere intertwined. Although the diversity of “natural” human languages has suffered an epoch of mass extinction, we computer people are living in a tiny but ongoing explosion of artificial (and thus perhaps even more human) linguistic diversity, and inevitably dragging in all our predilections for cliques and status games, to enact amidst all the mathematical and mechanical concerns. Perhaps someday there will be a true sociolinguistics of programming languages. As it stands now, we barely have even scraps of historical consciousness… like this joking-not-joking article.

            3. 6

              There’s plenty of people … who are “advocating for Rust” in a way that makes Rust advocates seem unhinged

              that’s increasingly my experience of lobste.rs

            4. 2

              In any case, I don’t think the object-level point this essay is making holds. In general, I’m skeptical of arguments saying that “such and such language community is arrogant, therefore Y”.

              I think the original talk was using the demise of Ruby as a pretense to talk about professionalism in programming rather than earnestly attempting to analyze the demise of a language. Professionalism - Martin’s version of it - is something that he likes to pontificate about.

            5. 14

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

              This is both inaccurate and condescending - as if not having heard of HKTs before is an indicator of intellect or ability. Stop this.

              The first one is discipline. Discipline specifically in documentation.

              I don’t see this as an issue in the Rust community, to be honest. There’s a suite of tools for generating wonderrful documentation, a significant culture of “document everything”, and beyond that, the larger libraries are often documented both with API docs and with book-style tutorial documentation.

              The professionalism of humility is something that may prevent the demise

              Rust, by and large, doesn’t have a problem with humility. “RIIR”/“RESF” jokes aside, robust FFI has been a focus of the language for a long time and interoperability with even the largest, most gnarly C codebases is possible - the kernel comes to mind. Spend a while on the Rust subreddit and you’ll see plenty of people telling new querants, “no, Rust probably isn’t a good fit for your problem.”

              the last thing would be acceptance of solving the “dirty” problems. Solving the problems of the horrible schema. And we’re gonna have to sit down and say “No, we’ll deal with that”.

              This really gets me. The entire point of Rust’s type system, its concept of segregated unsafe, and its zero-cost abstraction philosophy is to solve these nasty problems in a re-usable way. As an example, one of the most common criticisms of Rust from experience programmers coming from other languages is that its string handling is too complex - but, in fact, it’s representing the actual complexity of handling strings, if not perhaps in the most optimal way.

              I have to say, I’m not impressed.

              1. 12

                This is a transcript of a Robert C. Martin talk with some mechanical changes.
                The original talk was low quality and substituting Rust for Ruby and Haskell for Smalltalk hasn’t improved it.

                1. 2

                  I don’t know much about Rust, really. Or Ruby. But I have been paid to write both Smalltalk and Haskell, and I don’t think it much of a stretch to say they both suffer from some cultural issues… although not really quite the same ones. The original critique was sloppy and half-baked, yes. The practical-joke analogy treatment stretches it into something almost but not quite absurd. As ever, humor is our only reliable response to anxieties and discomforts we don’t understand and can’t face squarely.

                  But look at how much verbiage it’s elicited here in the peanut gallery! How very post-modern.

                2. 10

                  I don’t even buy that Haskell is dead. There are enough notable developers (shoutouts to Joey Hess!) doing notable things that will continue to generate interest and participation.

                  1. 9

                    Haskell is not dead

                    1. 6

                      Did Haskell die? When was the peak?

                      1. 4

                        Fear-mongering, ugh.

                        Why can’t things just lapse or fall out of style? “Kill”, “dead”, “destroy”; these words are out of place and overused in the tech and gaming spaces. /rant

                        1. 4

                          I’m not sure these arguments make sense. One thing which I keep bringing up is a language lives and dies way less on the particular features or community as it does on the ecosystem around the language, and the ecosystem around the problems the language is used to solve. Whatever the language and the community do to create and nurture that ecosystem is what counts.

                          People talk about the demise of Ruby as if the cause was the community when really it was more the shift in emphasis toward frontend development in creating web applications. This made Javascript and Node more attractive. As Ruby was mainly used for web development the loss of those users was felt relatively strongly. I think it has relatively little to do with the merits of the language or the community.

                          1. 4

                            I think it’s worth noting here that this essay was not well received in the Haskell subreddit, and there are some good critical comments there–this one in particular resonated with me. And Hail_Spacecake, it does seem like the author intended this to be set in 2030…

                            1. 4

                              At the end of the day it comes down to the ratio of the effort and the reward associated with it. Haskell is a large and complex language that requires a significant investment in terms of both time and brain power to use effectively. This is compounded by the fact that Haskell is very different from mainstream languages, and many of the patterns for solving problems people have already internalized need to be discarded. Somebody who’s already an experienced developer might actually find Haskell even harder to learn than a beginner because of this.

                              There are only so many hours in a day, and most people will be hesitant to invest a lot of their time learning something without seeing a concrete benefit. Of course, many people learn Haskell purely as an intellectual exercise, and that’s a reward of itself. However, majority of developers are ultimately looking for something that’s practical and provides a clear benefit over the tools they’re currently using.

                              I think that one of the primary reasons Haskell failed to gain popularity is due to the fact that the Haskell community ultimately failed to produce any convincing results. While there are some large projects written in Haskell in the wild, none of them are doing anything that couldn’t be done in pretty much any other language. There is also little indication that these projects are of significantly higher quality, that they were developed significantly faster, or that they’re easier to maintain.

                              Given that Haskell has been around as long as Java, the lack of interesting software written in it is not supportive of the argument that Haskell affords significant benefits in practice. Haskell may be a well designed language, and it does help avoid many errors that are common in mainstream languages. However, the benefits simply don’t appear to be sufficient for it to build the necessary critical mass of developers to achieve significant growth.

                              I don’t think Haskell will go away anytime soon since it has a vibrant and dedicated community around it. However, I also can’t really see it growing significantly at this point. If Haskell was going to get big, it would’ve happened by now.

                              Meanwhile, Rust has the advantage of being both simpler and more familiar to mainstream developers. There are also significant projects written in it, and its growth appears to be quite steady.

                              1. 2

                                The problem I always had with Haskell (for context, I have spent a significant amount of time with Haskell and compiling Haskell) was that the proponents would aggressively push performance, and laziness as a path to performance, at the same time, but any time anyone was doing actual performance sensitive stuff they would switch more or immediately to strict evaluation.

                                to my mind this hurt Haskell in that it meant non-haskell programmers were being told lazy evaluation made everything better, but were subsequently told to rework everything to remove the laziness whenever there was the smallest perf problem. It turns it from a standard “how do I get the best perf out of this language?” problem, and into an “I have been mislead” problem. That hurts the reputation of the language.

                                Now personally, my problems with Haskell have always been that it mandates functional programming in the strict sense. That means that something that would be trivial in imperative languages - adding basic logging, etc - suddenly requires substantial changes everywhere that has explicit types. While explicit types are theoretically not necessary (beyond higher minded types), a lot of standard practice Haskell has explicit types specified, and that is an instant compilation failure.

                                For impure functional languages, and for more or less all imperative languages there is no need to consider the behavior of inner functions in your external API, but the purity needs of Haskell require it. My personal feeling is that this is not a good design feature, even if logically it is a “sensible” language feature, and I’m not sure if it would be as much of a problem if I had been raised in a world of pure languages, so I can see valid arguments on each side here.

                                The other problem I’ve encountered is the emphasis on line or character count of solutions to fairly specific problems. A lot of the reduced character/line count comes as a byproduct of a substantial standard library (though honestly more languages should just have this), and the gratuitous use of new operators. People complain bitterly about the overloading of operators in c++, but a lot of brevity in Haskell is a byproduct of just that, and a lot of the remainder is a byproduct of allowing a dev to define arbitrary infix operators.

                                1. 1

                                  It feels like the “impurities” that are required in Haskell need to be divided somehow into “incoming” and “outgoing” effects… so, for example, logging and metrics shouldn’t really be reflected in producers’ types, or should be captured at a second level of types, whereas consuming external values obviously has more important implications. That would go a long way toward simplifying the ergonomics of pure languages, in my opinion, and still allow the elimination of many sources of non-determinism. Of course, one of Rust’s strengths (to me) is how it encourages a sort of purity by making you think about where values are produced and consumed more carefully.

                                  1. 1

                                    sorry, I missed this - in the Haskell type system it is never sound to put a function with side effects in a context that does not force you to pass state through it (there’s a literal internal type in GHC called RealWorld, and instance of which is passed into main). The reason you can’t do that is that if a function has no side effects (e.g. doesn’t produce a value the feeds forward) then you can execute that function multiple times with the same arguments (screwing up logging), you can coalesce multiple calls with the same argument (if nothing else that could mean hoisting out of a loop), and of course if the function doesn’t indicate that it changes some state (by returning a new state), then you don’t need to call the logging function at all.

                                    All of these conspire to break “side-effect free” logging.

                                    1. 1

                                      Yeah, I understand. I was thinking more about “some future type system.” Something with a concept of “sink effects” versus “source effects.”