5 ms·

> Remember that Haskell is something like 25+ years old. Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack t

> Remember that Haskell is something like 25+ years old. Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack thing is a mess.

pjmlp 10y ago
Yet, at least we can use proper versions instead of Git urls that are exposed in source code.
- dualogy 10y ago
  These import paths aren't really URLs. They're local import paths, where Go's out-of-box tooling additionally allows for far simpler package install/update flows when one chooses to have these local paths replicate remote-repo URL paths. One doesn't have to, but it essentially turns "any CVS" into what would be Hackage/Stackage in the Haskell world. Sure, no curation, but `go get repo-url` has its charms too for quick iterations and experimentations. Vendoring is also entirely trivial (have a fork, update it from the original when it seems sensible to do so, undo when it turns out not to be). And guess what, with that you have "reproducable builds". I like the hackage/stackage model, too. As long as there is always some folks tending to those repos. But, the `go get` model is a fine workflow too.
  - pjmlp 10y ago
    Those urls will change if upstream happens to change to another SCM provider or tooling. Whereas in any sensible package management system the package names and versions will be unaffected by such changes.
- XorNot 10y ago
  And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want. With Haskell the process for me has repeatedly been: "okay I'm going to follow this tutorial...okay I need to install it...okay cabal is complaining about versions or exceptions....okay let's try stack....okay this example needs some includes...okay I don't have quite the right ver..." Then 4 hours later I remember that I can't deploy any of this to my servers, give up, and go back to waiting for someone to make a sane "get started" bundle for an FP language. Haskell's package management might exist - but it sucks, and I'll take go get/govendor over pretty much anything currently out there.
  - NateDad 10y ago
    This is one of the things I love about go. Basically any random tool written in go I can have installed and runnable in 3 seconds from the time I know the github url. All but the largest of applications is made to be compatible with 'go get' and so most of the time it just works.
  - eptcyka 10y ago
    >And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want. You can. Today. But leave that code in a repo for a month, and it will stop compiling, because some of your dependencies got updated.
    - XorNot 10y ago
      Not any of my code (or any of the projects I know) - the solution of the vendor/ is not "smart" but it's simple and comprehensible. My dependencies are locked and explicit - if you can clone my repository, then you also get the dependencies. And no, I really don't care about wasted disk space measured in megabytes.
    - imsofuture 10y ago
      Incorrect. You apparently stopped at 'that looks like a URL!' and dreamed up the rest of the implementation to fit some narrative.
  - Chris_Newton 10y ago
    How much have you used Stack with Haskell? The kind of version-related problems you’re talking about are exactly what it’s supposed to fix, and my experience has been that it mostly Just Works, at least if you’re not trying to do something unusual like, say, cross-compiling. Have you found otherwise?
  - tel 10y ago
    To be honest there's a lot of old information out there about Haskell's packaging. Today, I just use stack and it's completely fire and forget. The default template will build you a little executable and a companion library and you can just modify it from there. stack new my-project cd my-project stack build stack test stack exec my-project-exe stack repl
- imsofuture 10y ago
  This is a fundamental misunderstanding of how go dependencies work. Dependencies are simply package names. It just happens that names are actually meaningful and tell you where you, the developer can get the package. Using vendoring and/or Godep/glide, you then strictly version and manage your dependencies. `go build` doesn't just run `git clone` or something.
  - pjmlp 10y ago
    So what is the approach when package X happens to change their Git path, change to another SCM server, or migrate the project to the next cool SCM tool? On any sensible package management system, as a user of the said package, I won't need to change anything.
    - imsofuture 10y ago
      Vendoring is how you do dependency management with Go. Using vendoring you would also not need to change anything.
      - pjmlp 10y ago
        So you vendor version a04377dfebbf79f0ff43b5da2b21b835f1495803, then by the time you decide to upgrade to version a04377dfebbf79f0ff43b5da2b21b835f1495803, the project moved from Github to Gitlab. How you upgrade with zero code changes?
dualogy 10y ago
stack isn't a mess at all, it's very well-designed, robust and stable. cabal is a mess (or say, a furball) that is properly "handled" by just using stack.
- ice109 10y ago
  Bs. tell me how to compile individual packages from a .cabal in stack? tell me how to pass configure args through stack to cabal. tell me how to get stack to install an executable that isn't just the name of the package (eg if I attach version number to the executable). these are reasonable things you can't do because stack is immature.
- chriswarbo 10y ago
  I've tried to use stack many times; I think I'm up to 5 attempts now? Each time, I've invested many hours trying to make it build; trying to make it find/fetch GHC; trying to make it find/recognise the GHC it's just downloaded; talking to others in IRC/GitHub issues/etc. for help; reading through the source code; trying to hack around brokenness (stack filling up temp dir, GHC misusing bash, etc.). Each time my patience has worn out and I've just used Cabal instead. I know that stack must work on some people's machines, and that's great for them. I don't understand at all why it's regarded as some sort of simple, works-everywhere, "end of cabal hell" thing. Haskell's infrastructure is probably its biggest pain-point; Cabal isn't great, but it's at least predictable enough and old enough to have stable, reliable workflows. Stack's approach seems to be solving problems by bundling them as yet another stack feature; that doesn't help when stack itself flat-out doesn't work :(
  - mrkgnao 10y ago
    Are you on NixOS by any chance? There is a problem with /run filling up that you can fix by using TMPDIR=/tmp stack whatever I switched back to Arch a while back, and I'm not sure if this problem still exists on the NixOS side. (Of course, you can always choose a bigger /run size in configuration.nix.)
    - chriswarbo 10y ago

> Remember that Haskell is something like 25+ years old. Yet, I'd argue that tooling is still one of the worst aspects of the language. The whole cabal/stack thing is a mess.

pjmlp 10y ago

Yet, at least we can use proper versions instead of Git urls that are exposed in source code.

dualogy 10y ago
These import paths aren't really URLs. They're local import paths, where Go's out-of-box tooling additionally allows for far simpler package install/update flows when one chooses to have these local paths replicate remote-repo URL paths. One doesn't have to, but it essentially turns "any CVS" into what would be Hackage/Stackage in the Haskell world. Sure, no curation, but `go get repo-url` has its charms too for quick iterations and experimentations. Vendoring is also entirely trivial (have a fork, update it from the original when it seems sensible to do so, undo when it turns out not to be). And guess what, with that you have "reproducable builds". I like the hackage/stackage model, too. As long as there is always some folks tending to those repos. But, the `go get` model is a fine workflow too.
- pjmlp 10y ago
  Those urls will change if upstream happens to change to another SCM provider or tooling. Whereas in any sensible package management system the package names and versions will be unaffected by such changes.
XorNot 10y ago
And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want. With Haskell the process for me has repeatedly been: "okay I'm going to follow this tutorial...okay I need to install it...okay cabal is complaining about versions or exceptions....okay let's try stack....okay this example needs some includes...okay I don't have quite the right ver..." Then 4 hours later I remember that I can't deploy any of this to my servers, give up, and go back to waiting for someone to make a sane "get started" bundle for an FP language. Haskell's package management might exist - but it sucks, and I'll take go get/govendor over pretty much anything currently out there.
- NateDad 10y ago
  This is one of the things I love about go. Basically any random tool written in go I can have installed and runnable in 3 seconds from the time I know the github url. All but the largest of applications is made to be compatible with 'go get' and so most of the time it just works.
- eptcyka 10y ago
  >And yet I can be up and running and compiling with Go faster then Haskell every time, ready to ship production binaries if I want. You can. Today. But leave that code in a repo for a month, and it will stop compiling, because some of your dependencies got updated.
  - XorNot 10y ago
    Not any of my code (or any of the projects I know) - the solution of the vendor/ is not "smart" but it's simple and comprehensible. My dependencies are locked and explicit - if you can clone my repository, then you also get the dependencies. And no, I really don't care about wasted disk space measured in megabytes.
  - imsofuture 10y ago
    Incorrect. You apparently stopped at 'that looks like a URL!' and dreamed up the rest of the implementation to fit some narrative.
- Chris_Newton 10y ago
  How much have you used Stack with Haskell? The kind of version-related problems you’re talking about are exactly what it’s supposed to fix, and my experience has been that it mostly Just Works, at least if you’re not trying to do something unusual like, say, cross-compiling. Have you found otherwise?
- tel 10y ago
  To be honest there's a lot of old information out there about Haskell's packaging. Today, I just use stack and it's completely fire and forget. The default template will build you a little executable and a companion library and you can just modify it from there. stack new my-project cd my-project stack build stack test stack exec my-project-exe stack repl
imsofuture 10y ago
This is a fundamental misunderstanding of how go dependencies work. Dependencies are simply package names. It just happens that names are actually meaningful and tell you where you, the developer can get the package. Using vendoring and/or Godep/glide, you then strictly version and manage your dependencies. `go build` doesn't just run `git clone` or something.
- pjmlp 10y ago
  So what is the approach when package X happens to change their Git path, change to another SCM server, or migrate the project to the next cool SCM tool? On any sensible package management system, as a user of the said package, I won't need to change anything.
  - imsofuture 10y ago
    Vendoring is how you do dependency management with Go. Using vendoring you would also not need to change anything.
    - pjmlp 10y ago
      So you vendor version a04377dfebbf79f0ff43b5da2b21b835f1495803, then by the time you decide to upgrade to version a04377dfebbf79f0ff43b5da2b21b835f1495803, the project moved from Github to Gitlab. How you upgrade with zero code changes?

dualogy 10y ago

stack isn't a mess at all, it's very well-designed, robust and stable. cabal is a mess (or say, a furball) that is properly "handled" by just using stack.

ice109 10y ago
Bs. tell me how to compile individual packages from a .cabal in stack? tell me how to pass configure args through stack to cabal. tell me how to get stack to install an executable that isn't just the name of the package (eg if I attach version number to the executable). these are reasonable things you can't do because stack is immature.
chriswarbo 10y ago
I've tried to use stack many times; I think I'm up to 5 attempts now? Each time, I've invested many hours trying to make it build; trying to make it find/fetch GHC; trying to make it find/recognise the GHC it's just downloaded; talking to others in IRC/GitHub issues/etc. for help; reading through the source code; trying to hack around brokenness (stack filling up temp dir, GHC misusing bash, etc.). Each time my patience has worn out and I've just used Cabal instead. I know that stack must work on some people's machines, and that's great for them. I don't understand at all why it's regarded as some sort of simple, works-everywhere, "end of cabal hell" thing. Haskell's infrastructure is probably its biggest pain-point; Cabal isn't great, but it's at least predictable enough and old enough to have stable, reliable workflows. Stack's approach seems to be solving problems by bundling them as yet another stack feature; that doesn't help when stack itself flat-out doesn't work :(
- mrkgnao 10y ago
  Are you on NixOS by any chance? There is a problem with /run filling up that you can fix by using TMPDIR=/tmp stack whatever I switched back to Arch a while back, and I'm not sure if this problem still exists on the NixOS side. (Of course, you can always choose a bigger /run size in configuration.nix.)
  - chriswarbo 10y ago