1. 37
  1.  

  2. 14

    I dislike Go but I think this is a fair assessment. It’s a lot more readable than C++, a lot less hideous and less verbose than Java, and it has a very fast compiler. It’s not a great language, but it’s not designed to be that. It’s designed to be good enough for Google, a “worse is better” language.

    It wins points on readability. That said, there are many other languages that do a better job and don’t have to make severe compromises (e.g. no parameterized collections) in order to be readable. OCaml comes to mind as a strong language, even if the implementation is lacking and unsuited for high levels of concurrency, and Haskell becomes very readable after you make the initial investment (about 3-6 months of learning a new way of thinking and a slightly idiosyncratic syntax).

    I don’t want Go to be “doomed to succeed”. I’d like to see something better do so. I do like it a hell of a lot better than Java, though.

    1. 4

      I think Haskell/OCaml are good languages for both personal projects and new companies, but consider companies already well established like the one I work for: my coworkers know C and PHP (as we use those) and at most another language like C++ or Java. Since we are small (<10 employees) each one of us works on a big part of the software (me working on the web interface and some other bits).

      As I got assigned to a new project that would be integrated into the software, I had free choice over the language to use, as long as my coworkers agreed (since they would need to take over if I left or went to work on something else).
      It was very very easy to sell them on Go, while if I went to try and propose something more exotic like Haskell or Node.js I’m pretty sure we would still be arguing “why not just use PHP”.

      1. 10

        I’ve come to the conclusion that anyone who hasn’t used at least one functional language for a year should not get a voice in programming language debates. If someone has used Haskell and knows it well, but would rather use Go or Java, that’s one thing. Someone who has only used Java should not get a vote. Not everything should be a democracy, and any personal opinion that I might have regarding brain surgery is worth a hell of a lot less than that of an actual neurosurgeon.

        On the other side, I’m annoyed when my colleagues argue that “Java developers” are somehow too stupid to learn Haskell or Clojure. It’s flatly not true. The mediocrity of software engineering is an artifact of talent inversion (i.e. dumb people in decision-making roles, smart but disengaged subordinate engineers) and not a lack of IQ. Most of those mediocre Java programmers are mediocre because of disengagement and have more than enough intellectual horsepower to learn functional programming and proper software engineering.

        1. 3

          learn functional programming and proper software engineering

          Don’t you think that making a so strong association between functional programming and “proper software engineering” is pushing the argument for FP a little bit too far?

          1. 1

            When it comes to learning your first functional language, I’d argue that being stupid is actually the best thing there is. All my experience and knowledge about structural languages and OO did nothing but put huge obstacles in my understanding of how functional languages work. I really notice this when teaching people about map/reduce, the ones that never programmed are the ones to understand and be able to apply them sooner.

        2. 4

          I don’t think OCaml and Haskell could compete with Java though. Nor could C++ I think. C++ is harder than Java, in that you have to do memory management yourself, and is also a lot more unsafe; it’s easier to write code with exploits. OCaml and Haskell might be great languages, but a lot of the cases where Java is used is within corporations, where choosing such weird languages is a lot more risky than choosing something which everyone who has gone through a CS education already knows; Java.

          I agree that Go isn’t perfect, as nothing is, but I also agree that it’s a heck of a lot better than Java. I also think that many of the things which would’ve made it better in your eyes, like making it functional and such, would’ve made it a worse alternative to Java internally in corporations, and the fact that it’s backed by Google, and used internally at Google, is part of making it a safer choice.

          Go could potentially be a great alternative to choose instead of Java in a lot of cases, which wouldn’t be the case to the same degree if it was a functional language.

          1. 8

            That Go is backed by Google hurts it, in my view. Google is good at many things, but those involving design or taste or aesthetic sense are not where it shines. Google was founded in the late ‘90s when PL was considered to be a dead field, and it shows.

            I understand what you’re saying, but I feel like there actually are a lot of people in the corporate world who dislike the mediocrity and the Java uber alles mentality. If they knew the right arguments to make and could agree on one specific high-power language (maybe Haskell, maybe Clojure since it runs on the JVM) I think that they’d be able to make a lot of progress.

            The “hard to hire” argument is a weird one, here. It’s short-sighted and just plain stupid to argue that it’s not worth using a language because it will take time to learn for new hires a new language, given that it takes time to learn a new codebase in any case. It seems to sound, to me, like “it’s hard to justify investing in our people to the execs”; if that’s the case, then those execs should be punched in the face.

        3. 20

          Let’s be clear: the message here is “don’t innovate too much, and aim for the 50th percentile programmer for the best chances of success, so everyone can feel included?” We’re to coddle programmers their whole career? Little wonder we re-write the world every five years with varying degrees of quality! I go through stages of deep disappointment with the intellectual laziness of the industry. I don’t know how people stay in. People become proud of what they don’t know.

          I have no beef with Go. If you like it, cool. But I very much despise this sort of populist pandering in the name of adoption, rather than genuine advancement.

          1. 12

            You work in an industry that prides itself on become-a-programmer-in-two-weeks courses. Of course people are going to cater to the minimum.

            (Not that I think Go does this.)

            1. 13

              An extremely innovative programming language, only understood by a few programmers, and very difficult to learn, would be useless to the industry.

              I agree that we need innovation in programming languages, but I also think that a new programming language must fit in a “complexity budget”. It’s okay for a programming language to innovate a lot, if it fits in this “complexity budget”, which makes the language learnable in a short amount of time.

              A language learnable in a few weeks can be used by almost any programmer. A language learnable in a few months will exclude programmers that are unable or unwilling to dedicate evenings or week-ends to this learning. A language learnable in a few years would require a sabbatical (but I’m unaware of any existing programming language requiring such an investment).

              My point is innovation in programming languages too often comes with an increase in complexity budget. And the more we increase the complexity budget, the more we limit the audience.

              Rob Pike wrote “The need to get programmers productive quickly in a new language means that the language cannot be too radical”. I would add that a new language can be radical only if the increased learning time is compensated by an increased productivity and quality in the future.

              By the way, if you compare Go to mainstream languages like C/C++/Java/PHP/Perl/Python/Ruby/JavaScript, it’s not that uninteresting. It brings thinks like CSP concurrency, structural typing with interfaces, composition over inheritance with embedded structs. Of course, if you compare it to OCaml/Haskell/Rust/Scala/F#, there is no question that Go is less innovative and radical (as a language – I’m not talking about the runtime, the tooling and the library). But the truth is that OCaml/Haskell/Rust/Scala/F# have not been designed to be mainstream languages. Go was.

              Maybe what you/we need is a successor to OCaml or Haskell, but with the design goal of becoming mainstream, at every level of the language (language itself, compiler, runtime, tools, libraries, ecosystem, etc.). What would be the equivalent of Go at Google: Language Design in the Service of Software Engineering for this new language?

              PS: One example of a programming language that I found quite radical and innovative for its time, and still easy to learn, would be Erlang.

              1. 5

                Maybe what you/we need is a successor to OCaml or Haskell, but with the design goal of becoming mainstream

                I think we might have something similar to that in Elixir. Elixir is unabashedly populist. I have shipped production Erlang apps and been badly burned trying to hire around it – so I am a bit gun-shy, but slowly warming to Elixir. It might end up being DSL soup (like Ruby), but maybe not… I will continue watching… with slow growing excitement.

                1. 2

                  That’s funny because I had a very constructive discussion with Saša Jurić, the author of Elixir in Action, a few days ago, on similarities and differences between Go and Erlang. I agree that Elixir is an interesting option for the same reasons and with the same reservations as you.

                  1. 1

                    It might end up being DSL soup (like Ruby), but maybe not…

                    That’s definitely a concern since it’s drawing lots of ruby developers, but in many ways the design of Elixir seems to be a reaction to a lot of ruby practices. Jose Valim (the creator) has counseled contributors that a DSL, if created, must exist on top of a well thought out API.

                    He also has this great talk DSL or No-DSL from 4 years ago.

                    1. 2

                      Yeah, I have yet to see a meta-programming system survive in an organization for too long. Generally initial coders love it and are very effective inside it – then under success conditions, it all falls apart…

                      1. 1

                        Why does it fall apart?

                        1. 4

                          Hiring and growth… which implies training and turnover. Finding people with a good mind for meta-programming is very challenging. Additionally, meta-programming is often not used with the level of restraint required to make it a good long term system (for examples: see Ruby). Beyond all that, when you are doing major meta-programming/DSL work – you have to document it as you would document a brand new language, the documentation / training overhead is brutal. Without documentation and without training, you are basically guessing how to use an undocumented programming language… fun.

                          In theory of course, you could overcome all these weaknesses, with “perfect” programmers – but in reality, it becomes a bloody mess and at some point – even those who initial wrote it and argued for it as like “Screw it, yeah, this is nonsense, lets port it to X” – X often being a very simple language like C or Java or in my very favorite example – it remained in Lisp – but anything but straightforward procedural programming was banned at the commit level (and scanned for with a nasty massive perl file)… Lisp - most of the Lisp things about Lisp.

                          1. 2

                            Yea, you see a lot of magic DSLs out there that grow organically under one person. As soon as they try (or have to) pass on that knowledge it falls. Here’s one I see in the making, but I doubt anyone outside of the prestigious original author are using this: https://github.com/nathanmarz/specter

                    2. 1

                      Out of curiosity, why Erlang made the hiring more difficult?

                      1. 1

                        Small talent pool, high pay requirements, decently hard to do in house training on unless they came from another functional language… it was a nightmare.

                      2. 1

                        If I’m not mistaken, I think that Elixir doesn’t let the programmer “reopen” a module and define or redefine functions, which should limit the kind of rogue monkey patching you find too often in Ruby.

                      3. 4

                        Maybe what you/we need is a successor to OCaml or Haskell, but with the design goal of becoming mainstream

                        IMO, the problem with this is that mainstream and good languages are more or less mutually exclusive. What I love and enjoy about Ocaml is what makes it unpopular.

                        1. 2

                          That’s a great point! Honestly, I hope you’re wrong, because if you’re right, then we’re doomed to either 1) program alone in a good language or 2) program as a team in a mediocre language.

                          Maybe we could draw inspiration from human languages here: Some people have a limited use of their mother tongue (limited vocabulary, limited understanding of grammar), others have a deep knowledge and mastery. Even the same person can use a different level of language, depending on the circumstances.

                          1. 2

                            The other alternative is to get a small group rallied around a core idea, like how suckless.org works. The upside to being into Haskell or Ocaml is that they are very expressive, meaning you can accomplish a lot with very little code. The lack of standard libraries hasn’t been a big issue for me in Ocaml because I can generally rewrite the portions I need pretty quickly.

                        2. 4

                          Haskell, as a language, is usable for mainstream purposes right now. OCaml is too. Haskell is 100% of our backend at my company.

                          You wouldn’t profit from making a more mainstream Haskell right now. Developments beyond Haskell are still being hammered out and researched.

                          1. 6

                            In fact, now would be a bad time to try to make a “mainstream” Haskell as we’re in the middle of figuring out some research and implementation at a couple different levels

                            I know what you mean, but don’t you think it is always a “bad time”? :-) This is the crux of the issue. One of the explicit goals of Haskell was to “serve as a basis for future research in language design” [1]. One the explicit goals of Go was to “address the problems faced in software development at Google, which led to a language that is not a breakthrough research language” [2]. It’s very difficult to innovate on on all fronts at the same time.

                            [1] https://www.haskell.org/onlinereport/haskell2010/haskellli2.html [2] https://talks.golang.org/2012/splash.article

                            1. 5

                              Haskell is still pushing things forward at the level it currently works for - example: https://www.cis.upenn.edu/~eir/papers/2012/singletons/paper.pdf

                              I don’t think you grokked my point. Haskell is ready for mainstream use, modulo libraries (not language), now. The library coverage has been plenty good for the work I do and I’m much happier using libraries written by Haskell users in Haskell than I am what’s available for JVM languages.

                              The DTPL stuff isn’t ready for wider use - yet. Churning what already works for mainstream use (Haskell) seems deeply wasteful. The GHC runtime system works a freakin' mint for the latency/throughput sensitive work I do with considerably less fuss (not zero) than the JVM.

                              To the extent that I can, I am trying to make Haskell more accessible.

                              My co-author is somebody that had never programmed before I taught her Haskell and started less than a year ago. How much easier does a mainstream programming language need to be for a total beginner? She still finds JS & Java difficult in ways that do not happen for her in Haskell.

                              There’s a lot of undiscovered value here, I think. But I believe it was shrouded in part by learning materials that weren’t sufficiently usable or accessible by non-CS people. That wasn’t an issue with the language, it was an issue with the approachability of how people taught the language.

                              I think my points here are why @mattgreenrocks sounds frustrated.

                              1. 5

                                Let’s consider a young professional programmer, gone through a computer science cursus, where he/she was taught C, Java and a bit of Lisp. Are you saying that learning Haskell would require a similar effort to learning Go?

                                1. 1

                                  You know this unanswerable and involves a lot of variables. Any assertions in either direction would be nonsense. Mu.

                                  Instead, let me say what I know.

                                  I know I’ve taught total beginners to programming the basics of programming in Haskell in a matter of months. I know I’ve taught people that already programmed for a living with FP experience to use Haskell in days.

                                  I know companies that train people with zero FP experience to write Haskell in 1-2 weeks of pair programming – then they’re on their own. One thing that helps with the latter is having a codebase already in place for them to learn from.

                                  I’ve taught many people over the internet as well. I don’t just use Haskell – teaching it is what I’m primarily known for. I know what’s possible.

                                  I also know it took me five years to learn Haskell, yet I’m able to get others going in a much shorter period of time. I believe this is because of the learning resources, not the language.

                                  1. 10

                                    Unfortunately, I have to discount everything else you have said because of such brazen intellectual dishonesty. If you are so deep in your own BS you can’t even admit that Go is easier to learn the Haskell, I simply can’t take anything else you have said seriously. Reeks of zealotry and fanaticism over pragmatism and honesty. This is a net-negative for the Haskell community, being honest about negatives of the language is a part of being a good steward of it.

                                    I love Haskell, so far no other language I have ever used has tickled my brain the way it does, it makes me happy and makes me feel good. I think it is a superior language to Go. That said, it has a steep learning curve and being in denial of that does a disservice to new users, because it makes them feel dumb rather than acknowledging “Yeah, this is harder than most languages to pick up, but it pays you back for it, keep striving, you will get over the hump!”

                                    I have gotten people up to speed in professional environments on Lisp, Erlang, Haskell, Go, and dozens of other languages over the past couple decades. Go’s simplicity and consistency is a killer feature when it comes to teaching people. You can hire people with no Go experience to be Go developers, and that is reasonable and sane, the overhead of learning Go is trivial. A professional developer can attain a mastery of Go in a week. Not bumbling “it mostly works” but actually understanding, because there simply isn’t that much there to know. I have literally gotten people up and running with NO programming experience writing complex selenium tests (using the Go driver) in a week – using basically every feature Go has to offer except for channels and channel select… and they often find some problem best solved by channels and concurrency within a few weeks and implement it without assistance.

                                    Over the past 3-4 years, I have seen a sad bend towards intellectual dishonesty in the Haskell community and it is depressing. Selling it as a magic bullet constantly, and it belittles the language, community and newcomers.

                                    1. 6

                                      Selling it as a magic bullet constantly

                                      As someone that keeps a close eye on Haskell, and keep reading about it (documentation, blogs, papers, code, etc.), but has not jumped into the bandwagon, I noticed this tendency too. Some people tend to present it as “magic bullet”, of course without saying anything about the remaining theoretical or practical issues (space leaks for example, to take a “classic”). Haskell is a really great technology, but I agree this attitude is a disservice to the language.

                                      1. 3

                                        It doesn’t take much reading on harder projects in Haskell (aka Warp from the Performance of Open Source Applications or Yesod from the earlier AOSA) http://www.aosabook.org/en/posa/warp.html to see that the really neato frito features of the language fall into a miasma of directives and special imports. Even though the code is short and I’m sure people are successful with it, it’s not straightforward enough for me to grok without learning a lot of syntax (beyond learn you a haskell stuff) just to get involved, then a lot of “what does this import do?” etc etc.

                                      2. 2

                                        I love Haskell, so far no other language I have ever used has tickled my brain the way it does, it makes me happy and makes me feel good. I think it is a superior language to Go. That said, it has a steep learning curve and being in denial of that does a disservice to new users, because it makes them feel dumb rather than acknowledging “Yeah, this is harder than most languages to pick up, but it pays you back for it, keep striving, you will get over the hump!”

                                        “Steep learning curve” is an interesting expression, because what it actually means is that one is learning quickly. Haskell does have a steep learning curve: you learn a lot, quickly. It also has a high learning curve. There’s a lot to learn. One can probably be as productive, as a writer of code, as an average employed Java programmer after 3-5 weeks of serious Haskell study (i.e. you can do whatever a junior programmer needs to do). As a reader, it depends highly on the specific code and the quality of documentation (as a community, Haskell isn’t great at documentation, although it’s getting a lot better) but there’s a lot of code that you won’t be able to read until you’ve been doing Haskell for months, if not years, and that’s not because the code is bad but because it’s a deep language. It also hurts our argument for the effectiveness and power of type signatures when we present lenses to new programmers and have to say, “don’t look at the types yet; they’ll hurt your eyes”.

                                        Over the past 3-4 years, I have seen a sad bend towards intellectual dishonesty in the Haskell community and it is depressing. Selling it as a magic bullet constantly, and it belittles the language, community and newcomers.

                                        I haven’t seen what I would call “intellectual dishonesty”, but there is a bit of counterproductive zealotry (I may be guilty of that as well). The truth is that Haskell is way farther along than 5-10 years ago. It’s far past being ready to tackle what most professional programmers do. Business people tend to write it off because it’s a 26-year-old language that (from their perspective) just now seems to be taking off, and they ask, “If it’s been around for so long and it’s so great, why isn’t it popular?” That leads to a tendency (in us) to overcompensate by presenting it as the absolute best choice for nearly all problems, when the reality is that it’s a very good choice for quite a large number of problems but (as you and I would agree) no “magic bullet”.

                                        On a side note, I think Haskell needs to work hard at building its community. Clojure has Cognitect and Conj and Clojure/West; as far as I know, Haskell doesn’t have any U.S. conferences. Clojure’s community leadership has been actively seeking to improve not only its age and gender diversity, but that of tech. It also has an aesthetic sense that is unmatched; {"one" 1} is just more attractive than fromList [("one", 1)]. Haskell’s great and I’m thrilled to be using it, but there’s a lot that we can learn from Clojure’s community.

                                        1. 6

                                          “Steep learning curve”…

                                          For the record, I was using the more conventional understanding of the phrase as “hard to learn”.

                                          One can probably be as productive, as a writer of code, as an average employed Java programmer after 3-5 weeks of serious Haskell study

                                          I have my doubts about this – but not sure it is worth arguing over. We can agree to disagree on this point without any confusion bleeding into future points.

                                          but there’s a lot of code that you won’t be able to read until you’ve been doing Haskell for months, if not years..

                                          I agree, and this is a noteworthy difference between Haskell and Go. Go you can jump into any code imaginable your second week and feel fairly comfortable… it is just Go. Even in some of the uglier OS specific pieces (syscalls, etc) – it is still very easy to read and understand, even for neophytes.

                                          Additionally, regardless of if it is because Haskell is a “deep language” or “hot garbage” – it really doesn’t matter from a business perspective, having code that will take someone years to be able to READ is terror inducing.

                                          I haven’t seen what I would call “intellectual dishonesty”, but there is a bit of counterproductive zealotry

                                          I flatly disagree with you on this point. Zealotry is obnoxious but often forgivable because it is done in a haze of ignorance. Excited children make bold claims, and generally you can smile and forgive them, because you remember when you were that young and that dumb. You can grow out of zealotry, you grow into intellectual dishonesty.

                                          Intellectual dishonesty is done by people who know better, who know they are lying. Those who actively omit and distort the truth while being absolutely aware of what they are doing, and are experts in the field. In a very real way, intellectual dishonesty is far more poisonous because it is done by those who you would depend on, those you would look to in order to assist you, those who are the elders of a community. They are where the misinformation the armies of zealots spout come from, they are original sources.

                                          It’s far past being ready to tackle what most professional programmers do. Business people tend to write it off because …

                                          I have reviewed Haskell 4 times for production use – and not once was its age brought up as a negative, or even brought up at all. The questions are simple: (1) How quickly can someone learn it and be able to read all the existing code? How long after that until they can ship production changes on top of that code? (2) How big is the market of developers? Growing or shrinking? (3) Will this be a liability or a asset going forward for the company.. IE: If we are given an outside audit / review for financing or are being purchased how will the outside investor or company look at that codebase?

                                          Generally speaking the answers where (1) Months, small patches in weeks maybe, probably months… (2) Tiny, slow growth… (3) Liability – and that is the end of the conversation. The upsides are complex and hard to explain and involve correctness, long term soundness and other things that are very challenging to get across in a useful way in a meeting.

                                          On a side note, I think Haskell needs to work hard at building its community. Clojure has

                                          Clojure has some very loud, bright voices at its core. It (the community around Clojure) has done stuff like associate bravery and joy with the language. Additionally, Clojure talks have taken place at lots of cons not directly related to Clojure, to spread Clojure. Java conferences were the primary thing – but they also did stuff for Ruby developers, Python developers, etc.

                                          It would be interesting to see what a talk about Haskell at a Ruby conference would look like… How would you spend an hour to convince people Haskell is worth using at a Ruby conference or a Python conference?

                                          Rust seems to have some bright lights as well – Specifically Yehuda Katz and his push for “You too can be a systems programmer!” is absolutely brilliant stuff – and he keeps doing talks on it – at places like Golden Gate Ruby Conference. His talk is amazing in that it makes Rust feel very accessible and shows off a lot of things that Ruby users care about.

                                          Elixir is doing amazing outreach to Ruby developers, and naturally picking up a lot of Erlang developers. It is unabashedly populist while remaining very honest about downsides and risks. This honesty that seems to be somewhat baked into this community is a huge asset to it – and IMHO, one of the reasons it might end up being a massive success. I suspect some of this honesty came as a response to intellectual dishonesty among Ruby evangelists (who directly profited off of promises that where never fulfilled).

                                          1. 1

                                            “Steep learning curve” is an interesting expression, because what it actually means is that one is learning quickly. Haskell does have a steep learning curve: you learn a lot, quickly.

                                            When you climb a “steep” path, you progress slowly, not “quickly”. Similarly, a “steep learning curve” implies you learn slowly, not quickly. But I’m nitpicking :)

                                            1. 1

                                              It is sloppy language at best. In physical terms, climbing a steep path obviously conjures the memory of the physicality of climbing a hill.

                                              But in more mathy terms, if the Y axis was “knowledge” (IE: learned) and the X was time. A steep learning curve would mean a rapid increase in knowledge. If the Y axis represents difficulty, then the a steep learning curve means increasing difficulty… I think different people think of different things on the Y axis.

                                              1. 2

                                                I think many people use an X axis of “what I can do” and Y of “what I must learn”. This may not be the one true definition of learning curve, but it allows “steep learning curve” and “You can’t do anything until you learn everything” to align.

                                                1. 1

                                                  Honestly, the never occurred to me, but probably fits most graphs more sanely.

                                                2. 1

                                                  You’re nitpicking even more than me, but it’s useful because your comment is completely true. Thanks!

                                                  1. 3

                                                    If you can’t be a pendant on lobste.rs where can you?! :)

                                                    1. 2

                                                      there are lots of places you can hang out!

                                                      1. 1

                                                        Haha, never thought about this before! :)

                                                        1. 1

                                                          If you can’t be a pendant on lobste.rs where can you?! :)

                                                          s/pendant/pedant/

                                                          (Normally, I wouldn’t do this; but with “meta” in your name, I assume you don’t mind the meta-ness of my doing so.)

                                                          1. 1

                                                            No, I am a gorgeous pendant. Who would want to be a pedant?

                                                            ducks

                                                  2. -2

                                                    as an average employed Java programmer after 3-5 weeks of serious Haskell study

                                                    These assertions are pretty dodgy when you haven’t taught anybody Haskell and have no practical experience.

                                                    I would urge you to be more epistemically cautious in how you present your case. It just gives people more surface area with which to undermine your points and it makes you look very unreasonable.

                                                    Your overreach has been noticed and is making reasonable people grumble.

                                                    Hard sales does not have a constructive role to play among otherwise serious professionals.

                                                    On a side note, I think Haskell needs to work hard at building its community.

                                                    I agree.

                                                    Haskell doesn’t have any U.S. conferences

                                                    What?

                                                    The Haskell hackathons have been going strong for a long time around the world, especially BayHac, NYC, and Zurich ones.

                                                    CUFP always has a lot of Haskellers/DTPLers, LambdaConf was like 50% Haskell, LambdaJam is predominantly Haskell.

                                                    And that’s just off the top of my head.

                                                    1. 1

                                                      Haskell doesn’t have any U.S. conferences … What?

                                                      I suspect the implication was “brand name” conferences. IE: GopherCon and GothamGo.

                                                  3. -1

                                                    You know this unanswerable and involves a lot of variables.

                                                    so deep in your own BS you can’t even admit that Go is easier to learn the Haskell,

                                                    I don’t think I said anything of the sort. I explicitly made the point that making such claims didn’t make sense. Your rudeness is not welcome or constructive.

                                                    they often find some problem best solved by channels and concurrency within a few weeks and implement it without assistance.

                                                    MVars (channel, of a sort) and channels are the most popular methods for handling concurrency in Haskell.

                                                    I’ll leave it at that. Ego is getting in the way of what could’ve been good conversation. Please do not reply.

                                              2. 7

                                                I read “modulo libraries (not language)” as “Not ready for mainstream use”.

                                                Surely if you want to build things you’re not well served by a language with poor libraries, no matter what else it offers.

                                                1. 2

                                                  I read “modulo libraries (not language)” as “Not ready for mainstream use”.

                                                  If the library situation with Golang satisfies you, then Haskell will be even better. It only compares disfavorably if you find writing a quick wrapper binding for the sort of thing Java/Python already have to be unacceptable.

                                                  At work we use libraries for Boilerpipe, beanstalkd, Riak, Percona MySQL, Redis, and dclass browser classification. And a lot more.

                                                  Full listing of what’s on Hackage: http://hackage.haskell.org/packages/

                                                2. 1

                                                  My co-author is somebody that had never programmed before I taught her Haskell and started less than a year ago. How much easier does a mainstream programming language need to be for a total beginner? She still finds JS & Java difficult in ways that do not happen for her in Haskell.

                                                  Maybe there are no easy or hard languages. Just more or less enthusiastic teachers. :)

                                                  1. 2

                                                    Static learning resources can make a huge difference as well. I wrote my guide for learning Haskell and the resources recommended there work considerably better than what people had usually used before.

                                            2. 2

                                              I think Haskell offers a great RIO of long term productivity for the cost to learn, but the sad truth is that it’s still an unknowable metric. As an industry we take for granted that whatever we use is more productive than assemby, but other than that we are all fumbling around in the dark. There’s no proof that this is more productive than that, only anecdotia.

                                              Languages that have a high cost to learn are often disregarded, because there is no way to prove it is better. All proof is effectively: I learned it, and it seemed better to me that what I was using before.

                                              This is why I think it’s my duty to learn a number of tools, then I’ll my own personal experience and judgement to apply to my own analysis.

                                              1. 5

                                                As an industry we take for granted that whatever we use is more productive than assemby, but other than that we are all fumbling around in the dark. There’s no proof that this is more productive than that, only anecdotia.

                                                Additionally, depends what you measure. Things the are wonderful for the productivity of individuals (rich DSLs, macros galore, terse syntax) are often horrible for the productivity of teams with turnover and hundreds or thousands of developers. It all depends what you are trying to optimize around.

                                                1. 2

                                                  I cannot agree more.

                                                  Things like operator overloading or macros are very tempting when I write code, because they strengthen the feeling that I have written smart, dense, beautiful code. But they are too often an obstacle when I read code, especially a new code base written by others.

                                                2. 2

                                                  Languages that have a high cost to learn are often disregarded, because there is no way to prove it is better. All proof is effectively: I learned it, and it seemed better to me that what I was using before.

                                                  We could replace Haskell with vim in this discussion :-) “Big learning curve, but it’s worth it!” Some agree, some disagree. Alas, it’s difficult to prove, so all we have is trying it for ourselves, or collecting and aggregating the opinions of our peers.

                                                  1. 1

                                                    Yeah, but choosing the wrong editor is an annoyance. Choosing the wrong language for your startup could literally kill your business when you can’t hire and grow.

                                                    1. 1

                                                      I agree, of course. This specific comment I posted was not meant to be really serious :)

                                              2. 4

                                                Others have said much the same, but if new languages shouldn’t aim for the 50th percentile, which percentile should they aim for? Honest question: of what use is the genuine advancement of a language designed for 90th percentile programmers?

                                                1. 8

                                                  Honest question: of what use is the genuine advancement of a language designed for 90th percentile programmers?

                                                  How about languages that turn 50th-percentile programmers into 90th-percentile programmers? I’d argue that Haskell fits the bill. You don’t have to be a 90th-percentile programmer to be more productive in it than you’d be in Java. In fact, if your knowledge of each is equal, you’d be more productive in Haskell pretty quickly. I really think that anyone who can learn to program Java well can do even better in Haskell.

                                                  I wasn’t born a 9xth-percentile programmer. My first words weren’t “functional programming”, and I wasn’t 10x-ing it in grade school with the Haskell skillz. I don’t buy the argument that most programmers are immutably mediocre, either. The mediocrity exists because we’ve done, as a professional group, an absolutely terrible job of managing our social status and have let ourselves be shoved into the role of business subordinates, which inflicts mediocrity upon us. It can be changed.

                                                  1. 2

                                                    How about languages that turn 50th-percentile programmers into 90th-percentile programmers?

                                                    Is go one of those languages? From what I’ve read, it seems pretty successful at improving the productivity of decent but not great Python and c++ devs.

                                                    1. 1

                                                      It can be changed.

                                                      How? Michael, I agree with you on this. If you have any “strategy” or any link on how to change this, then I’m interested.

                                                  2. 6

                                                    I think that the worst thing about the pandering is that it comes with a certain essentialism. People aren’t just catering to the 50th-percentile programmer, but also assuming that he can’t improve, and that our industry is just doomed to be staffed by mediocrities. They tend to assume that the Java mines are full of idiots who will never be able to understand Haskell. In reality, they’re smart enough. They’re just disengaged because decades of working for idiots (let’s be honest; most programmers work for non-technical jokers driven by emotion rather than reason) have left them seeing no better possibility than business-oriented Java. They have the intellectual horsepower needed to improve. What they don’t have is encouragement or a sense of purpose. Working on user stories shoveled to them by a 27-year-old “product owner” or “scrotum master” pays the bills.

                                                    This industry is overloaded with mediocre people (and, largely, because there’s so goddamn much money in software that it tolerates a lot of worthless upper management) but that’s because corporate development environments make people mediocre. This is good news, because it means that there’s hope of fixing it.

                                                    1. 2

                                                      This industry is overloaded with mediocre people (and, largely, because there’s so goddamn much money in software that it tolerates a lot of worthless upper management) but that’s because corporate development environments make people mediocre.

                                                      Alas, I don’t think this is really specific to our industry, don’t you?

                                                      I wrote “alas”, because if it was specific to our industry, then I think it would be easier to fix.