1. 24
  1.  

  2. 16

    This is a particular reputational problem for unusual language choices because failures of a team or product tend to be blamed on the weirdest things that a team does. When a Go project fails due to design issues, people rarely say “this failed because of Go” because there are so many examples of projects written in Go that did not fail. (On the flip side, design failure is also more likely because there are so many more examples of successful Go projects to follow than there are examples of successful Haskell projects.)

    1. 5

      On the flip side, design failure is also more likely because there are so many more examples of successful Go projects to follow than there are examples of successful Haskell projects.

      I feel like this is a big part of it. Another issue is that often the developers choosing languages like Haskell are less likely to have used it at a large scale than people working with conventional languages. For many people this is because you don’t get the opportunity to work with a language at scale without using it at work.

      1. 8

        Indeed. And things work much differently at scale than they do in the small, the tradeoffs get different, and one has to develop a plan to compartmentalize ugliness and complexity.

        1. 2

          For an average project… I seriously doubt the “less likely to have used it at a large scale” part is true. Many teams don’t have a person on board who’d have practical experience using something at an actually large scale, much less designing for a large scale.

          Just because there are more people with that experience in the general population, doesn’t mean a particular team has one of those. Also, many projects never reach a truly large scale, and with modern hardware, large is really quite large.

          Of course, “using $language isn’t a stand-in for good software design”. But first, it’s true for any language, and second, there are already enough people trying to discourage everyone from moving beyond the current mainstream.

          1. 3

            I can’t tell you the number of Python shops that said the same thing, only to have their engineers perform expensive rewrites in more performant language runtimes. Twitter here is the poster child of doing a large-scale rewrite from Rails into Scala for performance reasons. It’s true that large scale does not happen to every company, but I also think optimizing solely for developer ergonomics will put you in a bind any time you do need to scale.

            Of course, “using $language isn’t a stand-in for good software design”. But first, it’s true for any language, and second, there are already enough people trying to discourage everyone from moving beyond the current mainstream.

            Who? So many Silicon Valley companies have seen success embracing new technological stacks (like Rails and Django when they were hot, to Scala when it became cool, Go when it came onto the scene, and now Rust), so I can’t see why a new company would not want to use a new language if their devs were comfortable in it and confident in its ability to scale to the market they wished to address.

            the current mainstream

            There’s wisdom in accepting tried-and-true solutions. I’ve dug into new language libraries only to find undocumented settings or badly chosen constants more times than I can count. Edge cases in LRU caches, bugs in returning connections back into connection pools, circuit breakers that will oscillate between on-and-off when degenerate conditions are hit, these are all examples of algorithms that were incorrectly implemented, and it’s not always clear if the value proposition of a new language overcomes the complexity of implementing tried-and-true algorithms. Choosing an “unproven” language is not a light decision, especially when several engineers will spend their time and money on making it work.

            1. 3

              Most places aren’t Silicon Valley. Most companies aren’t startups. Most projects aren’t web services with open registration.

              And it’s not about optimizing for developer ergonomics. Advanced type systems are about correctness first of all. It’s just sort of taking off with Scala, Swift, and Rust. Sort of. Those clearly still face more opposition than 70’s designs like Python, Ruby, or Go.

              1. 5

                Most places aren’t Silicon Valley. Most companies aren’t startups. Most projects aren’t web services with open registration.

                According to StackOverflow [1], Typescript is a top 10 language, and Rust, Swift, and Typescript are top 20 languages. So while there is a bias for tried-and-true languages like Python and Java, languages with “advanced” type systems are in the top 20.

                Advanced type systems are about correctness first of all

                Is it? I’m not sure if there’s any proof that advanced type systems actually lead to more correct programs. I certainly don’t remember that when I was in grad school for PLT either. I understand that practitioners feel that type systems allow them to make more correct programs with less cognitive load, but I would bin that into developer ergonomics and not correctness until there’s proof positive that ML-based type systems do actually result in more correct programs.

                It’s just sort of taking off with Scala, Swift, and Rust. Sort of. Those clearly still face more opposition than 70’s designs like Python, Ruby, or Go

                Or, perhaps, most programmers genuinely do not enjoy working with heavily restrictive type systems or with monad transformer stacks and free monads. Haskell is a year older than Python and is an order of magnitude less widely used than Python. It’s clear that recent languages like Rust, Swift, Typescript, and Scala do use a lot of ideas from ML-descended type systems but it’s not clear whether they are popular as a whole or not. Many languages have taken pieces of these type systems (such as the Optional/Maybe sum type) and bolted them onto their language (Kotlin), but I think that ML-style languages will always be enjoyed by a minority, though how large that minority is time will tell.

                1: https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-all-respondents

                1. 2

                  I understand that practitioners feel that type systems allow them to make more correct programs with less cognitive load, but I would bin that into developer ergonomics and not correctness until there’s proof positive that ML-based type systems do actually result in more correct programs.

                  This is an accurate statement I think. No type system can guarantee you are more correct unless the “spec” you are implementing is more correct. What it does help with is giving the developer more information on where they are starting to deviate from the spec. But even then it doesn’t guarantee that they are implementing the spec correctly in the type system. ML Type systems give you early information that your code won’t work as implemented when it hits certain edge cases. Those edge cases will sometime but not always manifest as bugs in production. So depending on the ergonomics you favor in your programming language you will either love that early information, be ambivalent, or you will dislike it.

      2. 9

        I mean…yeah. I’m not suddenly going to write perfect microservices by choosing Golang. I’m not going to build a perfect frontend by choosing Vue. Language/framework choice only informs and constrains how you design the software, it doesn’t do the design for you. Put another way: your software is a destination, the language/framework your mode of transport, design/architecture the path. You can mix mode of transport and path pretty much freely, but some combinations are going to be far more painful than others.