3 ms·

>Go is going to look hideous to you because you're probably expecting functional things like list comprehensions Nah, list comprehensions are just syntactic su

>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.
    - papsosouid 14y ago
      I would definitely start with learn you a haskell. It makes a much better introduction to the language than RWH. RWH is great when you have learned the basics and want to start tackling bigger problems. Xmonad is a pretty common recommendation for looking at "good haskell code", in particular the overall design and how they keep the IO part minimized and isolated so the bulk of the application is easier to unit test. I think the standard libraries the come with GHC are good examples too.
    - gtani 14y ago
      There's lots of books: Hutton, Hudak, Thompson, Richard Bird. I have a ugly draft/link dump for learning http://isthishaskell.blogspot.com/2013/02/tips-on-learning.html http://isthishaskell.blogspot.com/2013/02/tips-on-learning.h...

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.
  - papsosouid 14y ago
    I would definitely start with learn you a haskell. It makes a much better introduction to the language than RWH. RWH is great when you have learned the basics and want to start tackling bigger problems. Xmonad is a pretty common recommendation for looking at "good haskell code", in particular the overall design and how they keep the IO part minimized and isolated so the bulk of the application is easier to unit test. I think the standard libraries the come with GHC are good examples too.
  - gtani 14y ago
    There's lots of books: Hutton, Hudak, Thompson, Richard Bird. I have a ugly draft/link dump for learning http://isthishaskell.blogspot.com/2013/02/tips-on-learning.html http://isthishaskell.blogspot.com/2013/02/tips-on-learning.h...