Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour; [..]
This kind of says it all to me though. I don't "approach programming problems", or at least that's not how I see building something to solve a real problem. I won't spend days philosophising about how to "best" solve this particular subset of the problem, but instead get something out that works and improve as we go along and where it actually matters for those using the product. I'm sure that can be done in Haskell, but it doesn't seem that's how the author thinks about things.
and I don’t worry about the cost of intermediary data structures, because that price is almost never paid in full.
Yet the author does, explicitly, worry about it. There's a whole paragraph about it and this tidbit in the conclusion. He relies on Haskell's lazy nature in order to not have to worry about it but refuses to rely on Go's compiler and garbage collector for similar intelligence (i.e it not mattering) and therefor decides not to split up a function, which he would've done in Haskell. And there's also no proof that the intermediary structure would've mattered at all to the end user. To me this comes right back down to "approaching programming" over building solutions.
Yes it is quite a partial approach. It is still quite good to hear what others coming from a completely different background think about Go though. If nothing else it's instructive about the differences between a functional and imperative mindset. Go is definitely in the imperative camp.
It does seem haskellers spend more time pontificating about the purity and expressiveness of the language than building real projects with it. There is a downside to pure abstractions and brevity - it can lead to code which is so algebraic as to be inscrutable to almost everyone.
This is a really interesting perspective on go from the outside, obviously some of the tradeoffs chosen in Go are distasteful for the author and this is a matter of taste but things like option types are an interesting solution to the more verbose go error handling for example. So while I'd never want go to become Haskell, there are some ideas here worth considering.
This kind of says it all to me though. I don't "approach programming problems", or at least that's not how I see building something to solve a real problem. I won't spend days philosophising about how to "best" solve this particular subset of the problem, but instead get something out that works and improve as we go along and where it actually matters for those using the product. I'm sure that can be done in Haskell, but it doesn't seem that's how the author thinks about things.
Yet the author does, explicitly, worry about it. There's a whole paragraph about it and this tidbit in the conclusion. He relies on Haskell's lazy nature in order to not have to worry about it but refuses to rely on Go's compiler and garbage collector for similar intelligence (i.e it not mattering) and therefor decides not to split up a function, which he would've done in Haskell. And there's also no proof that the intermediary structure would've mattered at all to the end user. To me this comes right back down to "approaching programming" over building solutions.
Yes it is quite a partial approach. It is still quite good to hear what others coming from a completely different background think about Go though. If nothing else it's instructive about the differences between a functional and imperative mindset. Go is definitely in the imperative camp.
It does seem haskellers spend more time pontificating about the purity and expressiveness of the language than building real projects with it. There is a downside to pure abstractions and brevity - it can lead to code which is so algebraic as to be inscrutable to almost everyone.
This is a really interesting perspective on go from the outside, obviously some of the tradeoffs chosen in Go are distasteful for the author and this is a matter of taste but things like option types are an interesting solution to the more verbose go error handling for example. So while I'd never want go to become Haskell, there are some ideas here worth considering.