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

91–100 of 162 posts

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

#91

Post by idoubtit »

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

[^2]: https://golang.org/pkg/runtime/trace/

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

#92

Post by Cthulhu_ »

lmm wrote: post #23
mappu wrote: post #2

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

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

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.

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

#93

Post by Cthulhu_ »

eznzt wrote: post #72

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

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.

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

#94

Post by Chris_Newton »

Sharlin wrote: post #81
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

I've never written Haskell or another pure functional language more than a couple of lines, but the more I write code the more convinced I become that the ability to reason about mutability and side effects is a major force multiplier in writing robust software.

I agree that being able to reason about mutability and other effects is useful. However, that doesn’t necessarily imply an all-or-nothing approach where either you’re in a pure function or you can do anything with anything. In a sibling comment, gwd mentioned const in C, which is one example of something in between. Rust’s ownership semantics and borrow checker are another.

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

#95

Post by Cthulhu_ »

dmitriid wrote: post #64
gonzo41 wrote: post #49

Earlier quoted context omitted.

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…

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.

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

#96

Post by anentropic »

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/ "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 ...it seems like you can specify versioned deps now

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

#97

Post by the_af »

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…

Such a weird thing to frame this in terms of the Blub Paradox. Regardless of what you think about the paradox, this is what it states:

> But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

It's very, very hard to argue Go is "up the power continuum" from Haskell, or that Haskell is a Blub language compared to Go. Everything else can be debatable, but surely not this.

He could have simply said "I was arrogant about Go, and need to look at it from a fresh perspective instead of comparing it to a language I'm more familiar with", no appeals to Blub needed.

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

#98

Post by jeromenerf »

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.

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

#99

Post by [deleted] »

gwd wrote: post #63
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

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

[deleted]

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

#100

Post by Chris_Newton »

uryga wrote: post #85
linspace wrote: post #56

Earlier quoted context omitted.

I joked with a friend that as people get older they start to prefer static typing. I personally don't have a preference, it depends on the application. I think it's obvious what are the advantages of static typing so let me rant about what is for me the main disadvantage: as soon as you have an advanced type system people will try to get creative writing code in the most abstract possible way. It's inevitable. It's t…

as a counterpoint, genericness can actually serve as a form of documentation. you can often infer a lot from just a signature, e.g: any :: (Functor f, Foldable f) => (a -> Bool) -> f a -> Bool tells me that `any` has to work across the whole collection `f a` (list/tree/whatever), because that's how folding works, and that it will get the answer by calling the function on the collection's elements (the collection is a…

This advantage can be overstated and give a false sense of security, though. It’s true that for entirely generic functions, you can sometimes infer useful properties just from the type signature, but once you start getting any more specific types in there, all bets may be off. You said

[of course this is assuming that `any` isn't implemented as `any _ _ = True`]

but actually there are many more possibilities. For example, this function might return True if the provided data structure has exactly 5 elements, never using the provided (a -> Bool) function or mapping over anything.

Post reply on HN