Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

memo.barrucadu.co.uk

Post reply on HN
Print view View original

61–70 of 162 posts

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

#61

Post by Cthulhu_ »

nickcw wrote: post #30

> 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 o…

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

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

#62

Post by Cthulhu_ »

sneak wrote: post #9
thatswrong0 wrote: post #5

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.

https://github.com/mvdan/gofumpt Drop in replacement for `go fmt` and probably does most of what you want.

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.

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

#63

Post by gwd »

panpanna wrote: post #37
jonahx wrote: post #15

Earlier quoted context omitted.

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.

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

> He slams go for not doing stuff the Haskell-way (e.g. pure code vs effectful code).

Heck, I come from a C background, and that's a complaint I have about Go. Sometimes you want to have a function accept a pointer to a large structure to avoid copying, but have the compiler prevent you from making any changes. In C you'd write "const"; in Go there's no way to do that.

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

#64

Post by dmitriid »

gonzo41 wrote: post #49
wwarner wrote: post #7

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

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?

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`

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

and so on.

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

#65

Post by scottlocklin »

eptcyka wrote: post #41
panpanna wrote: post #37

Earlier quoted context omitted.

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

That is a single dubious point amongst some serious and in my opinion legitimate issues with the language.

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.

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

#66

Post by technion »

innocentoldguy wrote: post #52
ghayes wrote: post #39

Earlier quoted context omitted.

Dialyzer is fully integrated into Elixir, yes. But again, it’s optional typing.

I know how to use Dialyzer and am quite proficient with it. I cannot say, however, that it helps me in any way. I think strong typing is a crutch for bad programmers and I've yet to encounter anything in my 30+ years of programming to change my mind.

Dialyzer solves certain problems for me that still exist in many "typed" languages. A great example is pos_integer(). In something like Typescript I can use "number", but that doesn't assert I can't receive a negative number, or a zero.

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

#67

Post by _0w8t »

quickthrower2 wrote: post #19
kjksf wrote: post #10

Apparently, the author of this blog post had a change of heart: 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…

Definitely! I couldn't get my head around why people like untyped languages, but I keep an open mind on it. I won't close off that they could be better, if the right patterns/practices are used (whatever they are!)

Prototyping or gluing components together is definitely faster without static typing.

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

#68

Post by eru »

technion wrote: post #66
innocentoldguy wrote: post #52

Earlier quoted context omitted.

I know how to use Dialyzer and am quite proficient with it. I cannot say, however, that it helps me in any way. I think strong typing is a crutch for bad programmers and I've yet to encounter anything in my 30+ years of programming to change my mind.

Dialyzer solves certain problems for me that still exist in many "typed" languages. A great example is pos_integer(). In something like Typescript I can use "number", but that doesn't assert I can't receive a negative number, or a zero.

In general, you'd need something like dependent types for solving this properly. Like eg Agda has.

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

#69

Post by barnacled »

kjksf wrote: post #10

Apparently, the author of this blog post had a change of heart: 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…

While I think there's some sense in the analogy and you get real insights using new languages, I do find that 'beating the averages' article really unconvincing.

Firstly there's the obvious observation that Y Combinator companies very rarely use lisp, but there's also really a lack of any solid evidence of any kind anywhere that language choice has such a big impact.

I am a fan of exploring languages and making a good choice for the problem at hand and always remaining open-minded but I can't stand the religious flame war side of it and I really do not think that article helps, at all.

To me languages are always a trade-off between abstraction and control, to which each problem has an appropriate range of languages to apply.

I also think the concept doesn't apply here as go is certainly less powerful and has fewer abstractions than Haskell (by design) - so if anything it is the 'blub' language* according to the article here (my point being not to criticise go but rather to point out how silly the beating the averages concept is).

I don't think his original piece was arrogant, I think this is something of an overreaction and a problem with assessing any language - adherents meeting criticism with 'you just have to use it more' can use that excuse indefinitely. Better to address individual points.

* I love go and contributed to the core compiler back in 2011/12 so this isn't an attack on it.

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

#70

Post by Twisol »

eru wrote: post #53
rwmj wrote: post #46

Earlier quoted context omitted.

And especially type inference.

Yes. Ideally something as powerful as Hindley-Milner or similar. But even the weak sauce versions in Go (or recent Java or C++) are a boon to developer ergonomics.

Java's is particularly weaksauce, and has problems chaining inferences within even the same expression, but it's definitely way better than not having it at all.
Post reply on HN