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

561–570 of 614 posts

Re: Go 1.18

#561

Post by jchw »

pie_flavor wrote: post #560
jchw wrote: post #548

Earlier quoted context omitted.

I don’t think Go channels really panned out well. However, I do think that Go’s thread model and scheduler have turned out great. I think channels could’ve made sense, but they wound up being both more complicated to use and less performant than I think was hoped for. However… channels aren’t a solution for iterators. They’re a solution for communicating between threads. Go, like C, simply doesn’t have anything geare…

Sum types are indeed great. That's why they're in Go 1.18. Pipe syntax and all.

As far as I know, that’s only for interfaces, and it’s more like a union and not a sum type. I’m talking about sum types for structs, like Rust has with enum.

(I realize I’m replying ridiculous fast here, but I just happen to click over to Comments on the first minute. Dumb luck.)

Of course, I could just use Rust, but it’s much harder to make idiomatic Rust libraries than it is idiomatic Go libraries, and I think that fact stunts the ecosystem a bit.

Go may encourage you to use a map to an empty struct for a set, or a weird if statement syntax that contains a full statement instead of a more elegant looking match or for expression, but I find its little quirks to be manageable and without a terrible amount of consequence. Generics will probably bring some good, like the end of needing weird slice tricks, but I’m still concerned it won’t be overall worth it.

Re: Go 1.18

#562

Post by jjtheblunt »

kitd wrote: post #497
jjtheblunt wrote: post #307

Earlier quoted context omitted.

> In fact kotlin/java has better peak performance than Go. Says what benchmark?

There are many benchmarks showing Java faster than Go. The trick is picking one that people agree is representative. It shouldn't be surprising though. "Peak performance" doesn't include start-up time, and ignores memory. If you discount both those, there's no reason that JITted native code wouldn't be faster than a runtime that includes goroutine scheduling.

unless goroutines aren't in use, which means the generated code probably matches what llvm and C would generate.

Re: Go 1.18

#563

Post by jshen »

pie_flavor wrote: post #558
jshen wrote: post #553

Earlier quoted context omitted.

As I've said, this isn't about generics specifically. There are a whole lot of us who find Go code bases far easier to read and understand that most other languages. We believe there is a value to the language's simplicity, and we want to keep it that way. We've written Go for years, and haven't missed many of these features you want. In fact, we think there is a decent chance that Go code bases are easier to jump in…

You are posting a criticism of the feature, in response to a comment that is an answer to that criticism . If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere. But just because you don't interact with a problem doesn't mean it doesn…

You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question.

“ If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.”

This shows a profound lack of understanding of software development at scale.

Re: Go 1.18

#564

Post by dragonwriter »

pie_flavor wrote: post #560
jchw wrote: post #548

Earlier quoted context omitted.

I don’t think Go channels really panned out well. However, I do think that Go’s thread model and scheduler have turned out great. I think channels could’ve made sense, but they wound up being both more complicated to use and less performant than I think was hoped for. However… channels aren’t a solution for iterators. They’re a solution for communicating between threads. Go, like C, simply doesn’t have anything geare…

Sum types are indeed great. That's why they're in Go 1.18. Pipe syntax and all.

Go has (untagged) union types, not sum (tagged union) types.

Re: Go 1.18

#565

Post by azth »

meetups323 wrote: post #244
henvic wrote: post #58

Tip: If you've only heard about generics, make sure to check out about fuzzing (*testing.F)!

Any idea why they have such a low byte budget? testing.Fuzz would be so much more readable. I'll accept test.Fuzz if 9 characters is the limit for any compound identifier. Is this sort of single letter class naming common in the standard library?

just golang things, I agree it doesn't make sense (as do many other things in the language)

Re: Go 1.18

#566

Post by munificent »

jshen wrote: post #402
saurik wrote: post #351

Earlier quoted context omitted.

This is what policies are for, not entirely new languages: if you don't like generics and don't trust the end developers at your organization to not use them in stupid ways you should maybe (I say "maybe" as this problem just seems so lame of a problem to have: if your army of end developers can't be trusted then you should fire them and hire some real developers) have a way to turn off generics that isn't "use a lan…

I’m not talking about generics specifically. I’ve been coding for decades. Go is by far the easiest language I’ve used when it comes to jumping into an arbitrary code base and making sense of it. Again I ask, why insist that go become the same as all the other languages when you can just use one of those? Why demand less diversity?

> why insist that go become the same as all the other languages

You're arguing a strawman. No one insists that Go become the same as all the other languages (which are themselves nowhere near the same as each other). People are just asking for generics.

C++, Java, C#, and Haskell all have generics and are still wildly different languages even with respect to their approach to generics.

Re: Go 1.18

#567

Post by eternityforest »

lanstin wrote: post #366
hodgesrm wrote: post #352

Earlier quoted context omitted.

Specialized collections are not necessarily bad. ClickHouse has dozens of hash table implementations, each tuned to a specific use case. It's what you do when you need something to go very fast.

And that is the exact joy of using a language like C or Go; you need to sort your things, just add in two pointers and make it a list you sort on. Eight or now sixteen extra bytes and you have a good tuned data structure. I don’t want to use a bunch of generic structures, I want to use the ones that solve my particular use case best.

I always say "Just right is all wrong". The time and standardization cost is often just too much for the small gains. I'd much rather have everything be reusable, abstracted, and one size fits all, aside from the tiny fraction that matters enough to optimize.

Re: Go 1.18

#568

Post by pjmlp »

jshen wrote: post #554
pjmlp wrote: post #526

Earlier quoted context omitted.

Thanks, the same way that people in Go community see as inconvenience to learn how to write better code. The old ways of code generators are good enough.

I've been coding for decades. I've written large scale systems in functional languages. I was a believer, but after many years of experience, I didn't find it to add a whole lot of value. I didn't find that there were fewer bugs as promised, it wasn't faster to develop and ship features, and most importantly, it was hard to jump into other peoples code and make sense of it. You might have a different opinion, that's…

Apparently the Go team has themselves admitted that we are right and they were wrong.

Go is open source, create your own fork without generics and lets see which version keeps going.

Re: Go 1.18

#570

Post by jshen »

pjmlp wrote: post #568
jshen wrote: post #554

Earlier quoted context omitted.

I've been coding for decades. I've written large scale systems in functional languages. I was a believer, but after many years of experience, I didn't find it to add a whole lot of value. I didn't find that there were fewer bugs as promised, it wasn't faster to develop and ship features, and most importantly, it was hard to jump into other peoples code and make sense of it. You might have a different opinion, that's…

Apparently the Go team has themselves admitted that we are right and they were wrong. Go is open source, create your own fork without generics and lets see which version keeps going.

We must be talking past each other, and maybe we don't disagree all that much. I'm not talking about generics in this form, and I think the Go team did a good job in their approach and implementation. However, you can read in this thread many people that are demanding more, specifically with the generics implementation. It's not good enough because you can't create monads, do purely functional programming, etc.

I'm hopeful that this implementation is hitting the sweat spot, and that the Go team won't chase the demands to make Go like many of the other languages. I think the biggest win for Go is not having class based inheritance. Fortunately, I haven't seen anyone demanding that.

Post reply on HN