9 ms·

tldr: use Haskell because it solves all problems, but actually don't use Haskell use Go/Rust instead because they are more suited to the mainstream programmer,

tldr: use Haskell because it solves all problems, but actually don't use Haskell use Go/Rust instead because they are more suited to the mainstream programmer, but Haskell is more powerful. What.

supergirl 11y ago
title is already a big hint that the article is bad
- profinger 11y ago
  It's WIRED of course it's bad.
DiabloD3 11y ago
And the thing is, that is largely why I love Haskell and Erlang... and then never use them for a project. Its really frustrating to me.
- jerf 11y ago
  If you like Erlang but can't use it, consider either Go or Elixir. The former is probably the "more enterprise" and conservative bet, but Elixir is growing enough that it's probably not going away any time soon. (Honestly, whenever I have to go back to programming in a language without cheap threads I am often sad with the BS that comes out of my fingers. Single-threaded languages, even ones wrapped around an event loop with various hacks to try to obscure the single-threadedness, are so 20th century compared to the ones that were built for it from day one.)
  - DiabloD3 11y ago
    Go is a language with serious flaws. It clearly was not made with threads in mind, and just gives low level primitives instead of just exposing a model like Erlang actors. I have high hopes for Rust, though. Even quite a few people at Google seem to have converted to the Rust camp, away from Go.
    - MikeKusold 11y ago
      > It clearly was not made with threads in mind What exactly are you trying to do? Golang was designed from the start for high concurrency programs. Instead of threads, they use go routines. https://golang.org/doc/faq#goroutines https://golang.org/doc/faq#goroutines
    - jerf 11y ago
      I've used both extensively. The practical differences between a goroutine and an Erlang process are small. The most significant difference is enforcement of isolation vs. isolation-by-convention (and bear in mind the latter is not the same as "no isolation"), but this is a bigger difference in theory than in fact. OTP being missing matters less than you might initially think, too. I implement what bits of supervisor trees can be implemented here: https://github.com/thejerf/suture https://github.com/thejerf/suture , and in general, with the way Go is structured, gen_servers and such just sort of melt away into "things you interact with over channels" without much fuss. (IMHO, OTP is generally a good thing, but the reification of gen_X so deeply into the language was an error. I actually prefer Go+Suture's way of bringing up a server; much simpler, virtually no loss of capability in practice. Again, the theoretical difference turns out to be larger than the practical difference.) (And before someone angrily smashes the reply button, pleases meditate on the distinction between a "small difference" and "no difference", especially the subjective nature of such judgment calls. You can certainly quibble with the size I assign to the differences but please don't reply as if I claimed no difference, or as if I have not demonstrated awareness of the difference between a strictly-enforced no-sharing environment vs. unenforced no-sharing convention, and, likewise, let's not pretend "isolation by convention" is the same thing in practice as "traditional shared-memory threading". Memory sharing can bite you in Go, and while I've gotten pretty used to the necessary patterns to avoid that (spending years in Erlang first is really good training for that), I don't deny it is non-zero cognitive effort required.)
    - Cshelton 11y ago
      Go is good, and yes, every language has serious flaws. I think what you really meant is Go is nothing special. It's a nice language with nice syntax, but the ideas behind it aren't different. The reason people like Rust is it is different. It's what people wished C++ could have been so many years ago. With that said though, each of the languages have its place and uses. Sure many things can be done with both of them, but some things only Rust can do/will be able to do(many unstable things still). Both languages will be successful imo. I can see Go and Rust being taught as the primary languages in the academic world and in the enterprise world. If I were starting out in school, I'd probably pick Go and Javascript.
  - vezzy-fnord 11y ago
    I'm not sure in what setting would Erlang be inappropriate, but somehow Elixir would be fine. Elixir actually adds a further layer of complication compared to Erlang, which is a straightforward pattern matching, expression-based language with recursion and polymorphic functions for looping and conditionals. Elixir looks Ruby-ish, but that illusion breaks down very quickly since the underlying semantics are anything but. Not to mention Elixir doesn't shield you from having to be aware of the Erlang runtime, the VM and OTP.
  - bduerst 11y ago
    As someone who uses python, what are some reasons for me to switch to Go?
    - robmccoll 11y ago
      The language itself is far simpler (fewer built-in basic complex data types, composition over inheritance, no overloading, no slots) but still batteries-included w.r.t. the standard library. You'll likely get a performance improvement unless you are writing some really zany code. Static types and the compiler will actually make your life much easier when dealing with larger code bases (no more wondering what type a parameter is, if it compiles there is a much better chance that it will just work, fewer worries about unhandled runtime conditions). Less magic (no decorators or deep class hierarchies) which means its easier to trace control flow in someone else's code. Verbose, but still very clean error handling. IMHO, the import system is pretty broken and awful, but importing someone else's packages straight off of github is still much better than pypi / wheelhouses. Compiled static binaries by default means that building somewhere and then shipping a binary is quite easy.
      - bduerst 11y ago
        Thanks - that's what I was looking for. I'll read more about the deep class hierarchies to see if it would be a problem. Shame to hear about the importing, I kind of like Python's importing (sans the circular dings).
        robmccoll 11y ago
        Sure - the import thing really just depends on what you're doing and how you use imports. Personally I found it to be really cool at first, but later realized it's more of an 80% solution that makes great demos but runs into practical problems (not flexible, tools around versioning or and relative paths are hackish). With hierarchies, you can mostly implement them, but they language pushes you away from them, which is really a feature.
    - bliti 11y ago
      Depends on what you use Python for.
akhilcacharya 11y ago
tldr: functional languages may be the future. Or maybe not.
- krapp 11y ago
  Always in motion, the future is.
- codygman 11y ago
  Hm, I took away this: tldr: functional languages were the future for Facebook's new spam fighting tool, they weren't for a startup owner who has previous professional Haskell experience. Consider for your next project and possibly live the future now.
dspillett 11y ago
For technical reasons Haskell is a good choice. For people reasons it is not (currently at least). The second point trumps the first at this time. Unless I'm missing something the logic here is not as intractable as some seem to think.
- boothead 11y ago
  It would seem that for people reasons Haskell isn't a good choice. However I would say that right now, for people reasons, Haskell is one of the best choices you could make. Haskell is a very good flag for the kinds of people that make good programmers: * It's hard to learn. * Chances of getting a job are minimal, therefore people learn it mostly for their own self edification, and have the kind of grit that keeps them studying for a year or two with not external reward. * Learning Haskell teaches you some fundamentals that aren't readily discoverable elsewhere. No one is hiring Haskellers right now, so what you have is a pool of very able programmers, who would love to do Haskell (in fact many would love the chance to use Haskell so much that they'd take a pay cut to do so) and very few people offering them what they want. If you're a start up, you want to hire a stellar team (possibly at a bit of a discount) and your domain is a good fit then you should seriously consider hiring some Haskellers and letting them write Haskell.
  - begriffs 11y ago
    At Wagon we use Haskell as our main language. And we are hiring. :) http://www.wagonhq.com/jobs/haskell-engineer http://www.wagonhq.com/jobs/haskell-engineer
    - boothead 11y ago
      I would guess that you'd corroborate my characterization of hiring Haskellers as an embarrassment of riches then? :-)
  - swsieber 11y ago
    My thinking is sort of along the same vein: you can train people, you can't "train" a language. And if you can't train the person, why did you hire them? The cost of training is much like the cost of evaluating frameworks and tools and choosing the best ones (with the huge caveat that you invested in a person, and they can leave... but if their strongest suite is the obscure language, it puts a damper on things...)

tldr: use Haskell because it solves all problems, but actually don't use Haskell use Go/Rust instead because they are more suited to the mainstream programmer, but Haskell is more powerful. What.

supergirl 11y ago

title is already a big hint that the article is bad

profinger 11y ago
It's WIRED of course it's bad.

DiabloD3 11y ago

And the thing is, that is largely why I love Haskell and Erlang... and then never use them for a project. Its really frustrating to me.

jerf 11y ago
If you like Erlang but can't use it, consider either Go or Elixir. The former is probably the "more enterprise" and conservative bet, but Elixir is growing enough that it's probably not going away any time soon. (Honestly, whenever I have to go back to programming in a language without cheap threads I am often sad with the BS that comes out of my fingers. Single-threaded languages, even ones wrapped around an event loop with various hacks to try to obscure the single-threadedness, are so 20th century compared to the ones that were built for it from day one.)
- DiabloD3 11y ago
  Go is a language with serious flaws. It clearly was not made with threads in mind, and just gives low level primitives instead of just exposing a model like Erlang actors. I have high hopes for Rust, though. Even quite a few people at Google seem to have converted to the Rust camp, away from Go.
  - MikeKusold 11y ago
    > It clearly was not made with threads in mind What exactly are you trying to do? Golang was designed from the start for high concurrency programs. Instead of threads, they use go routines. https://golang.org/doc/faq#goroutines https://golang.org/doc/faq#goroutines
  - jerf 11y ago
    I've used both extensively. The practical differences between a goroutine and an Erlang process are small. The most significant difference is enforcement of isolation vs. isolation-by-convention (and bear in mind the latter is not the same as "no isolation"), but this is a bigger difference in theory than in fact. OTP being missing matters less than you might initially think, too. I implement what bits of supervisor trees can be implemented here: https://github.com/thejerf/suture https://github.com/thejerf/suture , and in general, with the way Go is structured, gen_servers and such just sort of melt away into "things you interact with over channels" without much fuss. (IMHO, OTP is generally a good thing, but the reification of gen_X so deeply into the language was an error. I actually prefer Go+Suture's way of bringing up a server; much simpler, virtually no loss of capability in practice. Again, the theoretical difference turns out to be larger than the practical difference.) (And before someone angrily smashes the reply button, pleases meditate on the distinction between a "small difference" and "no difference", especially the subjective nature of such judgment calls. You can certainly quibble with the size I assign to the differences but please don't reply as if I claimed no difference, or as if I have not demonstrated awareness of the difference between a strictly-enforced no-sharing environment vs. unenforced no-sharing convention, and, likewise, let's not pretend "isolation by convention" is the same thing in practice as "traditional shared-memory threading". Memory sharing can bite you in Go, and while I've gotten pretty used to the necessary patterns to avoid that (spending years in Erlang first is really good training for that), I don't deny it is non-zero cognitive effort required.)
  - Cshelton 11y ago
    Go is good, and yes, every language has serious flaws. I think what you really meant is Go is nothing special. It's a nice language with nice syntax, but the ideas behind it aren't different. The reason people like Rust is it is different. It's what people wished C++ could have been so many years ago. With that said though, each of the languages have its place and uses. Sure many things can be done with both of them, but some things only Rust can do/will be able to do(many unstable things still). Both languages will be successful imo. I can see Go and Rust being taught as the primary languages in the academic world and in the enterprise world. If I were starting out in school, I'd probably pick Go and Javascript.
- vezzy-fnord 11y ago
  I'm not sure in what setting would Erlang be inappropriate, but somehow Elixir would be fine. Elixir actually adds a further layer of complication compared to Erlang, which is a straightforward pattern matching, expression-based language with recursion and polymorphic functions for looping and conditionals. Elixir looks Ruby-ish, but that illusion breaks down very quickly since the underlying semantics are anything but. Not to mention Elixir doesn't shield you from having to be aware of the Erlang runtime, the VM and OTP.
- bduerst 11y ago
  As someone who uses python, what are some reasons for me to switch to Go?
  - robmccoll 11y ago
    The language itself is far simpler (fewer built-in basic complex data types, composition over inheritance, no overloading, no slots) but still batteries-included w.r.t. the standard library. You'll likely get a performance improvement unless you are writing some really zany code. Static types and the compiler will actually make your life much easier when dealing with larger code bases (no more wondering what type a parameter is, if it compiles there is a much better chance that it will just work, fewer worries about unhandled runtime conditions). Less magic (no decorators or deep class hierarchies) which means its easier to trace control flow in someone else's code. Verbose, but still very clean error handling. IMHO, the import system is pretty broken and awful, but importing someone else's packages straight off of github is still much better than pypi / wheelhouses. Compiled static binaries by default means that building somewhere and then shipping a binary is quite easy.
    - bduerst 11y ago
      Thanks - that's what I was looking for. I'll read more about the deep class hierarchies to see if it would be a problem. Shame to hear about the importing, I kind of like Python's importing (sans the circular dings).
      - robmccoll 11y ago
        Sure - the import thing really just depends on what you're doing and how you use imports. Personally I found it to be really cool at first, but later realized it's more of an 80% solution that makes great demos but runs into practical problems (not flexible, tools around versioning or and relative paths are hackish). With hierarchies, you can mostly implement them, but they language pushes you away from them, which is really a feature.
  - bliti 11y ago
    Depends on what you use Python for.

akhilcacharya 11y ago

tldr: functional languages may be the future. Or maybe not.

krapp 11y ago
Always in motion, the future is.
codygman 11y ago
Hm, I took away this: tldr: functional languages were the future for Facebook's new spam fighting tool, they weren't for a startup owner who has previous professional Haskell experience. Consider for your next project and possibly live the future now.

dspillett 11y ago

For technical reasons Haskell is a good choice. For people reasons it is not (currently at least). The second point trumps the first at this time. Unless I'm missing something the logic here is not as intractable as some seem to think.

boothead 11y ago
It would seem that for people reasons Haskell isn't a good choice. However I would say that right now, for people reasons, Haskell is one of the best choices you could make. Haskell is a very good flag for the kinds of people that make good programmers: * It's hard to learn. * Chances of getting a job are minimal, therefore people learn it mostly for their own self edification, and have the kind of grit that keeps them studying for a year or two with not external reward. * Learning Haskell teaches you some fundamentals that aren't readily discoverable elsewhere. No one is hiring Haskellers right now, so what you have is a pool of very able programmers, who would love to do Haskell (in fact many would love the chance to use Haskell so much that they'd take a pay cut to do so) and very few people offering them what they want. If you're a start up, you want to hire a stellar team (possibly at a bit of a discount) and your domain is a good fit then you should seriously consider hiring some Haskellers and letting them write Haskell.
- begriffs 11y ago
  At Wagon we use Haskell as our main language. And we are hiring. :) http://www.wagonhq.com/jobs/haskell-engineer http://www.wagonhq.com/jobs/haskell-engineer
  - boothead 11y ago
    I would guess that you'd corroborate my characterization of hiring Haskellers as an embarrassment of riches then? :-)
- swsieber 11y ago
  My thinking is sort of along the same vein: you can train people, you can't "train" a language. And if you can't train the person, why did you hire them? The cost of training is much like the cost of evaluating frameworks and tools and choosing the best ones (with the huge caveat that you invested in a person, and they can leave... but if their strongest suite is the obscure language, it puts a damper on things...)