5 ms·

I feel like some of the criticism is unwarranted, specifically: > The tooling is bad I feel like the tooling is really impressive, considering the age of the

by joaodlf 10y ago

I feel like some of the criticism is unwarranted, specifically: > The tooling is bad 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. > Zero values are almost never what you want I've always felt the defaults to be spot on. Anyway, it's my responsibility to initialise these values, even on struct fields. > A culture of “backwards compatibility at all costs” I agree the current (package management) landscape is dire, but this should change, hopefully this year, with godep. As it is now, I have found success using glide for dependency management, so that's what I would recommend for now. Apart from that, I can agree on a lot of things - I'm specifically annoyed by the whole generics thing, the way I interpret the people involved with the project is "it would be nice to have, but the implementation is awkward, so we won't admit to it being nice to have".

AsyncAwait 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.
  - 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
gribbly 10y ago
>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 https://research.swtch.com/go2017#generics
icebraining 10y ago
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.
- raulk 10y ago
  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.
  - icebraining 10y ago
    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.
    - raulk 10y ago
      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.
      - icebraining 10y ago

by joaodlf 10y ago

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

gribbly 10y ago

>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 https://research.swtch.com/go2017#generics

icebraining 10y ago

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.

raulk 10y ago
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.
- icebraining 10y ago
  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.
  - raulk 10y ago
    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.
    - icebraining 10y ago