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

Go 1.27

go.dev

Post reply on HN
Print view View original

201–210 of 277 posts

Re: Go 1.27

#201

Post by amiga386 »

pjmlp wrote: post #193
amiga386 wrote: post #189

Earlier quoted context omitted.

./prog.go:20:29: cannot specify promoted field name and enclosing embedded field Object Which is what you get if you don't add a direct "name" field to Line, because it's then completely unambiguous, the deeper "name"s are not promotable.

Yeah, but that isn't what I am talking about. The whole point is the implicit bug, when the field is added and initialisation code rewritten to take advantage of this feature, without the developer realising the clash in first place.

I'm not sure what I can say. One man's "source of bugs" is another man's "convenient syntax".

The rule errs in favour of the developer and the struct they can see. Initialising (or accessing!) a named field always picks the one in the top-level struct if you have one there. It'll be there because you added it. Promoted fields can only get promoted if they are unambiguous.

If you don't want to take advantage of that, you can write in full:

    g := Gopher{
        Name:    "Gopher",
        Burrow:  "Burrow #42",
        Habitat: Habitat{Burrow: "Wild Acres"},
    }
    fmt.Println("Your burrow: ", g.Burrow)
    fmt.Println("I mean your _real_ burrow: ", g.Habitat.Burrow)
... but most Go programmers would look at the fact you named two fields the same and then nested them as an unforced error, a rookie mistake.

Most of them are very happy that they can embed some other type they don't know the full contents of, knowing they can access (and now initialise!) fields in it they care about, and thus don't give the fields in their own types the same name, while resting assured that if that other type later gains new fields they've never heard of, it's not going to clash with their own naming choices and break their code and force them to rename something. Their types' field names always come out on top, in their code.

You're doing "but what if I deliberately named my type's fields the same as the embedded type's fields?", which is like "but what if I deliberately stuck my hand in the meat grinder?" -- don't do that

Re: Go 1.27

#202

Post by Cthulhu_ »

xavdid wrote: post #57

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

I get the why, kind of - if you need colors to make sense of code, maybe the code isn't clear enough. If you send blobs of code through email and other systems that don't necessarily have syntax highlighting, it also makes sense. But on a website, whyever not?

Personally I can't say when I was last actually aware of syntax highlighting. The only time I'm actively engaged with it is to change the default low contrast comment color that a lot of themes have (for some reason, as if comments are unimportant / noise) to something better. For Go, I don't really notice when it has or doesn't have syntax highlighting, at least not on e.g. go's website.

Re: Go 1.27

#203

Post by saturn_vk »

dotwaffle wrote: post #116
jeremyjh wrote: post #92

Earlier quoted context omitted.

What is childish is holding up one guy's editor preferences as a religious sacrament when 99.9% of your readers have different preferences.

Well, there's kind of a precedent at least... > Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.

That's been a major success

Re: Go 1.27

#204

Post by thiht »

nasretdinov wrote: post #148
tyho wrote: post #33

The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well. Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.

I still believe that SIMD support is one of the most underrated new features in Go. It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case. So SIMD not only increases performance on i…

Are rewrites from Go to Rust for performance reasons really that common?

Re: Go 1.27

#207

Post by Retr0id »

amelius wrote: post #175
Retr0id wrote: post #82

Earlier quoted context omitted.

I don't know about mail clients, but it's in most web browsers already.

Then I'm wondering why they don't simply use the same crypto libraries as the web browsers.

Chromium uses BoringSSL, which opens its readme as follows:

> BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

> Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

OpenSSL itself is a clusterfuck that doesn't really meet anyone's needs: https://cryptography.io/en/latest/statements/state-of-openss...

Re: Go 1.27

#208

Post by amiga386 »

dolmen wrote: post #190
xavdid wrote: post #57

I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.

The Go official web site doesn't even use the Go fonts: https://go.dev/blog/go-fonts I wonder if the Go fonts has been created just to get a trademark on the "Go" word...

The Go language is by itself more than enough to get a trademark. They only additional thing you can do with a font is get a design patent... for the font.

It's more likely that they don't feel the need to use the font they gave you (for your code editor) on code samples on their own web pages. As it's a custom font, the text would be susceptible to pop-in, or would visibly switch from one font to another, both of which are ugly.

Their CSS says this:

    #blog .Article[data-slug='/blog/go-fonts'] code {
      font-family: 'Go Mono', monospace;
    }
    #blog pre,
    #blog code {
      font-family: monospace;
    }
So they have no specific font preference for code samples, they only show their Go-specific font on the blog post about it. They prefer fast loading and no jank over custom font.

EDIT: just force reload https://go.dev/blog/go-fonts and look at the first hyperlink, "golang.org/x/exp/shiny". Watch it visibly switch from generic monospace font to Go Mono as the page loads. Janky! They probably don't want that for all their code samples ever.

Re: Go 1.27

#209

Post by pjmlp »

amiga386 wrote: post #201
pjmlp wrote: post #193

Earlier quoted context omitted.

Yeah, but that isn't what I am talking about. The whole point is the implicit bug, when the field is added and initialisation code rewritten to take advantage of this feature, without the developer realising the clash in first place.

I'm not sure what I can say. One man's "source of bugs" is another man's "convenient syntax". The rule errs in favour of the developer and the struct they can see. Initialising (or accessing!) a named field always picks the one in the top-level struct if you have one there. It'll be there because you added it. Promoted fields can only get promoted if they are unambiguous. If you don't want to take advantage of that,…

The only, single, complaint is that this possible source of bugs should be part of go vet, just like in other programming languages static analysis tooling, Sonar, PVS, clang-tidy, Roslyn, Checkstyle, clippy, PMD,.... catch such kind of flaws.

However I see that I crash again in the Go versus other programming languages ecosystems mindset.

Re: Go 1.27

#210

Post by saghm »

kqp wrote: post #140
stryan wrote: post #103

Earlier quoted context omitted.

"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.

Yes but only one of them makes most people who hear it think you don’t know the expression you’re trying to use. There’s no objective reason it has to be this way, but it is, and at least personally I appreciate being told when I’ve got something stuck to my back.

I don't really know why I should care what expression I'm trying to use (or what someone else is trying to use) as long as the intent is understood. If anything, people who are needlessly pedantic about the way I express things that they clearly understood are people I'm happy to get signal from so that I can minimize my need to interact with them going forward; it's much nicer to find out from something inane like this than to wait until we have a communication problem about something actually important.
Post reply on HN