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

281–290 of 614 posts

Re: Go 1.18

#281

Post by SureshG »

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…

> None with the same performance characteristics,

Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.

Re: Go 1.18

#282

Post by philosopher1234 »

mcronce wrote: post #240
throwaway894345 wrote: post #165

Earlier quoted context omitted.

> Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go. I could say the same about many of Go's critics, but I don't because that wouldn't be constructive. Rather than taking undue offense at my comment, why not articulate a counterexample to prove that there are valid reasons why a person (rather tha…

> 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.

>At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.

This justifies anything popular, including things that are now universally seen as bad, but once were popular.

Re: Go 1.18

#283

Post by meetups323 »

unfunco wrote: post #255
meetups323 wrote: post #244

Earlier quoted context omitted.

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?

Not in the standard library in general, but in the testing package it's the convention. There's testing.B, testing.M, testing.T, and testing.F, and *testing.TB. https://pkg.go.dev/testing#pkg-types

Well that's a hard pass from me. I always knew go was quick to compile, I didn't know the lengths they were willing to go to achieve that!

Case in point: it's not TB, as you stated, but rather PB.

Re: Go 1.18

#284

Post by dimgl »

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-good-the-bad-the-...

Re: Go 1.18

#285

Post by tomohawk »

AaronFriel wrote: post #64

My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to…

Your campaign to get this fix put in should be required reading for anyone involved in open source. A lot of lessons to be learned there.

Re: Go 1.18

#286

Post by stouset »

cdelsolar wrote: post #257
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…

should be == 0? I don't like the Ruby example myself.

Should be >= 20.

Whether or not you like the Ruby version is beside my point, which is that which one of those is "more complicated" is a matter of perspective. The Ruby one is almost strictly a wrapper around the golang one so it does add absolute complexity. But the golang one is relatively more complex, because the Ruby version uses higher-level equivalents, and those abstractions are good enough that I don't ever have to actually reason about what happens underneath the covers.

Put another way, even the golang version is an abstraction around an absolutely massive amount of hardware and electrical engineering complexity that you virtually never have to think about. The absolute complexity of what happens when you compile and execute those instructions is extreme to the point that no single human or even room of humans collectively fully knows what's going on. And yet we manage just fine.

Or, I love this example:

    admin_usernames = users.select(&:admin?).map(&:username)
Versus

    adminUsernames := make([]string, len(users))
    for i, user := range users {
        if user.isAdmin {
            userNames = append(userNames, user.Name)
        }
    }
Again, spot the bug!

Re: Go 1.18

#287

Post by preseinger »

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.

Re: Go 1.18

#288

Post by scns »

quaunaut wrote: post #43
candiddevmike wrote: post #38

Earlier quoted context omitted.

I think Go's criticisms come from elitism more than anything--folks can't flex their algebraic programming muscles and instead have to do error checking inline or do some WET things due to lack of generics like some amateur. To me, Go is never the wrong choice, but it may not be the best choice for some projects.

I'm not sure it's elitism to be looking for type-system features that are well-over a decade old and generally non-controversial and considered vast positives. I don't think they necessarily need to go crazy in this regard(as simplicity is one of Go's best strengths), but I don't think it's elitism.

> Algebraic data types were introduced in Hope, a small functional programming language developed in the 1970s at the University of Edinburgh. [0]

It predates Miranda and Haskell and is contemporaneous with ML, also developed at the University. [1]

ML had them too [2]

[0] https://en.wikipedia.org/wiki/Algebraic_data_type#Programmin...

[1] https://en.wikipedia.org/wiki/Hope_(programming_language)

[2] https://en.wikipedia.org/wiki/ML_(programming_language)

edit: add ML

Re: Go 1.18

#289

Post by morelisp »

stingraycharles wrote: post #264
Mawr wrote: post #220

Earlier quoted context omitted.

It is just an assumption on my part, I figure that the cost of pointer chasing is generally going to outweigh any disadvantages. It can also help enable optimizations, for example slices and maps that do not contain pointers do not get scanned by the GC ([1]). [1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...

I fully agree with your approach. The important thing is that the user now has the choice to use a pointer or not: they can always use a pointer to the optional if they want to use pointers. Pointers to pointers are generally something you try to avoid if possible.

> the user now has the choice to use a pointer or not

But any benefits of the packing are gone whether I make a pointer or not.

And either way, no nested pointers are involved. We’re not taking pointers to options in either case.

Re: Go 1.18

#290

Post by munificent »

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…

There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.
Post reply on HN