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

241–250 of 305 posts

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

#241

Post by gaganyaan »

didntcheck wrote: post #221
candiddevmike wrote: post #128

Earlier quoted context omitted.

Your code shouldn't be littered with that though, those errors should be wrapped or have some kind of logging/handling associated with them. If you find yourself just returning err all the time, you're not doing it right, IMO.

If only a language could have a built in feature to propagate an error up the call stack, recording its context as it goes! It's always surprised me how negative of a reception checked exceptions had, since they provide the forced handling (or explicit propagating) of (value, err) or Result , but with an automatic stack trace and homogeneous handling across the ecosystem I imagine some of the disdain in Java specific…

Checked exceptions suck because they're implemented in Java, where you have to deal with Java. The moral equivalent in Rust of "Result" is great, because the language was designed to handle it nicely. You're right that lambdas are a part of it. I can chain together `.map`, `.and_then`, and `.transpose` nicely with closures even if there's Results and Options in the mix, but that would be godawful in Java.

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

#242

Post by tomcam »

wk_end wrote: post #158
tomcam wrote: post #102

Earlier quoted context omitted.

Now you’ve got me curious. I’d like to type inference in go. Can you tell me what languages do it better?

In ML-lineage languages (including Haskell) you almost never need any type annotations whatsoever, at least not unless you’re poking around at the fringes of those languages (GADTs, various GHC extensions). Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.

Interesting. I feel much better having some kind of explicit indicator, especially with numeric types.

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

#243

Post by btilly »

valenterry wrote: post #215
btilly wrote: post #214

Earlier quoted context omitted.

Because it makes a certain group of developers more productive. If you care about that or not is your decision. I'm not saying you should. I would qualify that further. It makes a certain group of developers more productive for certain kinds of problems. In particular they are more productive for rapidly creating relatively small prototypes. Particularly if performance is not a significant concern. By the data that I…

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, the data that I saw includes some of the same data that informed the Go team's decisions. And therefore it is no surprise that it fits their ideas. Also that data was rather lacking on, say, real world examples of Hindley-Milner type systems. So maybe those actually work well in practice.

I also have reason to suspect that Rust's type system actually is a big win. Though I haven't seen actual data on it. But since Rust was in early development back when Go was started, it isn't a shock to me that Go didn't incorporate a lot of lessons from Rust.

So I am inclined to think that I'm basically right. However I would also classify my knowledge as only moderately well-informed. (But in a subject where I think that most people who chatter about it are essentially uninformed.)

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

#244

Post by Mawr »

za3faran wrote: post #231
Mawr wrote: post #216

Earlier quoted context omitted.

Is that more or less ironic than Java copying Go's goroutines and still struggling to add value types?

Java's designers have consistently mentioned the approach they're taking that Java has the last mover advantage. They cautiously see what features other languages applied, and take what gives them the highest value compared to the complexity introduced. Java's virtual threads are already superior to golang's approach because they're working on structured concurrency from the start. Value types are a huge proposition,…

> Java's designers have consistently mentioned the approach they're taking that Java has the last mover advantage.

There's nothing one can do to wiggle away from designing something. You can only make tradeoffs. In this case, Java's sacrificing time. Is that a good call? I don't know.

> They cautiously see what features other languages applied, and take what gives them the highest value compared to the complexity introduced.

They've historically shown poor taste in the features they've chosen, so this strategy doesn't seem to have worked out all that well. Waiting longer doesn't help if you don't know what you're doing.

> Java's virtual threads are already superior to golang's approach because they're working on structured concurrency from the start.

Already? Ten years later! Time matters.

We'll see how much actual adoption there'll be, Go was built with its concurrency solution in mind, so not only are the primitives ergonomic to use, but the entire ecosystem has grown around it. You can't match it in a day.

> Value types are a huge proposition, [...]

"Value types" is a misnomer anyway, it's just "types". We've had those since at least C, some 50 years ago.

> [...] but they seem to be coming along nicely.

I've been hearing this for a while, has it been a decade yet?

> They have already baked in nullables/zero values into the design, something that is a pain in golang, and a big gotcha and source of bugs.

You can't be serious. Complaining about another language's null problems from the perspective of Java?

> The interesting thing is that Java already beats golang because of its superior GCs, particularly in large programs, so it will be interesting to see what sort of performance improvements come out of value types.

It's a wash most of the time AFAIK. Unless we do the classic Java benchmark trick of ignoring memory usage.

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

#245

Post by pjmlp »

philosopher1234 wrote: post #212
pjmlp wrote: post #187

Earlier quoted context omitted.

Docker, Kubernetes and key CNCF projects.

What was the marketing investment here..?

Google is using Go to implement Kubernetes.

Kubernetes is cool, I want to play with Kubernetes.

Maybe I should lean Go to play.

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

#246

Post by kaba0 »

Mawr wrote: post #194
wk_end wrote: post #158

Earlier quoted context omitted.

In ML-lineage languages (including Haskell) you almost never need any type annotations whatsoever, at least not unless you’re poking around at the fringes of those languages (GADTs, various GHC extensions). Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.

From my experience, such type inference systems are awful in practice. Rust designers tried to do something like that initially but quickly realized understandability suffered greatly. You really do want to specify types manually, at least at boundaries, e.g. in function definitions. > Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almos…

That’s just artificial limits. You yourself mentioned Rust that does the exact same type inference with the limit for usability of having signatures typed. Here is your example of a language with eons better type system/type inference, but go’s is really not a high mark.

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

#247

Post by kaba0 »

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…

> The Go team was populated by people who had created one of the most influential languages of all time, C

Which is absolutely terrible from a programming language point of view, there were already better languages at its inception. Ken Thompson has a huge legacy in the CS world, but he is frankly not a good language designer at all.

Also, appeal to authority. If go were so good, it should able to be praised on its own accord.

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

#248

Post by kaba0 »

Veraticus wrote: post #147
btilly wrote: post #127

Earlier quoted context omitted.

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…

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.

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

#249

Post by 59nadir »

za3faran wrote: post #73
nullwarp wrote: post #62

Earlier quoted context omitted.

Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still try…

golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.

What does this actually mean? They are both programming languages made for solving general problems, what makes the comparison inappropriate? I've used both and pretty much all of their cousins, so I'm confused why you would think they aren't comparable.

The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.

Post reply on HN