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

251–260 of 305 posts

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

#251

Post by valenterry »

sethammons wrote: post #163
valenterry wrote: post #146

Earlier quoted context omitted.

Since when has "clever" become something negative? If someone is clever, that's a good thing! I also try to be clever when I do things, be it repairing something, planning my workout routine or programming.

I've heard the drum against clever code for over a decade. This sums it up well: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

"If code is written as clevery as possible, it's surely written in a way that it's easy to debug it"... is what I would reply, but I get the gist. :-)

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

#252

Post by valenterry »

btilly wrote: post #243
valenterry wrote: post #215

Earlier quoted context omitted.

I think you are quite mistaken. It is pretty much commonly agreed that powerful typesystems are not great for prototypes, rather the opposite, they allow easier maintenence of bigger codebases.

I have seen much in the way of opining that this should be true. I have seen zero in the way of real-world maintainability data saying that it is true. Mind you, there is very little good real-world public maintainability data. And therefore I will say that, when I was at Google, I saw some of their private data, and it wasn't true there. Specifically, most of the win from a type system is simply having one. Mind you…

> Also that data was rather lacking on, say, real world examples of Hindley-Milner type systems. So maybe those actually work well in practice.

That is of course a bit disappointing, because anything below HM is _certainly_ not what I call advanced. But Google must be using some languages that use HM or a variant no? How comes there is no data about those.

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

#253

Post by Veraticus »

kaba0 wrote: post #248
Veraticus wrote: post #147

Earlier quoted context omitted.

Right? So many complaints about "well but it's hard to make N-leaf tries in golang so we need generics!" It's like people believe the success of a programming language is correlated to its ability to express obscure computer science concepts unrelated to most peoples' jobs. Golang works extremely well in practice, which is what I really care about.

If a goddamn list/vector requires built-ins from your language, you have already lost.

Golang is responsible for some of the biggest open-source projects out there and has a huge share of developers working in it. Lost… what exactly?

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

#254

Post by kaba0 »

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…

> Advancing the state of the art is not the goal, producing a tight, clean design is.

Sure, but they failed to deliver that.

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

#255

Post by pjmlp »

btilly wrote: post #127
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 Go team was populated by people who had created one of the most influential languages of all time, C. Who created the new language based on theories about how to encourage good engineering practice. Theories that they were able to test…

Those wouldn't have been as successful if AT&T had been allowed to sell UNIX at the same prices as VAX/VMS, instead of having source tapes available for a symbolic price.

It isn't as if C would have been a commercial success, had it come with a price tag.

Plan 9 and Inferno commercial successes, and Limbo adoption, are a clear example of how it would have gone instead.

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

#256

Post by EspressoGPT »

Tainnor wrote: post #205
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…

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…

The fact that you mention Go, an 11-year-old language, alongside a 27-year-old, a 51-year-old and a 28-year-old language proves that it has succeeded.

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

#257

Post by pjmlp »

afandian wrote: post #82
adtac wrote: post #40

Earlier quoted context omitted.

I consider the stdlib to be Go's best feature too. As a somewhat contrived example, can you name any language that lets you write a HTTP/2 TLS endpoint that computes the HMAC of a PNG file's pixels without any dependencies? And if something is still missing, it's probably in golang.org/x (which is basically stdlib)! After that, I probably consider readability at 3am [1], defer statements, explicit error handling and…

Just cos I was curious and Java has a pretty good comprehensive library. - PNG: https://docs.oracle.com/en/java/javase/14/docs/api/java.desk... - HMAC - https://docs.oracle.com/en/java/javase/14/docs/api/java.xml.... You need Jetty for HTTP/2.

We are now with Java 21 around the corner, and any Java EE server (nowadays Jakarta EE) framework supports HTTP/2, which is basically the Java standard library for servers.

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

#258

Post by EspressoGPT »

gaganyaan wrote: post #239
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…

Nah mate, sorry. Go is a language already past its prime, which is laughable given how young it is, and how it was modeled on better, long-lived languages. Take a look at Google trends if you disbelieve me. There was a slight bump in interest when generics finally got pushed out, but that's died off, and Go is entering the same decline as other has-beens like Ruby. Good riddance to a language designed for people that…

Most SWEs aren't particularly good at programming. It's not a shame to embrace that.

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

#259

Post by bzzzt »

pg_1234 wrote: post #170
cempaka wrote: post #72

Earlier quoted context omitted.

As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or exper…

Go is basically C with training wheels, THAT CAN NEVER BE REMOVED. It accelerates junior devs to production ready at the expense of everyone else. It really feels like a language designed by people with utter contempt for those who actually write code.

If those people who 'actually write code' wouldn't have sprinkled their code with race conditions and buffer overflows maybe C would still be used widely for business apps, but reality is C code, while highly efficient, carries more risks than languages with training wheels. It's not contempt, it's coping with a reality where you can't afford to disqualify half of the programmer population because they're 'too junior' while there is an extreme shortage of workers. There's even a shortage of programmers for languages _with_ training wheels here...

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

#260

Post by kaba0 »

Veraticus wrote: post #94
woooooo wrote: post #91

Earlier quoted context omitted.

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.

You are writing a Turing complete language. If someone wants to be stupid architecture astronauts, you can’t help them, beside better filtering people who work on your project.
Post reply on HN