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

Ten years of “Go: The good, the bad, and the meh”

blog.carlmjohnson.net

Post reply on HN
Print view View original

201–210 of 305 posts

Re: Ten years of “Go: The good, the bad, and the meh”

#201

Post by sophacles »

Mawr wrote: post #191
wk_end wrote: post #46

> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…

> Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. The fact that it was even a point of concern shows how misguided the PL community is. Advancing the state of the art is not the goal, producing a tight, clean design is. > Just because Sun couldn't figure out how to do it in the 90s doesn…

> The fact that it was even a point of concern shows how misguided the PL community is. Advancing the state of the art is not the goal, producing a tight, clean design is.

I don't see how having better type inference interferes with the "tight clean design"? If anything I'd argue that not having it is a hinderance. Why do i need to `x :=make([]foo)` or `var x []foo` when I could just `x := []` and let the type system infer that its `[]foo` by the fact that I keep `append`ing `foo`s to it?

Re: Ten years of “Go: The good, the bad, and the meh”

#202

Post by Mawr »

za3faran wrote: post #75
iamcalledrob wrote: post #43

I am immensely thankful for Go. The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is chefs kiss . Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the t…

> Working on a cross-platform project where in Go, I write code and it just builds I've worked on large golang code bases that had to build on bazel, and I had the same experience fighting it. It has nothing to do with the language. > In Java, I fight with Gradle. So gradle's issue, not Java's. See above.

The way you use the language has everything to do with the language. It is the language.

A language is a product, and the programmers writing in it are its users. The same way any other product works.

Would you be okay with buying a Tesla without the capability to charge at supercharger stations? You can only charge at home. The supercharger network is not literally part of the car after all!

Re: Ten years of “Go: The good, the bad, and the meh”

#203

Post by Tainnor »

Night_Thastus wrote: post #142
aptenoforst wrote: post #119

Earlier quoted context omitted.

Anything that made programming easier in the last 30 years. I miss Hindley Milner type inference, ADTs, default immutability, sane error handling, pattern matching, and functional collection manipulation. I'm not even mentioning the time it took to add generics to the language, which should've come from the beginning, and we got a bad implementation of it. Not saying that it HAS to have all of this, but at least 1 or…

TBH, it sounds like you want a functional language (type inference, pattern matching, collection manip), of which there are many. GO is not such a language. But then you want ADTs, which aren't really functional. I'm not sure you can have both in a clean way. The closest you might get is a multi-paradigm language that tries to allow both, like C++. Default immutability is great in a language like Rust where it's desi…

> But then you want ADTs, which aren't really functional.

Pretty sure by ADTs, GP means "algebraic data types". These are very much functional, at least in the sense that they're a standard feature of statically typed FP (at least I know of no such language that doesn't have them).

ADT also sometimes stands for "abstract data type", which is something different. Although I wouldn't call them incompatible with FP either, Haskell typeclasses can express abstract data types, for example.

Re: Ten years of “Go: The good, the bad, and the meh”

#204

Post by primax »

mikebenfield wrote: post #77
softirq wrote: post #57

Earlier quoted context omitted.

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

> And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.

Building something that can be successfully adopted and operationalized at mass scale is an element of the state of the art.

Re: Ten years of “Go: The good, the bad, and the meh”

#205

Post by Tainnor »

softirq wrote: post #57
wk_end wrote: post #46

> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…

> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…

What do you mean by "Go has succeeded"? It has found its niche, yes, but so have those HM languages (maybe the Go niche is a bit bigger), and a bunch of other languages that people also like to hate.

Meanwhile, most code is still written in languages like Java, C and PHP.

That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has revolutionised anything. It's just become a new option among many.

Re: Ten years of “Go: The good, the bad, and the meh”

#206

Post by Mawr »

Veraticus wrote: post #162
valenterry wrote: post #148

Earlier quoted context omitted.

It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.

I've been using Golang professionally for about a decade. In that time the only place I've ever needed to use a tree map was an interview that specifically called for it. Whose usage are you trying to optimize the language for? Golang is not a good academic language. But it is extremely good for actually solving problems with code.

A tree map is just an example.

More compelling ones are sets, ordered maps, a generic sync.Map, optionals (nulls suck!), abstractions over channels - badly needed!

I wouldn't consider any of those to be academic.

Re: Ten years of “Go: The good, the bad, and the meh”

#207

Post by lillywastaken »

Veraticus wrote: post #52
bborud wrote: post #42

Go didn't try to be overly clever and abstract. That rubs quite a few people the wrong way, but it also means you are less likely to have to work with people who try to be clever. My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now. I want to…

Yeah this was my primary complaint with the inclusion of generics. People will try to be all clever and their code will wind up as an unreadable, unmaintainable disaster. It has definitely led to some cool stuff, but I prefer boring, verbose, and clear any day.

Is writing the same function n times more readable and more maintainable? Is it more maintainable to entirely circumvent the type system with interface{}?

Re: Ten years of “Go: The good, the bad, and the meh”

#208

Post by Mawr »

SCLeo wrote: post #180
j1elo wrote: post #65

I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I…

Honestly, I'm incredibly frustrated with this issue; it's just pure idiocy. Commenting out a part of the code and observing the effects is such a simple and useful debugging technique, yet this "feature" of Go prevents you from doing so effectively. What's even more frustrating is that when you search for solutions, you come across two kinds of (pardon my language) completely brain-dead responses: First, there are th…

> I've never seen anyone argue that allowing unused variables is good for production. It's always been about facilitating the development process and debugging. Yes, I am aware now there are unused variables, but please just let me see what does removing this part of the code do.

Yes, but once you allow that, you'll inevitably end up with unused variables in production code (warnings are useless). That's the core of the issue and why the Go team made the decision.

In my opinion, the real solution is to have two build modes: --devel and --release. This would allow for not bothering devs with anal checks during development while preventing substandard code in production.

Though the real advantage would come from the reduced pressure on compilation speed in --release mode which would make room for more optimization passes, resulting in faster production runtime speed and lower binary size.

Re: Ten years of “Go: The good, the bad, and the meh”

#209

Post by Night_Thastus »

Tainnor wrote: post #203
Night_Thastus wrote: post #142

Earlier quoted context omitted.

TBH, it sounds like you want a functional language (type inference, pattern matching, collection manip), of which there are many. GO is not such a language. But then you want ADTs, which aren't really functional. I'm not sure you can have both in a clean way. The closest you might get is a multi-paradigm language that tries to allow both, like C++. Default immutability is great in a language like Rust where it's desi…

> But then you want ADTs, which aren't really functional. Pretty sure by ADTs, GP means "algebraic data types". These are very much functional, at least in the sense that they're a standard feature of statically typed FP (at least I know of no such language that doesn't have them). ADT also sometimes stands for "abstract data type", which is something different. Although I wouldn't call them incompatible with FP eith…

Ahah, whoops. I thought they meant "abstract data types", ie, classes - which AFAIK Go does not have.

Yeah, then if they want algebraics then a functional language is definitely the answer here.

Re: Ten years of “Go: The good, the bad, and the meh”

#210

Post by lillywastaken »

Veraticus wrote: post #36
icholy wrote: post #15

Earlier quoted context omitted.

> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code. Who needs data structures right?

Uh, generics are not data structures and generics are neither the only way nor the best way to interact with data structures.

Do you think it is somehow more elegant to have a specialised version of a data-structure for every single type that may need to be placed into it? Or just to ignore the type whatsoever and erase it via interface{}? Even Golang's designers obviously realise that generics are a better way to interact with data structures because the standard types map and array were always "generic", just special cased as such.
Post reply on HN