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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

481–490 of 670 posts

Re: Toward Go 2

#481

Post by rsc »

notjack wrote: post #185
jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.

FWIW I think this is a fair criticism. We've had so much help from the Go community, not just for those two issues but also for essentially all the work we've done since the release in 2009. Go simply wouldn't exist without the community, and we're very grateful for it.

I couldn't fit any kinds of thank yous into the talk, except for the credit to the overall community in the first few minutes, because I had a lot to say and only 25 minutes. It's possible I should have written an extended blog post that was more than just the talk, but I didn't - the blog post is just the talk, as it says.

Re: Toward Go 2

#482

Post by rsc »

canes123456 wrote: post #278
jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

The discussion is not about identifying problems. The issue is communicating the problem and explaining the impact. The Go team was wrong about monotonic time but the correct response is not to assign blame. Concrete examples and conversations are a better way to communicate a problem. This is what they are trying to communicate now.

And if you _do_ want to assign blame, it's fine to put it on us. I did as much in the talk:

"Just as we at Google did not at first understand the significance of handling leap second time resets correctly, we did not effectively convey to the broader Go community the significance of handling gradual code migration and repair during large-scale changes."

Our fault, both times.

Re: Toward Go 2

#483

Post by adrianratnapala »

rbehrends wrote: post #307
willtim wrote: post #108

Earlier quoted context omitted.

As a far as I can tell, an "optional type system" is just an unsound type system with a marketing name. Any decent static type system would allow one to progressively increase the level of typing, the weakest form being using a Variant type to hold all other types. The advantage here is that any invariants/proofs that are captured in the system are not compromised by unsoundness.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

There seems to be a cost associated with static types and that is that it takes longer to write code;

But this is not the only cost that matters, indeed might not even be a cost.

I've gone from being neutral about static vs. dynamic types to being pro-static types -- and the change happened when maintenance became a bigger part of my job.

Writing new code is now far less important to me than looking at a small part of a large system and trying to understand what is and is a not possible at that point. Static typing does not make this easy, but dynamic typing makes it far more difficult.

Re: Toward Go 2

#484

Post by rsc »

camus2 wrote: post #127
jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

The second half of the "Introduction" section of the blog post explains what "done" meant and why.

Re: Toward Go 2

#485

Post by rsc »

Analemma_ wrote: post #8

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must…

I think you're mostly right. Doesn't it make sense then to ask for help correcting that bias?

Re: Toward Go 2

#486

Post by rsc »

jgrahamc wrote: post #3

I didn't expect to get namechecked in that. Shows the value of constantly being transparent and supporting open source projects.

It absolutely does, and thank you. (I thought you might be here so I could thank you in person.)

Re: Toward Go 2

#487

Post by rbehrends »

adrianratnapala wrote: post #483
rbehrends wrote: post #307

Earlier quoted context omitted.

No, there's more to it. There's been some research in recent years on the actual benefits of types and the results are less straightforward than some people think. An important aspect of type annotations, for example, seems to be that they help document the API of a module, regardless of whether they're statically checked. This is especially relevant with respect to maintenance tasks. Conversely, the benefits of stat…

There seems to be a cost associated with static types and that is that it takes longer to write code; But this is not the only cost that matters, indeed might not even be a cost. I've gone from being neutral about static vs. dynamic types to being pro-static types -- and the change happened when maintenance became a bigger part of my job. Writing new code is now far less important to me than looking at a small part o…

> But this is not the only cost that matters, indeed might not even be a cost.

I'm not saying otherwise. My point is that there's no objective way to proclaim one better than the other. This depends on application domain, economic constraints, engineering constraints, what you're doing, and so forth.

Writing Ada software that controls a pacemaker has totally different requirements than exploratory programming in Jupyter that mostly deals with integers, floats, and arrays and matrices thereof, for example.

Re: Toward Go 2

#488

Post by rsc »

nickbauman wrote: post #56

Will there be gotos in Go 2? Asking for a friend.

Have you actually used Go 1's goto? There's not a lot it can actually do. It's there for generated code state machines, and that's almost all it's good for. But yes, goto will stay in the absence of a very compelling benefit to take it out, a benefit that would far outweigh the cost of breaking all the programs that use it.

Re: Toward Go 2

#489

Post by adrianratnapala »

jules wrote: post #449
kevhito wrote: post #428

Earlier quoted context omitted.

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough" And that's just in your first sentence. My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team membe…

What are the very real downsides that generics have?

Even if you don't care about binary bloat (and I do care), it can introduce some of the same problems as dynamic typing.

If I am debugging some C++, and I find myself looking at templated function, then I can't easily see what types the template parameters are. Also it becomes hard to navigate to method calls etc.

C++ is a particularly bad example, because template metaprogramming is essentially typeless. But any form of polymorphism introduces these problems to some extent.

To be fair, that includes the run-time polymorphism already available in Go. Thus if generics allow us to replace some `interface{}` hacks with properly typed middle-men (even if they compile down to `interface{}`) then that would be genuine benefit.

Re: Toward Go 2

#490

Post by lomnakkus »

randomdata wrote: post #459
lomnakkus wrote: post #82

Earlier quoted context omitted.

Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. -…

There are many different ways to provide generics (templates, typeclasses, etc.), each with their own pros and cons. It's not simply a matter of "add generics". And what solution they do come up with is going to bring the given cons those who would be better served by a different generics solution. The Go team have been long criticized for choosing the option that fits Google, but not the rest of the world. This seem…

Then they should ask for that instead.

It's not unreasonable to ask "how do we implement this in the best way?", but I'll note a) that's not what was asked, and b) I have a hard time believing that code at Google is so incredibly "special" that they need a special kind of generics. Also, if Google is such a unique snowflake why not ask the Google people directly rather than the "Go community"?

Post reply on HN