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

81–90 of 162 posts

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

#81

Post by Sharlin »

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

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.

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

#82

Post by wwright »

eru wrote: post #68
technion wrote: post #66

Earlier quoted context omitted.

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.

Ada has this without general dependent types AFAIK

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

#83

Post by jiofih »

willtim wrote: post #80
Philip-J-Fry wrote: post #33

Earlier quoted context omitted.

Yeah it's hard to write weirdly complicated code in Go. Stick Java or C# in the hands of a team and before you know it you've got typed factory service factories and every abstraction known to man.

> Yeah it's hard to write weirdly complicated code in Go Just because Go lacks many forms of abstraction, doesn't mean complex code will not be created with it. Quite the opposite. It's lack of expressiveness will encourage "frameworks", elaborate encodings, code generation and various productivity aids. Look at what the lack of generics has done to the Kubernetes code base: "The core team replaced a compile-time lan…

> Quite the opposite.

No. What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.

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

#84

Post by simiones »

scottlocklin wrote: post #65
eptcyka wrote: post #41

Earlier quoted context omitted.

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

The type system complaints are somewhat in the area of "it should be more like Haskell", but the debugger, heap profiler and thread debugger ones are certainly not.

Golang has extremely basic tools for anything beyond formatting/compiling compared to most modern languages. This is just a limitation of the current ecosystem, not something you can say has tradeoffs (except of course for the Go team's time/prioritization of features).

Delve is getting better, but it has a LOT of ground to cover before it is half as useful as gdb or a java/C# debugger. Same goes for the profiling tools, especially on the CPU side.

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

#85

Post by uryga »

linspace wrote: post #56
quickthrower2 wrote: post #19

Earlier quoted context omitted.

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

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 Functor, and the only thing you can do with one is `map` a function over it).

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

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

#86

Post by wwright »

_0w8t wrote: post #67
quickthrower2 wrote: post #19

Earlier quoted context omitted.

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.

I think this is a fault of language ergonomics rather than static typing.

If you are gluing components together, then surely the components have a common interface that uses compatible types. And surely you need to tell the runtime what those types are in some way, even if that is simply by writing them to return appropriate values.

In theory, a statically typed language with ideal ergonomics would make that as easy to specify as a dynamic language, but would have the benefit of warning you of mistakes as early as possible.

Of course, many statically-typed languages trade-off some amount of ergonomics for other features.

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

#87

Post by willtim »

jiofih wrote: post #83
willtim wrote: post #80

Earlier quoted context omitted.

> Yeah it's hard to write weirdly complicated code in Go Just because Go lacks many forms of abstraction, doesn't mean complex code will not be created with it. Quite the opposite. It's lack of expressiveness will encourage "frameworks", elaborate encodings, code generation and various productivity aids. Look at what the lack of generics has done to the Kubernetes code base: "The core team replaced a compile-time lan…

> Quite the opposite. No. What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.

> What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.

I suggest that is because not many large applications have yet been built in Go and it is still relatively young. If Go was used more sparingly as a "domain-specific language for concurrent network services", then I might be inclined to agree with you, but it seems to be marketed and promoted as a general purpose language.

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

#88

Post by shaan7 »

Philip-J-Fry wrote: post #77
shaan7 wrote: post #43

Earlier quoted context omitted.

What higerorderma said above applies to this ^ comment as well. It is another of those nonsensical things that keeps getting repeated all the time by some Go programmers. That line of thinking promotes workarounds over long-term solutions. If your team has people who are abusing tools (like types, abstractions etc), the solution is to teach them how to not do that. The solution is NOT to remove the tool itself! That…

Why do you think it gets repeated by Go developers? I was a C# developer writing all these abstractions like every other C# developer does. It's idiomatic C#. OOP exists, you're encouraged to use it to abstract and decouple code. Even if you try and strip all that away, you'll never escape it because every library you depend on is written this way. For example, try understanding https://github.com/protobuf-net/protob…

> Why do you think it gets repeated by Go developers?

Not by all, only by a subset of Go developers (until very recently I was one as well, maintained a moderate-size webservice). I specifically said "some Go developers" in my comment because that is what happens (at GopherCons, meetups and so on).

I don't really have a lot of C# experience, but I have read the same story about C++ from lot of people. I think you will agree that abstractions are not a problem, abuse is. Now, I have worked on a C# project for a very short time where I have seen the problems you described. But I do not follow the thinking that a tool was abused and hence its the tool's fault. That is silly.

I was a Go developer for ~4 years where I struggled because I had to constantly spend mental effort trying to ignore the people in the Go community who, instead of focusing on what Go does well, spent all their time (in GopherCon, meetups and so on) rationalizing missing features from Go. Here I was - with this nice language that let me write webservices which are efficient and do not carry a heavy runtime (CLR, JVM etc). But it is severely missing features that can help you be more productive when programming. After all that, listening to people say "its feature, not a defect" just makes you lose all hope that things will get any better.

A better approach is what (thankfully) some folks from the Go team take. You will find blogs from the core team where it is explained that Generics aren't missing because they are outright bad. They are missing because the Go team had not yet[1] figured out how to do it the right way (TM). _That_ is fine, it is the truth.

Finally, you say that it just isn't possible to avoid writing complex code with a powerful language. Well, I have heard that as well, from the same people. But it isn't true, I have worked on a C++ project where I was careful to keep things simple[2] and had quite a few developers on the team (with only college-level C++ experience, most of them Go devs) contribute to the project without much trouble.

But hey, maybe it is personal preference then. I would rather use powerful tooling and put cognitive effort into keeping things simple - rather than using something else and feeling limited by it all the time.

[1] now they have, for the most parts [2] for example, it would use templates but avoid nesting more than one level, and so on. You get the idea.

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

#89

Post by panpanna »

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.

Sure, const is great to have.

But Haskells view on this topic is far far more opinionated than just supporting 'const'.

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

#90

Post by jiofih »

willtim wrote: post #87
jiofih wrote: post #83

Earlier quoted context omitted.

> Quite the opposite. No. What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages.

> What you see in K8S is the exception rather than the norm in Go - but is the norm in other languages. I suggest that is because not many large applications have yet been built in Go and it is still relatively young. If Go was used more sparingly as a "domain-specific language for concurrent network services", then I might be inclined to agree with you, but it seems to be marketed and promoted as a general purpose l…

Go is over a decade old and basically powers the majority of web infrastructure right now (k8s, docker, traefik, istio, terraform, cloudflare) and is used by google, Uber, twitch, SoundCloud, dropbox, YouTube, sendgrid... these are not exactly backyard projects. 90% of all software written falls into concurrent network services now.
Post reply on HN