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

Go 1.18

go.dev

Post reply on HN
Print view View original

31–40 of 614 posts

Re: Go 1.18

#31

Post by nicoburns »

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.

Re: Go 1.18

#32

Post by candiddevmike »

Personally, I'm waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.

Re: Go 1.18

#33

Post by zozbot234 »

gerbilly wrote: post #20
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming commun…

Go has a lot more in common with Alef or Limbo than it does with C, but close enough. It feels like it's been forever stuck in the early 1990s, and now that it's gotten generics it has perhaps reached the late 1990s.

Re: Go 1.18

#34

Post by rat9988 »

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> I would like to understand a bit more about where a lot of the Go criticism comes from

Because I loved the language so much but I feel like it decided to be on the wrong level of abstraction, making many things, uselessly frustrating and verbose. What can be a very readable code in other languages can be hard to read in go because of its verbosity. And the lack of generic has been very limiting of a while, and many discussions with the main team turned to "what are your usecases that really need generic". So I felt like the language won't evolve the way I wanted it, the despite its redeeming qualities.

Re: Go 1.18

#35

Post by mcronce »

icholy wrote: post #10
echelon wrote: post #7

Earlier quoted context omitted.

Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.

If you consider the adoption rate, it's pretty clear that the people who avoid Go because of are a vocal minority.

While true, that doesn't really change the situation for the individuals who require

Re: Go 1.18

#36

Post by FpUser »

andrewf wrote: post #14
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub ( http://www.paulgraham.com/avg.html ). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succee…

Quite frankly Paul's article makes little sense to me. Unless you trying to code in some brainfuck using language A vs language B is of little concern from my experience. I will of course exclude cases when language is simply and obviously unsuitable for the domain. Writing low level video codec in Python is definitely not the best idea. Quality of the programmers on the other hand matters more.

Re: Go 1.18

#37

Post by throwaway894345 »

freedomben wrote: post #24
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). I do dislike the verbosity of Go programs (some of which is force…

> I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go.

Yeah, Go is opinionated. I like functional programming style too (because I like being abstract), but it's hard for me to deny that it's easier for people to read code which is more concrete and standardized (fewer ways to express the same idea) even if there is more boilerplate.

> More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed).

These things have been fixed for a long time. It sounds like you tried Go when it was quite young.

> I think of it as a flavor of ice cream: some people will like it, others won't.

I agree. To expound on that, I'll also posit that people have different goals in choosing a programming language. Some people want a language that makes them feel clever / express themselves aesthetically and others want a ruggedly practical language / Get Shit Done (I definitely fall into both camps). Go is squarely in the latter camp.

Re: Go 1.18

#38

Post by candiddevmike »

philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I think Go's criticisms come from elitism more than anything--folks can't flex their algebraic programming muscles and instead have to do error checking inline or do some WET things due to lack of generics like some amateur.

To me, Go is never the wrong choice, but it may not be the best choice for some projects.

Re: Go 1.18

#39

Post by Thaxll »

nicoburns wrote: post #31
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.

I disagree, Go is easier to read than most modern languages, it's easier because it has a few keyword and did not add major features in the last 15 years.

I can't say the same for Java / C#, Rust / C++ etc ...

Re: Go 1.18

#40

Post by throwaway894345 »

rat9988 wrote: post #34
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> I would like to understand a bit more about where a lot of the Go criticism comes from Because I loved the language so much but I feel like it decided to be on the wrong level of abstraction, making many things, uselessly frustrating and verbose. What can be a very readable code in other languages can be hard to read in go because of its verbosity. And the lack of generic has been very limiting of a while, and many…

> What can be a very readable code in other languages can be hard to read in go because of its verbosity

I suspect that a lot of people conflate "readable" and "terse" or "abstract". For example, beyond one or two chained methods, a foos.map(...).reduce(...) style quickly becomes unreadable while the equivalent for loop is still easily understood (this is a large part of the reason why complicated list comprehensions are discouraged in many parts of the Python world). It's also why it's often easier to understand error paths in Go than in a language which makes heavy use of exceptions despite differences in boilerplate.

Post reply on HN