6 ms·

Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.

by Peaker 14y ago

Tyr42 14y ago
Wait, even "Go comes with a complete set of documentation available from the command line". I use hoogle from the command line, is there anything else for Haskell?
- Peaker 14y ago
  Hoogle type search is great: Give a type, get back names implementing that type or a generalization of it. There's the haddock auto-generated documentation from cabal (if you enable it). Not sure if that qualifies for "available from the command line".
jerf 14y ago
Having used both a bit (Haskell substantially, still fiddling with Go), there's no "might" about it. But then, "Go compiles quickly" was an explicit design goal from day one. "GHC compiles quickly" is certainly much further down on the list of GHC design goals. Otherwise, Go & Haskell are very different languages. In the grand CLispScript landscape, Go is sort of close to Haskell because of the interface/typeclass similarity, but pushed apart by the fact that Go's strong type system has some serious weak points in it by Haskell standards, for instance, there's no equivalent to a TChan a -> TChan a function as there is no way to have a function that is ignorant of "a" but can pass it through as the same type. Go forces it to collapse to interface{}, which is roughly equivalent to Data.Dynamic in Haskell. (If you want to search for it, Go calls it's equivalent to Data.Dynamic.fromDyn a "type assertion". There's two ways to use it, one that is the rough equivalent of fromDyn in that it returns whether the conversion worked and maybe the converted value, and one mode in which it does the Data.Maybe.fromJust for you, complete with violent crashing behavior if you're wrong.)
papsosouid 14y ago
I write haskell code all day. I spend my day writing it at work (with occasional HN breaks obviously) and then I go home and write personal projects in it. I advocate haskell on a semi-regular basis. I certainly fall on the pro-haskell side of things. But GHC absolutely does not meet all those bullet points. Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies. >Go comes with a complete set of documentation available from the command line GHC does not come with command line docs. >All Go code is statically compiled so deployment is trivial GHC links in C libs dynamically, and as far as I can figure there is no way to get static linking working, so I have to have all the same C libs installed on my production servers as my build server. With go you can just upload your binary to a bare bones server and it works. >but it also has a tool to clean up code: gofmt GHC has nothing like this. >And there's also go fix which can automatically convert Go code designed for earlier versions to newer versions Or this. Haskell is a great language, but it does not match go's toolchain.
- car54whereareu 14y ago
  Actually if you import "net" go links to libc.so and some others.
  - stock_toaster 14y ago
    I believe "net" does so for native dns lookups. You can disable that by building go with 'CGO_ENABLED=0', if desired.
    - 4ad 14y ago
      That is correct. It uses libc for resolving names because systems might be configured to use NIS or LDAP before DNS. With cgo disabled it defaults to using its own DNS resolver and resolv.conf.
  - papsosouid 14y ago
    Ah, if the original bulletpoints for go are wrong then ghc may be more comparable than I figured. Can you statically link go binaries? As in, if I am using a go postgresql binding, can I build a binary with libpq (the postgresql C library) linked in statically, so it can be deployed on servers with no postgresql libraries installed?
burntsushi 14y ago
> all of his bullets apply to GHC Haskell too No chance. Using the `go` tool to install packages is at least an order of magnitude less annoying than using `cabal`.
- Peaker 14y ago
  When did you last use `cabal`? Cabal works much better now, and most of the problems were due to over-conservative version ranges combined with an over-eager reinstallation policy that overwrote packages in a breaking way. That was fixed about 6 months ago, IIRC.
  - burntsushi 14y ago
    A few weeks ago. And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools. Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.
    - Peaker 14y ago
      Well, how can it infer the dependency on particular versions? Or on particular implementations of some interface you're using?
      - burntsushi 14y ago
        It doesn't. Hence: > Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances. If you need to stick to a particular version of a software package, the common workflow involves using existing tools. (i.e., fork.)

Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.

by Peaker 14y ago

Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.

Tyr42 14y ago

Wait, even "Go comes with a complete set of documentation available from the command line". I use hoogle from the command line, is there anything else for Haskell?

Peaker 14y ago
Hoogle type search is great: Give a type, get back names implementing that type or a generalization of it. There's the haddock auto-generated documentation from cabal (if you enable it). Not sure if that qualifies for "available from the command line".

jerf 14y ago

Having used both a bit (Haskell substantially, still fiddling with Go), there's no "might" about it. But then, "Go compiles quickly" was an explicit design goal from day one. "GHC compiles quickly" is certainly much further down on the list of GHC design goals. Otherwise, Go & Haskell are very different languages. In the grand CLispScript landscape, Go is sort of close to Haskell because of the interface/typeclass similarity, but pushed apart by the fact that Go's strong type system has some serious weak points in it by Haskell standards, for instance, there's no equivalent to a TChan a -> TChan a function as there is no way to have a function that is ignorant of "a" but can pass it through as the same type. Go forces it to collapse to interface{}, which is roughly equivalent to Data.Dynamic in Haskell. (If you want to search for it, Go calls it's equivalent to Data.Dynamic.fromDyn a "type assertion". There's two ways to use it, one that is the rough equivalent of fromDyn in that it returns whether the conversion worked and maybe the converted value, and one mode in which it does the Data.Maybe.fromJust for you, complete with violent crashing behavior if you're wrong.)

papsosouid 14y ago

I write haskell code all day. I spend my day writing it at work (with occasional HN breaks obviously) and then I go home and write personal projects in it. I advocate haskell on a semi-regular basis. I certainly fall on the pro-haskell side of things. But GHC absolutely does not meet all those bullet points. Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies. >Go comes with a complete set of documentation available from the command line GHC does not come with command line docs. >All Go code is statically compiled so deployment is trivial GHC links in C libs dynamically, and as far as I can figure there is no way to get static linking working, so I have to have all the same C libs installed on my production servers as my build server. With go you can just upload your binary to a bare bones server and it works. >but it also has a tool to clean up code: gofmt GHC has nothing like this. >And there's also go fix which can automatically convert Go code designed for earlier versions to newer versions Or this. Haskell is a great language, but it does not match go's toolchain.

car54whereareu 14y ago
Actually if you import "net" go links to libc.so and some others.
- stock_toaster 14y ago
  I believe "net" does so for native dns lookups. You can disable that by building go with 'CGO_ENABLED=0', if desired.
  - 4ad 14y ago
    That is correct. It uses libc for resolving names because systems might be configured to use NIS or LDAP before DNS. With cgo disabled it defaults to using its own DNS resolver and resolv.conf.
- papsosouid 14y ago
  Ah, if the original bulletpoints for go are wrong then ghc may be more comparable than I figured. Can you statically link go binaries? As in, if I am using a go postgresql binding, can I build a binary with libpq (the postgresql C library) linked in statically, so it can be deployed on servers with no postgresql libraries installed?

burntsushi 14y ago

> all of his bullets apply to GHC Haskell too No chance. Using the `go` tool to install packages is at least an order of magnitude less annoying than using `cabal`.

Peaker 14y ago
When did you last use `cabal`? Cabal works much better now, and most of the problems were due to over-conservative version ranges combined with an over-eager reinstallation policy that overwrote packages in a breaking way. That was fixed about 6 months ago, IIRC.
- burntsushi 14y ago
  A few weeks ago. And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools. Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.
  - Peaker 14y ago
    Well, how can it infer the dependency on particular versions? Or on particular implementations of some interface you're using?
    - burntsushi 14y ago
      It doesn't. Hence: > Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances. If you need to stick to a particular version of a software package, the common workflow involves using existing tools. (i.e., fork.)