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

361–370 of 614 posts

Re: Go 1.18

#361

Post by int_19h »

CraigJPerry wrote: post #341
stouset wrote: post #241

Earlier quoted context omitted.

As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less c…

Generally direct refutation of a central point is a constructive argument. Here’s another example of direct refutation: You’ve given a strawman argument, specifically you’ve given one implementation which has abstracted the details (we don’t see the code for take, select and reduce). That’s just an arbitrary decision you’ve made, the equiv go example you could have posted might be: // idiomatic error handling elided…

> in the worst case we would have repeated definitions of these functions. Code that any junior developer will be able to safely reason about and change

It's also code that many junior developers will forget to change in all the places when they fix a bug in one of them.

Re: Go 1.18

#362

Post by rr808 »

dimgl wrote: post #284
pie_flavor wrote: post #277

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…

Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-goo…

My view is there should be official libraries with generics, but regular developers shouldn't be allowed to write any.

Re: Go 1.18

#363

Post by int_19h »

HideousKojima wrote: post #263
crtc wrote: post #121

Finally! This will be the last day I see the words "Go" "lack of"/"no" and "generics" in one sentence.

I mean in Java vs. C# fights people still bring up that C# generics are reified while Java generics rely on casting and erase type information at runtime, so probably not.

Go dodged that bullet by reifying theirs!

Re: Go 1.18

#364

Post by rr808 »

movedx wrote: post #303
2OEH8eoCRo0 wrote: post #254

Earlier quoted context omitted.

Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s

I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you'v…

Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.

Re: Go 1.18

#365

Post by squeaky-clean »

throwaway894345 wrote: post #332
pie_flavor wrote: post #277

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…

> I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' Who says this? There have been a lot of weird arguments surrounding Go and generics over the last decade, but I’ve never heard anything like this.

As a non-Go user who peaks into threads about major Go updates, this is one of the most commonly repeated things I've read.

Re: Go 1.18

#366

Post by lanstin »

hodgesrm wrote: post #352
codeflo wrote: post #340

Earlier quoted context omitted.

That’s true, a binary tree isn’t a problem, it’s a tool for solving a certain class of problems. Since you can’t build reusable tools in pre-generic Go, (and, to be honest, only a limited set of tools with Go’s new generic system), programmers are forced to reinvent half-baked ad-hoc solutions all over their code base. I once read an article about a C codebase that contained dozens (!) of specialized linked-list impl…

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.

Re: Go 1.18

#367

Post by int_19h »

oxplot wrote: post #138

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only…

Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value.

For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that more time is needed to figure out how to do them "right". And so they waited for a decade, and ended up implementing them in a way that's not fundamentally different from most other languages that had them all along. What, exactly, was gained here to justify the productivity lost while waiting?

I will also add that to someone who knows a few PLs, Go is a very boring language in a sense that there's very little new there, neither in terms of individual parts, nor in terms of how they're combined together. So the notion that this combination is somehow so unique that its evolution is like walking on untested ground doesn't pass the smell test.

Re: Go 1.18

#368

Post by int_19h »

edenlinger wrote: post #80
honkycat wrote: post #4

WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta. This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language. I've been using the https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs. I would really…

I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit s…

It's worth remembering that Java and C# didn't have generics initially. And when they did get them, there was a lot of pushback along the same lines; sometimes almost word-to-word about lost simplicity etc.

18 years later, the C# and Java developers are doing fine.

Re: Go 1.18

#369

Post by int_19h »

RodgerTheGreat wrote: post #199
crtc wrote: post #164

Earlier quoted context omitted.

This is by design: https://go.dev/doc/faq#Does_Go_have_a_ternary_form Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.

> A language needs only one conditional control flow construct. And yet, Go has a switch statement.

And loops!

Re: Go 1.18

#370

Post by didibus »

kaba0 wrote: post #119
didibus wrote: post #69

Earlier quoted context omitted.

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I think the reason Go gets a lot of criticism is that at a language level it misses a lot of constructs and features. So for everything it doesn't have, you'll find someone who is really used to leverage those constructs or features when they program and w…

> since it creates beautifully efficient, small and low memory binaries with cross-compilation, and it has a good set of libraries. Other than good cross-compilation, I really don’t see any of that. Even niche languages that have been around forever hit this exact trio like D. Also, the performance is ain’t that good to begin with, for more complex scenarios the comparatively dumb GC of Go will be a bottleneck, compa…

Cross-compilation is a big deal I'd say, I wouldn't brush it off as insignificant.

Even if I ignore cross-compilation, what other language has easy and fast native compilation, that produces relatively performant and low memory programs, is properly garbage collected, and has a good library ecosystem as well as a good concurrency story?

Post reply on HN