Hacker News Reader

> 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.

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

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.

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.

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.

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.

>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.

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.

Incorrect. You apparently stopped at 'that looks like a URL!' and dreamed up the rest of the implementation to fit some narrative.

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?

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

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.

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.

Vendoring is how you do dependency management with Go. Using vendoring you would also not need to change anything.

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?

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.

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.

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 :(

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.)

> Are you on NixOS by any chance?

Yes. That's the issue I alluded to with "stack filling up temp dir".

Off the top of my head, other issues include:

- Bootstrapping GHC from old versions. This tries to run a script with a non-existent `/bin/bash` shebang. A more portable version would be `/usr/bin/env bash`, but since bootstrapping relies on out-of-date versions this can't be changed. Since such paths can vary depending on the OS, the right thing to do is using what the OS provides, rather than making yet another attempt at cross-OS/distro packaging for a one-off app.

- When using "Nix integration", to try and avoid GHC bootstrap hell, the "lts" releases written in various project's "stack.yaml" files is assumed to correspond to a key in the `(import <nixpkgs> {}).haskell` attribute set. Except that a) different projects use a variety of these identifiers, which may or may not correspond to actual keys, b) nixpkgs doesn't actually contain any of these identifiers anymore https://github.com/NixOS/nixpkgs/issues/14897

>it would be nice to have, but the implementation is awkward, so we won't admit to it being nice to have".

That's not the impression I'm getting

https://research.swtch.com/go2017#generics

I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too.

That's like hiring a toddler who can do sums for an accounting position. Showing promise is good, but not the same as being good right now.

When a decent software engineer builds a project, you not only take into consideration the status quo of the technology, but also its promise, momentum and community development speed. You don't want to pick a stack with weaning manpower because you'll soon be left with legacy software in your hands. Hence, I do think that, for most serverside projects, the "promise" (as you call it) is very relevant and a true factor of decision.

Yes, but that's a red herring. Outside maybe of the JavaScript world, the available tooling isn't divided into immature and near legacy. Haskell itself is a good example of a mature language still growing in popularity.

All I'm saying is that it's unfair to discredit the argument that Haskell has been around for 25 years, hence its had more time to evolve a more complete tooling offering. It is a valid argument.

If Haskell didn't exist and had only been launched a few years ago alongside Go, what would the status of its tooling be today? That would be a fairer comparison.

Obviously one can't measure it objectively, but you do have a comparable case with Elixir, I believe. And it's clear that Go surpasses Elixir in traction.

So let's not discredit the merits of Go in such a long time. It definitely has more happening for it now than Haskell or Elixir.

This is sounding like a golang version of "Leave Britney Alone".

The author wasn't accusing the creators of Go of being incompetents and unable to produce good tools. All was said is that currently, the tooling is not as good as Haskell's. That Go is a newer language is not a valid argument for rebutting that claim - it's only an explanation for it.