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

191–200 of 305 posts

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

#191

Post by Mawr »

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't mean that type inference wasn't mostly solved in the 70s.

Theory's only as useful as its implementation. If there's no sensible implementation of type inference out there, but then a new language comes out with it, is that not a significant improvement to the status quo, even if the theory behind it may be decades old?

Code autoformatters were not exactly dark PL magic when Go came out either. But somehow the impact gofmt has had on the PL space has been immense. Funny how that works.

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

#192

Post by Tainnor »

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.

Why should there be only one goal of "the PL community" (whatever that is)? Maybe you need people who advance the state of the art and others who make things ready for production.

> Theory's only as useful as its implementation. If there's no sensible implementation of type inference out there, but then a new language comes out with it, is that not a significant improvement to the status quo, even if the theory behind it may be decades old?

That would be a fine argument if Go had been the first major language with type inference, but even if you're willing to ignore ML languages (because you think they're too niche and/or weird), Scala is almost 10 years older than Go.

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

#193

Post by Xeamek »

Mawr wrote: post #190
soulbadguy wrote: post #174

Earlier quoted context omitted.

> 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. And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good meas…

> In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. Not at all. It's the same as with literally any other product. If it's good, people will use it. Outliers are rare. Now, you may disagree with what most people consider good, but that's another discussion ;)

https://rationalwiki.org/wiki/Survivorship_bias

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

#194

Post by Mawr »

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.

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 almost always figure everything out itself.

See? That's not a good thing at all. If the compiler's capability makes the code less understandable, then it's undesirable. Doesn't matter how fancy and cool, or state-of-the-art it may be.

You probably don't want to strap a jet engine to a car, no matter how cool you may think it would be.

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

#195

Post by Xeamek »

Mawr wrote: post #190
soulbadguy wrote: post #174

Earlier quoted context omitted.

> 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. And nothing says that go wouldn't have been more successful had they added those features. In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. But IMO, the success is not a good meas…

> In the final analysis, the relationship between the success of a language and any intrinsic qualities is very hard to qualify. Not at all. It's the same as with literally any other product. If it's good, people will use it. Outliers are rare. Now, you may disagree with what most people consider good, but that's another discussion ;)

I guess marketing industry is billion dollar money sink then.

"Just get-good at making products, duh"

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

#196

Post by sophacles »

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.

And here I thought it was because:

1. repeating the same function definition and type declarations over and over varying only one type parameter and the name was a great way to introduce bugs if one of the functions was missed in updating.

2. working with reflection is slow and complex and easy to get wrong

Both of which are solved with something simple like generics.

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

#197

Post by Tainnor »

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…

I still don't know what people mean by "obvious" code.

Yes, there are people who create a mess with abstraction. This happens in every language, in Java people create FactoryFactories, in Haskell people play type tetris, in Ruby, people abuse metaprogramming and in Go, I assume some people go overboard with code-gen.

But that said, I suspect many people, when they say, "obvious code", they mean "I can easily understand what every line does". Which is a fine goal, but how does that help me with a project that has 100ks of lines of code? I can't read every single line, and even if I could, I can't keep them all in my head at once. And all the while, every one of these lines could be mutating some shared state or express some logic that I don't understand the reason for.

We need ways of structuring large code bases. There are a ton of ways for doing so (including just writing really good and thorough documentation), but just writing "obvious" code doesn't cut it. Large, complex projects are not "obvious" by their very nature.

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

#198

Post by primax »

ducktective wrote: post #104
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…

Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how? Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?

A data dip via a single http endpoint is very easy to implement in go. Like 6-8 lines of code easy, with tons of examples available online

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

#199

Post by [deleted] »

ducktective wrote: post #104
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…

Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how? Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?

[deleted]

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

#200

Post by [deleted] »

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…

[deleted]
Post reply on HN