4 ms·

Can I ask what language you are used to? I hear how nice go is as a language a lot, but coming from haskell, go is hideous in comparison.

deleted 14y ago
[deleted]
chimeracoder 14y ago
Go is going to look hideous to you because you're probably expecting functional things like list comprehensions (which Go doesn't have) and a very intricate type system allowing for things like generics (which Go doesn't have either). Go code will look a little less DRY to you as a result, which is a fair criticism, but it makes up for that by being incredibly opinionated (that's a good thing), being incredibly easy to prototype in, and being incredibly easy to refactor painlessly.
- papsosouid 14y ago
  >Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic sugar and not used much in haskell. Python seems to encourage their use a lot, but you hardly even see them in haskell code. >a very intricate type system allowing for things like generics (which Go doesn't have either). That is definitely one of the big problems, but I take issue with the characterization of that as needing "a very intricate type system". Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. >being incredibly easy to prototype in, and being incredibly easy to refactor painlessly. Those are actually two of the other big issues going from go to haskell. Go is harder to prototype in, and it is easy to add bugs when refactoring because the type system is so poor.
  - chimeracoder 14y ago
    > Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference. > Go is harder to prototype in, and it is easy to add bugs when refactoring because the type system is so poor. This is where we'll have to agree to disagree. It's definitely not harder to prototype in - and I say this as a functional programmer - and if you find the type system to be inadequate when refactoring, it sounds to me like you're trying to write idiomatic Haskell in Go. Go's type system, by design, stays out of the way - if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them. As for generics, this gets beaten to death on every single Go post on HackerNews. Yes, Go would ideally have generics. Yes, there are tradeoffs involved. Yes, those tradeoffs have been explained by the Go developers at length. Yes, they would be open to including them in the future, if somebody addressed the existing concerns. No, nobody seems to mind that they're missing from the language as-is, given those tradeoffs.
    - papsosouid 14y ago
      You are contradicting yourself about parametric polymorphism. First you acknowledge it doesn't exist, then you claim a limited workaround solves it. >It's definitely not harder to prototype in - and I say this as a functional programmer Have you used haskell to make the comparison? >if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them. I don't understand where you are coming from here. I am not thinking about types, that is why I need the compiler to point out when I mess them up. The problem is go has such a limited type system, that you have to change much more code when you refactor, and the type system is inadequate for catching many errors, in particular dealing with error handling. The combination makes go worse for refactoring than haskell. It is certainly much better than python for example, but you seem to be convinced that go is the top of the spectrum and nothing can exist above it.
      - dman 14y ago
        I have been wanting to learn Haskell for some time. Is Real World Haskell still the best book for the language? Could you point me to some well written libraries/projects that are considered idiomatic haskell? Would appreciate the pointers.
- zem 14y ago
  actually, the thing i find most lacking in go (although granted i've only done a few toy programs in the language) is sum types. it would make error handling a lot more pleasant, for one. i'm excited about rust, which did go the algebraic datatype route.
codygman 14y ago
I'll tell you that coming from Python/C it looks very nice. I'm actually learning haskell atm (use xmonad for a window manager), I'm afraid that if it lives up to it's hype I won't want to program in anything else. Also playing with Racket, Clojure, and good ol' Common Lisp.
jgrahamc 14y ago
Define hideous.
- papsosouid 14y ago
  "Extremely unpleasant"
tel 14y ago
Here's a comparable Haskell server, warts and all {-# LANGUAGE OverloadedStrings #-} import Snap import qualified Data.ByteString as BS main :: IO () main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100 I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Snap's Enumerator library and this is slightly closer to the design being tested in the other servers since it'll allocate the whole bytestring instead of writing it lazily.
- e12e 14y ago
  I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ http://localhost:8000/ -- nodejs completed in 160 seconds, go in 170 seconds. Nodejs had a few requests around 8 seconds, and go had a worst time of almost 5 seconds. (This is on an old desktop, with a core 2 duo - roughly 6000 "bogomips" pr core, two cores). I'm guessing the haskell solutions ran out of resources, but I'm not sure.
  - tel 14y ago
    Not sure, I'm trying to replicate it but I'm having a tough time with OSX's network stack. I can't siege or ab very well. The Haskell server tends to stay under 6Mb on my machine though. I'll keep stressing it. http://imgur.com/b89bxST http://imgur.com/b89bxST
  - danieldk 14y ago
    Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.
    - 14y ago
dscrd 14y ago
I studied Haskell for a decade with the goal of actually using it for production software. When I finally found a nice gap to try it, the experience was mostly awful. Go was such a huge relief after that horrible catastrophe language that seems to still continue to wreck new generations. Please, please, don't poison your career on focusing on a single language, especially one as disturbing as Haskell.
- gtani 14y ago
  What were the specific problems you had with haskell?
  - dscrd 14y ago
    I had several small things (laziness, poor libraries [in 2009], failing to get anyone else in the organisation even the slightest bit interested, my own lacking skills) but the overall worst problem was the feeling of the disconnect between the language and the host running my program. That is of course more or less always an issue when one uses a higher level language, but I felt Haskell was so far off that it disturbed me. Also, the negative effect one gets after going back to one's own code after several months seemed much much worse in Haskell. Haskell code is too thick, too concise, not unlike mathematics. I find it ironic that the community, apparently, values that. I bet others have had better experiences, but I definitely did not. Hanging around with Haskell clearly taught me many good things about program design, but I don't foresee myself wanting to ever write anything on the platform ever again.
- papsosouid 14y ago
  >Please, please, don't poison your career on focusing on a single language My career is likely older than you, I think it'll survive the horrors of using a good language. I've been running production web sites on haskell for a year so far, and it has been great.
  - dscrd 14y ago
    "My career is likely older than you" Your career spans over 30 years? If so, I applaud you and of course withhold my rights to criticize your choices without knowing more details.

deleted 14y ago

[deleted]

chimeracoder 14y ago

Go is going to look hideous to you because you're probably expecting functional things like list comprehensions (which Go doesn't have) and a very intricate type system allowing for things like generics (which Go doesn't have either). Go code will look a little less DRY to you as a result, which is a fair criticism, but it makes up for that by being incredibly opinionated (that's a good thing), being incredibly easy to prototype in, and being incredibly easy to refactor painlessly.

papsosouid 14y ago
>Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic sugar and not used much in haskell. Python seems to encourage their use a lot, but you hardly even see them in haskell code. >a very intricate type system allowing for things like generics (which Go doesn't have either). That is definitely one of the big problems, but I take issue with the characterization of that as needing "a very intricate type system". Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. >being incredibly easy to prototype in, and being incredibly easy to refactor painlessly. Those are actually two of the other big issues going from go to haskell. Go is harder to prototype in, and it is easy to add bugs when refactoring because the type system is so poor.
- chimeracoder 14y ago
  > Parametric polymorphism is very simple, and has been a completely solved issue for a very long time. There is simply no excuse for a brand new language to be decades behind on something so easy to do right. Go has addressed this; their approach is Go's interfaces, which combines the best of all worlds: duck typing with static type checks and type inference. > Go is harder to prototype in, and it is easy to add bugs when refactoring because the type system is so poor. This is where we'll have to agree to disagree. It's definitely not harder to prototype in - and I say this as a functional programmer - and if you find the type system to be inadequate when refactoring, it sounds to me like you're trying to write idiomatic Haskell in Go. Go's type system, by design, stays out of the way - if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them. As for generics, this gets beaten to death on every single Go post on HackerNews. Yes, Go would ideally have generics. Yes, there are tradeoffs involved. Yes, those tradeoffs have been explained by the Go developers at length. Yes, they would be open to including them in the future, if somebody addressed the existing concerns. No, nobody seems to mind that they're missing from the language as-is, given those tradeoffs.
  - papsosouid 14y ago
    You are contradicting yourself about parametric polymorphism. First you acknowledge it doesn't exist, then you claim a limited workaround solves it. >It's definitely not harder to prototype in - and I say this as a functional programmer Have you used haskell to make the comparison? >if you're writing Go idiomatically, you really shouldn't be thinking very much about the types as you write them. I don't understand where you are coming from here. I am not thinking about types, that is why I need the compiler to point out when I mess them up. The problem is go has such a limited type system, that you have to change much more code when you refactor, and the type system is inadequate for catching many errors, in particular dealing with error handling. The combination makes go worse for refactoring than haskell. It is certainly much better than python for example, but you seem to be convinced that go is the top of the spectrum and nothing can exist above it.
    - dman 14y ago
      I have been wanting to learn Haskell for some time. Is Real World Haskell still the best book for the language? Could you point me to some well written libraries/projects that are considered idiomatic haskell? Would appreciate the pointers.
zem 14y ago
actually, the thing i find most lacking in go (although granted i've only done a few toy programs in the language) is sum types. it would make error handling a lot more pleasant, for one. i'm excited about rust, which did go the algebraic datatype route.

codygman 14y ago

I'll tell you that coming from Python/C it looks very nice. I'm actually learning haskell atm (use xmonad for a window manager), I'm afraid that if it lives up to it's hype I won't want to program in anything else. Also playing with Racket, Clojure, and good ol' Common Lisp.

jgrahamc 14y ago

Define hideous.

papsosouid 14y ago
"Extremely unpleasant"

tel 14y ago

Here's a comparable Haskell server, warts and all {-# LANGUAGE OverloadedStrings #-} import Snap import qualified Data.ByteString as BS main :: IO () main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100 I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Snap's Enumerator library and this is slightly closer to the design being tested in the other servers since it'll allocate the whole bytestring instead of writing it lazily.

e12e 14y ago
I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ http://localhost:8000/ -- nodejs completed in 160 seconds, go in 170 seconds. Nodejs had a few requests around 8 seconds, and go had a worst time of almost 5 seconds. (This is on an old desktop, with a core 2 duo - roughly 6000 "bogomips" pr core, two cores). I'm guessing the haskell solutions ran out of resources, but I'm not sure.
- tel 14y ago
  Not sure, I'm trying to replicate it but I'm having a tough time with OSX's network stack. I can't siege or ab very well. The Haskell server tends to stay under 6Mb on my machine though. I'll keep stressing it. http://imgur.com/b89bxST http://imgur.com/b89bxST
- danieldk 14y ago
  Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.
  - 14y ago

dscrd 14y ago

I studied Haskell for a decade with the goal of actually using it for production software. When I finally found a nice gap to try it, the experience was mostly awful. Go was such a huge relief after that horrible catastrophe language that seems to still continue to wreck new generations. Please, please, don't poison your career on focusing on a single language, especially one as disturbing as Haskell.

gtani 14y ago
What were the specific problems you had with haskell?
- dscrd 14y ago
  I had several small things (laziness, poor libraries [in 2009], failing to get anyone else in the organisation even the slightest bit interested, my own lacking skills) but the overall worst problem was the feeling of the disconnect between the language and the host running my program. That is of course more or less always an issue when one uses a higher level language, but I felt Haskell was so far off that it disturbed me. Also, the negative effect one gets after going back to one's own code after several months seemed much much worse in Haskell. Haskell code is too thick, too concise, not unlike mathematics. I find it ironic that the community, apparently, values that. I bet others have had better experiences, but I definitely did not. Hanging around with Haskell clearly taught me many good things about program design, but I don't foresee myself wanting to ever write anything on the platform ever again.
papsosouid 14y ago
>Please, please, don't poison your career on focusing on a single language My career is likely older than you, I think it'll survive the horrors of using a good language. I've been running production web sites on haskell for a year so far, and it has been great.
- dscrd 14y ago
  "My career is likely older than you" Your career spans over 30 years? If so, I applaud you and of course withhold my rights to criticize your choices without knowing more details.