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

331–340 of 614 posts

Re: Go 1.18

#331

Post by zozbot234 »

zinclozenge wrote: post #193
ed25519FUUU wrote: post #131

Earlier quoted context omitted.

Plenty of great functional alternatives to Go.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

A bit offtopic here, but it's a bit weird to see this argument that using .clone() in Rust is "littering" the code. The feature is there for a reason, and using it will still give you vastly more efficient code than in most other languages; quite possibly including Go.

Re: Go 1.18

#332

Post by throwaway894345 »

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.

Re: Go 1.18

#333

Post by pstuart »

ta20200202 wrote: post #311
dimgl wrote: post #284

Earlier quoted context omitted.

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…

> there's a lot of developers that misuse/shouldn't use generics. The same is true for other features, like channels and goroutines.

Over use of channels is new Go coder smell. I certainly was guilty at the beginning.

But goroutines? I see much less abuse there. And they're so damn handy.

Re: Go 1.18

#334

Post by nine_k »

preseinger wrote: post #287
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,…

Problems are not generic. "I need a N-ary binary tree over arbitrary comparable types" is not a problem. Problems are expressed in terms of domain concepts that are unique to the problem space, the organization, the business need. Some _implementation details_ or maybe patterns that can be used to solve those problems may be generic. That's separate.

Some problems are technical problems, posited and solved by engineers.

Solving them helps better solve the product and business "real-world" problems.

Re: Go 1.18

#335

Post by throwaway894345 »

mcronce wrote: post #324
throwaway894345 wrote: post #279

Earlier quoted context omitted.

> All three of these things are subjective. Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities. > At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. Not when there are plenty of people willing to think differently and reap the benefits.

> there’s pretty wide consensus even among Go detractors about these qualities [citation needed] > there are plenty of people willing to think differently and reap the benefits "Reap the benefits" is, again, subjective. It's something you like , not something objectively beneficial or worth the trade-offs in all, most, or even necessarily many projects. This is precisely the unduly arrogant attitude amongst Gophers t…

You’re welcome to disbelieve me on the consensus. I’m not trying to persuade you of anything.

> "Reap the benefits" is, again, subjective. It's something you like, not something objectively beneficial or worth the trade-offs in all, most, or even necessarily many projects.

Of course, productivity isn’t for everyone. Sometimes for personal projects I’ll opt for things that exercise my creativity and cleverness over the purely productive or pragmatic.

> This is precisely the unduly arrogant attitude amongst Gophers that others have already mentioned several times in this thread.

Hah! This made me laugh. Yes, I disagree with you therefore I must be arrogant. (:

Re: Go 1.18

#336

Post by justinsaccount »

grogenaut wrote: post #325
justinsaccount wrote: post #48

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

Did it break anything/uncover anything?

Pretty much, yeah.

I knew I needed some extra sanity checks around input parsing and sanity checking shorter than expected buffers. Fuzzing the function that parsed input caused panics and other errors that I was able to fix by adding bounds/sanity checks in the right places.

Re: Go 1.18

#338

Post by mcronce »

throwaway894345 wrote: post #279
mcronce wrote: post #240

Earlier quoted context omitted.

> simpler, more concrete, more standard code. All three of these things are subjective. > in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to" At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.

> All three of these things are subjective. Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities. > At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. Not when there are plenty of people willing to think differently and reap the benefits.

lol...you even take criticism arrogantly. Impressive. It wasn't a personal attack, it was a statement of fact, but thanks for making my point even more clearly for me - not only in your response to that, but in your assertion that your opinion based on your experience is fact. Appreciated.

Restated: You aren't arrogant because you disagree with me. You're arrogant because the things you say and the way you say them are arrogant.

Re: Go 1.18

#339

Post by throwaway894345 »

mcronce wrote: post #229
throwaway894345 wrote: post #155

Earlier quoted context omitted.

You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics. > Generics also aren't the only useful feature that Go lacks (or, as of today, lacked). Agreed, but it's foolish to frame language debates purely around the presence or absence of useful…

> You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics. Performance only drives one of the two alternatives. > Agreed, but it's foolish to frame language debates purely around the presence or absence of useful features. Many languages have t…

> Performance only drives one of the two alternatives.

Right, so use dynamic dispatch by default.

> Seriously, how many dependency management paradigms have we gone through so far, and the best thing we can come up with is `go mod`?

Agreed that the road to go mod has been tumultuous, but go mod is in the top tier of dependency managers, which is perhaps a sad indictment of dependency managers. Most languages still don’t offer reproducible builds, and several mainstream languages require that you generate your list of dependencies in an imperative DSL—or at least these build systems are the most popular, which brings us to another problem: some languages don’t even have a single standard tool! From dependency managers, let’s look at build tools: how many build completely static binaries by default? How many make you script the build in an imperative DSL? How many punt altogether? How many languages compile to native code in seconds or faster? How many languages can trivially cross-compile virtually any package? How many languages still make you spin up a CI job to build and publish source code packages? How many make you spin up a CI job to build and publish documentation packages? How many support testing out of the box? Benchmarking? Fuzzing? Formatting? Profiling?

As far as I can tell, Go trounces virtually every other language on tooling (Rust seems to do pretty well). One area where ago doesn’t do as well is debugging—I know Go has delve, but I understand it to be limited (haven’t tried it in a long time though to be honest).

Re: Go 1.18

#340

Post by codeflo »

preseinger wrote: post #287
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,…

Problems are not generic. "I need a N-ary binary tree over arbitrary comparable types" is not a problem. Problems are expressed in terms of domain concepts that are unique to the problem space, the organization, the business need. Some _implementation details_ or maybe patterns that can be used to solve those problems may be generic. That's separate.

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 implementations. Large Go codebases, from everything I’ve seen, aren’t all that different.
Post reply on HN