13 ms·

Three Months of Go from a Haskeller’s perspective (2016)

177 points by amzans 6y ago

mappu 6y ago
(2016) The versioning and slice sorting have since been solved, by go.mod and sort.Slice respectively. The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields.
- throw_m239339 6y ago
  Still no official debugger though. Delve is just full of bugs.
  - justasitsounds 6y ago
    Just do as the Head of Marketing from previousEmployer suggested and "leave out the bugs"
    - lostcolony 6y ago
      Revolutionary thinking right there
    - redis_mlc 6y ago
      That's next-level. Was he being ironic, or serious? Love to hear more.
      - AnimalMuppet 6y ago
        "Head of Marketing". He was probably serious.
  - peter_l_downs 6y ago
    delve (through vscode-go) has worked fine from my perspective
- lmm 6y ago
  > The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields. If you allow the struct definition to specify a default value then the struct author can set default in the cases where there is a sensible default, and leave it compile-time incompatible in the cases where there really is no good default and the person doing the upgrade needs to make a decision.
  - Cthulhu_ 6y ago
    That is already possible by exposing a `New` function and making the struct itself unexposed; are you suggesting syntax should be added to provide default values to struct fields? Because there is high resistance (which I agree with btw) to adding additional syntax and constructs to the language.
    - lmm 6y ago
      > That is already possible by exposing a `New` function and making the struct itself unexposed; I thought Go didn't allow functions with default argument values either?
thatswrong0 6y ago
I actually wish gofmt was _more_ opinionated. Break my lines please. Prettier has spoiled me - write absolutely hideous looking code, and one save later it is exactly what I want almost every time.
- corytheboyd 6y ago
  I was very apprehensive about prettier at first, but I pulled it into a side project of mine and I am never looking back. I absolutely loathe people’s obsession over formatting code. Just let a formatter do it, don’t fuck with the defaults, and work on your business logic instead of bike shedding on perfectly placed spaces.
  - jonahx 6y ago
    Totally agree, but you need an iron-fisted formatter to make that work. Because otherwise you get an ever-changing quilt of every dev's style du jour, and while I don't think the specific formatting you use matters, I think sloppiness and inconsistency are actually harmful.
- sneak 6y ago
  https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt Drop in replacement for `go fmt` and probably does most of what you want.
  - skavi 6y ago
    > Running gofmt after gofumpt should be a no-op. This looks perfect actually.
  - Cthulhu_ 6y ago
    Thanks! I noticed the other day I was doing some manual formatting (putting short struct initializers on a single line), and the newlines mentioned as well.
wwarner 6y ago
I've been using generics with go2go and am looking forward to replacing generated code when they are officially released.
- gonzo41 6y ago
  Serious question, I've been toying about with Go but aside from having to recently write a tree for myself, what are you using generics for? One of the things I really lean into with go is that your program tightly fits your problem. Where's your generic limitation?
  - dmitriid 6y ago
    Libraries and library-like code. Any code that fetches data from generic storage/protocols. Prime examples: - http requests. For an API it's almost always a generic request parametrized by some type. For example, you API always returns `{result: ...some data..., nextPageToken: ...}`. Well, that's a `PagedResponse<...the type of data...>` - cache Caches store objects. In go any `.get` from a cache will return an `interface{}` that you have to type-assert because you can't do a `Cache<T>`. and so on.
    - Cthulhu_ 6y ago
      Re: HTTP requests, you mean the exact HTTP response, which in your case is a JSON object that can be parsed via a different package; the two should not be conflated, and the HTTP package should not be polluted with assumptions about what (if any) data is being passed. Re: caches, what kinda caches do you mean? For the most simple use case you have maps, which in Go are already generic. Of course, anything more advanced would be greatly helped with generics, since at the moment they (I presume) store `interface{}` types and the consumer has to cast them back to the real types. Or they use code generators, which is also pointed out in the article. To add some potential goodness coming from generics: Option types to avoid nil, Either types to replace the value/error tuples (which the article points out is a weird outlier, because you don't have tuples elsewhere in the language). Those make me wonder if parts of the language and codebases written therein would actually improve compared to the weirdness of multiple return values and the like.
kjksf 6y ago
Apparently, the author of this blog post had a change of heart: https://memo.barrucadu.co.uk/blub-crisis.html https://memo.barrucadu.co.uk/blub-crisis.html > I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are obviously too limited to get any real work done in, and languages with more advanced features than Haskell (like dependent types) are really just weird and not actually solving a problem I would ever face. > The arrogance! Such a know-it-all! > I have decided to call such a realisation a “Blub Crisis”. Haskell is my Blub. The only solution is to become proficient—actually proficient—in a different language, and once again learn a new way of thinking.
- jonahx 6y ago
  I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.
  - panpanna 6y ago
    It did to me. He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code). This is not how you approach new things
    - eptcyka 6y ago
      That is a single dubious point amongst some serious and in my opinion legitimate issues with the language.
      - scottlocklin 6y ago
        Complaining about strict evaluation, the std lib not doing what he wants it to, the type system, the lack of heap profiler/threadscape, and .... demanding Golang handle zero values in his preferred way is basically him whining it ain't Haskell. I could blubber about it not having power conjunctions or self intervals or whatever if I wanted Golang to be J, which would be a similarly moronic roster of complaints. In reality golang is a basket of compromises like any other programming language. There's vastly more good stuff built in it than Haskell, despite Haskell being older and more theoretically amazing, so they must be doing something right. His only criticism that resonated with me was go get defaulting to head, which befuddled me when I first saw it, but that's a compromise too; one oriented to the large codebases that golang is designed for. It's actually a pretty good compromise compared to the propeller head Haskell dork "Things break backwards compatibility in Haskell, and the users just update their code because they know the library author did it for a reason." -aka this appears to be a statement from an academic wanker who obviously never had to ship on a timeline in his entire fucking life.
Thaxll 6y ago
This is from 2016 and it's not accurate, especially about toolings.
- santamarias 6y ago
  I did not realize, thanks. The year of publishing should be quoted in the link title?
- garethrowlands 6y ago
  Things have moved on in the Handel world too, especially around garbage collection.
demux 6y ago
Nothing about concurrency??
- WJW 6y ago
  The concurrency models of Haskell and Go are very similar, so it's possible that nothing stood out in particular.
TeeWEE 6y ago
Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is build for readability, not for writing code fast and elegantly... Often short dense code with complex types is just really hard to read for your overage joe programmer. We're not all computer scientists here. Go is designed to write maintainable server side programs that can utilize concurrency in computer these days. Therefore they left out generics... I hope its coming. I do wish error handling and generics where part of the language... And a tuple type indeed.
- cies 6y ago
  > I do wish error handling and generics where part of the language... And a tuple type indeed. On top of that I wish `null` wasn't and sum types + pattern matching were (and were used for error handling).
- lmm 6y ago
  > Often short dense code with complex types is just really hard to read for your overage joe programmer. I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality. There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack Scala for. It took time and effort to understand what they did. But they were still a lot more maintainable than a 200 line class.
  - mrmonkeyman 6y ago
    There is a middle way here. 4 terse lines still sucks. Make it 10-15 readable lines please.
- greyman 6y ago
  I agree with the first sentence, and that I found is one of the strongest points of Go. That you can look at your colleague code and be almost sure what it does, there just aren't hidden traps or clever hacks. It's always the same "dull" code, telling you in plain language what is happening.
revskill 6y ago
Go is like SQL, where it's pragmatic for TEAM work, where your teammate has little background on programming, because Go code is easy to follow, extend (copy and paste and modify). In my case, my team is composed of most of DBA experts, they have no problem following Golang code. So your programming languages of choice should base on your team.
- shaan7 6y ago
  > So your programming languages of choice should base on your team. While that is a good thing to keep in mind when making tech decisions, make sure not tunnel vision only on it. More about that here https://news.ycombinator.com/item?id=24880273 https://news.ycombinator.com/item?id=24880273
  - joseluisq 6y ago
    Yeah, especially when there are not only preferences in between but also other strong reasons to help the team to decide to pick one or another language for the job(s). I would like to use Go, Haskell, Rust or whatever that I like (or my team as well) but this is just one piece of the whole cake IMO.
nickcw 6y ago
> In Go, you import packages by URL. If the URL points to, say, GitHub, then go get downloads HEAD of master and uses that. There is no way to specify a version, unless you have separate URLs for each version of your library. Go modules has solved this problem. I find that in practice Go modules work very well. Certainly better than the alternatives and I've been through most of them. Incrementing the major version of your module is very clunky though.
- tankenmate 6y ago
  The OP is from 2016
  - earthboundkid 6y ago
    @dang, can you fix the title?
- Cthulhu_ 6y ago
  I don't believe the problem is fully solved yet with modules (there's still the V1/V2 problem), but it's a step in the right direction. I've been using modules in my current project (new codebase) since the start of the year and so far have run into no problems whatsoever when it comes to modules. Mind you, a big plus, I think, is that Go doesn't have the ridiculous library ecosystem that others I've worked with (JS/Node, Java) have; I only use a handful of libraries at the moment (for REST api, .env file handling, database interaction and logging, and some additional ones for development like mocking, neat diffs for tests, and code generation (xsd & swagger to code).
  - nikon 6y ago
    > Mind you, a big plus, I think, is that Go doesn't have the ridiculous library ecosystem that others I've worked with (JS/Node, Java) have; I only use a handful of libraries at the moment (for REST api, .env file handling, database interaction and logging, and some additional ones for development like mocking, neat diffs for tests, and code generation (xsd & swagger to code). I think this is a great selling point. Probably due to the stdlib being so extensive.
agnivade 6y ago
> when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; That's it. A large majority of the people don't think on those terms. Go tries to be pragmatic and hit a decent balance between productivity and language features.
eznzt 6y ago
>The way in Go to handle possibly-failing functions is to have multiple return values: an actual result, and an error. If the error is nil, then the actual result is sensible; otherwise the actual result is meaningless. This means you can forget to check the error and use a bogus result and, because there are no compiler warnings (another wtf), you will know nothing of this until things fail at runtime. ? You can't forget to check the error because not checking err is a compiler error unless you forcibly mute it by using _
- Cthulhu_ 6y ago
  While you're correct, you can still avoid handling an error and not get any feedback from the compiler or linters by doing something like: val, err := something() val2, err := somethingElse() if err != nil // etc You can - and all the examples usually do - reuse and shadow an 'err' variable, and tooling won't complain as long as something is done with it at least once. If Go wants to enforce not ignoring errors, it still has a few holes like this to fix.
  - eznzt 6y ago
    I see now. That is indeed one of the things I hated about Go, having to reuse err (or maybe, making the mistake of reusing err) several times in a single function.
pdimitar 6y ago
While the author has a very Haskell-centric view and his comparison is a bit biased, I completely relate with some of his points. "Use it more" is not an answer. If you have found a good way to produce software and it has served you well -- even better if you had other ways in the past and your latest one is objectively better! -- then you are not under any obligation to "give it a chance". Many people longed for certain ways of doing things and one day they found the tools that enable them. That's quite fine. No need to insert platitudes in there which can't ever be satisfied (like "use it more", especially if you are not inclined to).
idoubtit 6y ago
Other comments have claimed that Go is intended for teams, but my personal experience shows that Go code is easier to maintain than Haskell code, even for a single developer. Though I've coded with Haskell for many years, I never reached an expert level. So, when I went back to an application after 6 month of break, my Haskell skills were rusty, and I struggled to understand what I had written. What's that pragma `MultiParamTypeClasses, TypeFamilies`? What does `<*>` mean in that context? And so on. A similar break happened last year, and I still had a hard time getting back to fluent Haskell, while modifying my Go code was still easy. Still, I agree with some of the bad points. Like him, I would have liked more types with a stricter compiler that helps refactoring (sum types, zero values). The official documentation of the language is also very disappointing, as noted by Eric S. Raymond in his conversion notes[^1] from Python to Go. The author of this blog post criticizes the tooling for the lacks of features that in fact do exist[^2], but are hard to find due to the poor documentation (split over a a shallow "tour of Go", blogs, other official docs, with no links between them). [^1]: https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc [^2]: https://golang.org/pkg/runtime/trace/ https://golang.org/pkg/runtime/trace/
- mhh__ 6y ago
  I think comparing Go to Haskell at all is slightly bizarre, really. When I think Haskell, enterprise maintainability coding isn't exactly what comes to mind. I really don't like Go, but I won't deny that it basically does what it's supposed to do.
  - codygman 6y ago
    > When I think Haskell, enterprise maintainability coding isn't exactly what comes to mind. One day hopefully
anentropic 6y ago
Is the stuff about GHC's garbage collector still valid? (I have no idea, but I found this https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ "Low-latency garbage collector merged for GHC 8.10", which is more recent than the OP blog post) Is the “backwards compatibility at all costs” point about Go still valid? https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules ...it seems like you can specify versioned deps now
jeromenerf 6y ago
Go was designed for teams and by a very opinionated designer, Rob Pike, regarding both the language features and the programming experience (tooling, etc), akin to acme/plan9. I do enjoy this experience. Very text oriented. It’s subjective. And it has served me well.
pikzel 6y ago
I really agree with some points. In my project, we moved from Java/Spring because it was just too much magic happening behind the scenes. We wanted something that was just clear and straight to the point. We should be able to read the code and it should do exactly that, not something else because you annotated the class. I just wish it wasn't so bloated with error handling. It's difficult to see the actual code among all the if err != nil (even though GoLand does a pretty good job at hiding them). Something like this? f := os.Open("file") or { return err } After a couple of years with Scala, I'm also really missing proper FP, pattern matching, optional types, immutability, etc. Still, I'm pretty happy with Go and it has made me more excited about coding again.
carapace 6y ago
> whereas Python’s significant whitespace (which is there for exactly the same reason: enforcing readable code) has been much more contentious across the programming community. Because with gofmt there's nothing to argue about, it is what it is. With Python’s significant whitespace there was plenty of rope to play tug-o-war with: tabs or spaces? How many? That was enough to fuel the flame wars.

177 points by amzans 6y ago

(2016) The versioning and slice sorting have since been solved, by go.mod and sort.Slice respectively. The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields.

throw_m239339 6y ago
Still no official debugger though. Delve is just full of bugs.
- justasitsounds 6y ago
  Just do as the Head of Marketing from previousEmployer suggested and "leave out the bugs"
  - lostcolony 6y ago
    Revolutionary thinking right there
  - redis_mlc 6y ago
    That's next-level. Was he being ironic, or serious? Love to hear more.
    - AnimalMuppet 6y ago
      "Head of Marketing". He was probably serious.
- peter_l_downs 6y ago
  delve (through vscode-go) has worked fine from my perspective
lmm 6y ago
> The problem with "Make it an error to not initialise a struct field" is you lose source compatibility when adding new struct fields. If you allow the struct definition to specify a default value then the struct author can set default in the cases where there is a sensible default, and leave it compile-time incompatible in the cases where there really is no good default and the person doing the upgrade needs to make a decision.
- Cthulhu_ 6y ago
  That is already possible by exposing a `New` function and making the struct itself unexposed; are you suggesting syntax should be added to provide default values to struct fields? Because there is high resistance (which I agree with btw) to adding additional syntax and constructs to the language.
  - lmm 6y ago
    > That is already possible by exposing a `New` function and making the struct itself unexposed; I thought Go didn't allow functions with default argument values either?

thatswrong0 6y ago

I actually wish gofmt was _more_ opinionated. Break my lines please. Prettier has spoiled me - write absolutely hideous looking code, and one save later it is exactly what I want almost every time.

corytheboyd 6y ago
I was very apprehensive about prettier at first, but I pulled it into a side project of mine and I am never looking back. I absolutely loathe people’s obsession over formatting code. Just let a formatter do it, don’t fuck with the defaults, and work on your business logic instead of bike shedding on perfectly placed spaces.
- jonahx 6y ago
  Totally agree, but you need an iron-fisted formatter to make that work. Because otherwise you get an ever-changing quilt of every dev's style du jour, and while I don't think the specific formatting you use matters, I think sloppiness and inconsistency are actually harmful.
sneak 6y ago
https://github.com/mvdan/gofumpt https://github.com/mvdan/gofumpt Drop in replacement for `go fmt` and probably does most of what you want.
- skavi 6y ago
  > Running gofmt after gofumpt should be a no-op. This looks perfect actually.
- Cthulhu_ 6y ago
  Thanks! I noticed the other day I was doing some manual formatting (putting short struct initializers on a single line), and the newlines mentioned as well.

wwarner 6y ago

I've been using generics with go2go and am looking forward to replacing generated code when they are officially released.

gonzo41 6y ago
Serious question, I've been toying about with Go but aside from having to recently write a tree for myself, what are you using generics for? One of the things I really lean into with go is that your program tightly fits your problem. Where's your generic limitation?
- dmitriid 6y ago
  Libraries and library-like code. Any code that fetches data from generic storage/protocols. Prime examples: - http requests. For an API it's almost always a generic request parametrized by some type. For example, you API always returns `{result: ...some data..., nextPageToken: ...}`. Well, that's a `PagedResponse<...the type of data...>` - cache Caches store objects. In go any `.get` from a cache will return an `interface{}` that you have to type-assert because you can't do a `Cache<T>`. and so on.
  - Cthulhu_ 6y ago
    Re: HTTP requests, you mean the exact HTTP response, which in your case is a JSON object that can be parsed via a different package; the two should not be conflated, and the HTTP package should not be polluted with assumptions about what (if any) data is being passed. Re: caches, what kinda caches do you mean? For the most simple use case you have maps, which in Go are already generic. Of course, anything more advanced would be greatly helped with generics, since at the moment they (I presume) store `interface{}` types and the consumer has to cast them back to the real types. Or they use code generators, which is also pointed out in the article. To add some potential goodness coming from generics: Option types to avoid nil, Either types to replace the value/error tuples (which the article points out is a weird outlier, because you don't have tuples elsewhere in the language). Those make me wonder if parts of the language and codebases written therein would actually improve compared to the weirdness of multiple return values and the like.

kjksf 6y ago

Apparently, the author of this blog post had a change of heart: https://memo.barrucadu.co.uk/blub-crisis.html https://memo.barrucadu.co.uk/blub-crisis.html > I have realised in recent conversations about programming languages, and in reflection of my very negative and kind of arrogant blog post about Go, that I have become trapped by the Blub Paradox. I have become dismissive of non-Haskell languages. I think in Haskell. Languages less powerful than Haskell are obviously too limited to get any real work done in, and languages with more advanced features than Haskell (like dependent types) are really just weird and not actually solving a problem I would ever face. > The arrogance! Such a know-it-all! > I have decided to call such a realisation a “Blub Crisis”. Haskell is my Blub. The only solution is to become proficient—actually proficient—in a different language, and once again learn a new way of thinking.

jonahx 6y ago
I thought the criticisms and praise, and the article's Good/Neutral/Bad structure, were fair and thoughtful on balance. It didn't read as arrogant to me.
- panpanna 6y ago
  It did to me. He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code). This is not how you approach new things
  - eptcyka 6y ago
    That is a single dubious point amongst some serious and in my opinion legitimate issues with the language.
    - scottlocklin 6y ago
      Complaining about strict evaluation, the std lib not doing what he wants it to, the type system, the lack of heap profiler/threadscape, and .... demanding Golang handle zero values in his preferred way is basically him whining it ain't Haskell. I could blubber about it not having power conjunctions or self intervals or whatever if I wanted Golang to be J, which would be a similarly moronic roster of complaints. In reality golang is a basket of compromises like any other programming language. There's vastly more good stuff built in it than Haskell, despite Haskell being older and more theoretically amazing, so they must be doing something right. His only criticism that resonated with me was go get defaulting to head, which befuddled me when I first saw it, but that's a compromise too; one oriented to the large codebases that golang is designed for. It's actually a pretty good compromise compared to the propeller head Haskell dork "Things break backwards compatibility in Haskell, and the users just update their code because they know the library author did it for a reason." -aka this appears to be a statement from an academic wanker who obviously never had to ship on a timeline in his entire fucking life.

Thaxll 6y ago

This is from 2016 and it's not accurate, especially about toolings.

santamarias 6y ago
I did not realize, thanks. The year of publishing should be quoted in the link title?
garethrowlands 6y ago
Things have moved on in the Handel world too, especially around garbage collection.

demux 6y ago

Nothing about concurrency??

WJW 6y ago
The concurrency models of Haskell and Go are very similar, so it's possible that nothing stood out in particular.

TeeWEE 6y ago

Go is a programming language for teams, not primarily designed to impress individual programmers... I agree with all points with the author. But working in teams, or even mutiple teams on the same software, then go solves a lot of problems for you.. Yeah its a dumb language, missing a lot of features. But there is only 1 way to program, dependency management is sane (no circular dependencies), and the language is build for readability, not for writing code fast and elegantly... Often short dense code with complex types is just really hard to read for your overage joe programmer. We're not all computer scientists here. Go is designed to write maintainable server side programs that can utilize concurrency in computer these days. Therefore they left out generics... I hope its coming. I do wish error handling and generics where part of the language... And a tuple type indeed.

cies 6y ago
> I do wish error handling and generics where part of the language... And a tuple type indeed. On top of that I wish `null` wasn't and sum types + pattern matching were (and were used for error handling).
lmm 6y ago
> Often short dense code with complex types is just really hard to read for your overage joe programmer. I think people make the mistake of measuring how long it takes you to read x lines, when really you need to measure how long it takes to read x functionality. There've been times when I replaced a 200 line class with 4 lines of Scala. Those lines were very much the kind of complexly-typed code that people attack Scala for. It took time and effort to understand what they did. But they were still a lot more maintainable than a 200 line class.
- mrmonkeyman 6y ago
  There is a middle way here. 4 terse lines still sucks. Make it 10-15 readable lines please.
greyman 6y ago
I agree with the first sentence, and that I found is one of the strongest points of Go. That you can look at your colleague code and be almost sure what it does, there just aren't hidden traps or clever hacks. It's always the same "dull" code, telling you in plain language what is happening.

revskill 6y ago

Go is like SQL, where it's pragmatic for TEAM work, where your teammate has little background on programming, because Go code is easy to follow, extend (copy and paste and modify). In my case, my team is composed of most of DBA experts, they have no problem following Golang code. So your programming languages of choice should base on your team.

shaan7 6y ago
> So your programming languages of choice should base on your team. While that is a good thing to keep in mind when making tech decisions, make sure not tunnel vision only on it. More about that here https://news.ycombinator.com/item?id=24880273 https://news.ycombinator.com/item?id=24880273
- joseluisq 6y ago
  Yeah, especially when there are not only preferences in between but also other strong reasons to help the team to decide to pick one or another language for the job(s). I would like to use Go, Haskell, Rust or whatever that I like (or my team as well) but this is just one piece of the whole cake IMO.

nickcw 6y ago

> In Go, you import packages by URL. If the URL points to, say, GitHub, then go get downloads HEAD of master and uses that. There is no way to specify a version, unless you have separate URLs for each version of your library. Go modules has solved this problem. I find that in practice Go modules work very well. Certainly better than the alternatives and I've been through most of them. Incrementing the major version of your module is very clunky though.

tankenmate 6y ago
The OP is from 2016
- earthboundkid 6y ago
  @dang, can you fix the title?
Cthulhu_ 6y ago
I don't believe the problem is fully solved yet with modules (there's still the V1/V2 problem), but it's a step in the right direction. I've been using modules in my current project (new codebase) since the start of the year and so far have run into no problems whatsoever when it comes to modules. Mind you, a big plus, I think, is that Go doesn't have the ridiculous library ecosystem that others I've worked with (JS/Node, Java) have; I only use a handful of libraries at the moment (for REST api, .env file handling, database interaction and logging, and some additional ones for development like mocking, neat diffs for tests, and code generation (xsd & swagger to code).
- nikon 6y ago
  > Mind you, a big plus, I think, is that Go doesn't have the ridiculous library ecosystem that others I've worked with (JS/Node, Java) have; I only use a handful of libraries at the moment (for REST api, .env file handling, database interaction and logging, and some additional ones for development like mocking, neat diffs for tests, and code generation (xsd & swagger to code). I think this is a great selling point. Probably due to the stdlib being so extensive.

agnivade 6y ago

> when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; That's it. A large majority of the people don't think on those terms. Go tries to be pragmatic and hit a decent balance between productivity and language features.

eznzt 6y ago

>The way in Go to handle possibly-failing functions is to have multiple return values: an actual result, and an error. If the error is nil, then the actual result is sensible; otherwise the actual result is meaningless. This means you can forget to check the error and use a bogus result and, because there are no compiler warnings (another wtf), you will know nothing of this until things fail at runtime. ? You can't forget to check the error because not checking err is a compiler error unless you forcibly mute it by using _

Cthulhu_ 6y ago
While you're correct, you can still avoid handling an error and not get any feedback from the compiler or linters by doing something like: val, err := something() val2, err := somethingElse() if err != nil // etc You can - and all the examples usually do - reuse and shadow an 'err' variable, and tooling won't complain as long as something is done with it at least once. If Go wants to enforce not ignoring errors, it still has a few holes like this to fix.
- eznzt 6y ago
  I see now. That is indeed one of the things I hated about Go, having to reuse err (or maybe, making the mistake of reusing err) several times in a single function.

pdimitar 6y ago

While the author has a very Haskell-centric view and his comparison is a bit biased, I completely relate with some of his points. "Use it more" is not an answer. If you have found a good way to produce software and it has served you well -- even better if you had other ways in the past and your latest one is objectively better! -- then you are not under any obligation to "give it a chance". Many people longed for certain ways of doing things and one day they found the tools that enable them. That's quite fine. No need to insert platitudes in there which can't ever be satisfied (like "use it more", especially if you are not inclined to).

idoubtit 6y ago

Other comments have claimed that Go is intended for teams, but my personal experience shows that Go code is easier to maintain than Haskell code, even for a single developer. Though I've coded with Haskell for many years, I never reached an expert level. So, when I went back to an application after 6 month of break, my Haskell skills were rusty, and I struggled to understand what I had written. What's that pragma `MultiParamTypeClasses, TypeFamilies`? What does `<*>` mean in that context? And so on. A similar break happened last year, and I still had a hard time getting back to fluent Haskell, while modifying my Go code was still easy. Still, I agree with some of the bad points. Like him, I would have liked more types with a stricter compiler that helps refactoring (sum types, zero values). The official documentation of the language is also very disappointing, as noted by Eric S. Raymond in his conversion notes[^1] from Python to Go. The author of this blog post criticizes the tooling for the lacks of features that in fact do exist[^2], but are hard to find due to the poor documentation (split over a a shallow "tour of Go", blogs, other official docs, with no links between them). [^1]: https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/blob/master/GoNotes.adoc [^2]: https://golang.org/pkg/runtime/trace/ https://golang.org/pkg/runtime/trace/

mhh__ 6y ago
I think comparing Go to Haskell at all is slightly bizarre, really. When I think Haskell, enterprise maintainability coding isn't exactly what comes to mind. I really don't like Go, but I won't deny that it basically does what it's supposed to do.
- codygman 6y ago
  > When I think Haskell, enterprise maintainability coding isn't exactly what comes to mind. One day hopefully

anentropic 6y ago

Is the stuff about GHC's garbage collector still valid? (I have no idea, but I found this https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/ "Low-latency garbage collector merged for GHC 8.10", which is more recent than the OP blog post) Is the “backwards compatibility at all costs” point about Go still valid? https://blog.golang.org/using-go-modules https://blog.golang.org/using-go-modules ...it seems like you can specify versioned deps now

jeromenerf 6y ago

Go was designed for teams and by a very opinionated designer, Rob Pike, regarding both the language features and the programming experience (tooling, etc), akin to acme/plan9. I do enjoy this experience. Very text oriented. It’s subjective. And it has served me well.

pikzel 6y ago

I really agree with some points. In my project, we moved from Java/Spring because it was just too much magic happening behind the scenes. We wanted something that was just clear and straight to the point. We should be able to read the code and it should do exactly that, not something else because you annotated the class. I just wish it wasn't so bloated with error handling. It's difficult to see the actual code among all the if err != nil (even though GoLand does a pretty good job at hiding them). Something like this? f := os.Open("file") or { return err } After a couple of years with Scala, I'm also really missing proper FP, pattern matching, optional types, immutability, etc. Still, I'm pretty happy with Go and it has made me more excited about coding again.

carapace 6y ago

> whereas Python’s significant whitespace (which is there for exactly the same reason: enforcing readable code) has been much more contentious across the programming community. Because with gofmt there's nothing to argue about, it is what it is. With Python’s significant whitespace there was plenty of rope to play tug-o-war with: tabs or spaces? How many? That was enough to fuel the flame wars.