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

181–190 of 277 posts

Re: Go 1.27

#181

Post by sneak »

abtinf wrote: post #84
IshKebab wrote: post #73

Earlier quoted context omitted.

That must be why traffic lights and electrical wires and transit maps are all black and white...

That’s an interesting point. The reason traffic lights are colored is because they are showing distinct states of the same thing and the color is the means of differentiating. Same for transit maps: different routes are colored to distinguish them from other routes, which is especially useful if they overlap. But that’s not what syntax highlighting does. The equivalent of your examples would be to not highlight the s…

There are a bunch of identical things on my screen called lines. They contain a bunch of mostly identical things called tokens. Syntax highlighting uses different colors to identify the different purposes of all of these tokens blasted onto my screen.

Re: Go 1.27

#183

Post by dekdrop »

dvt wrote: post #54
jeremyloy_wt wrote: post #49

Earlier quoted context omitted.

I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts

One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He's a super cool and nice guy. I don't really write that much Go anymore, but it was a fun & cute language when it first came out.

I once wrote him an email asking what font was used in the plan9 papers. He replied. It's Lucida Sans Unicode. He even provided a url to paper published by the maker of the font.

Re: Go 1.27

#184

Post by dolmen »

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.

Go features cleaner crypto APIs (than OpenSSL for example) with less footguns.

Re: Go 1.27

#185

Post by pjmlp »

amiga386 wrote: post #180
pjmlp wrote: post #158

Struct literal changes while welcomed, have the issue of being a possible source of bugs, if there are overlapping fields, type Habitat struct { Burrow string } type Gopher struct { Name string Burrow string Habitat } It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code. https://go.dev/play/p/dsY6tK5S8Ie Better generics and improved SI…

Go has had this behaviour for promoting fields ( provided they don't clash ) for some time, this is just extending the language feature to initialisers. Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity. https://go.dev/ref/spec#Comp…

Which error?

https://go.dev/play/p/CFWVXkFBOEX

Note that I added a name field to Line.

    Data:  {edge black}  --  {{edge black} {{ } 0 0 0} {{ } 0 0 0} diagonal}
Oops now Object.name is empty, which is my point.

Re: Go 1.27

#186

Post by dolmen »

markusw wrote: post #159
semiquaver wrote: post #94

Earlier quoted context omitted.

Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.

Yeah, I would have gone with uuid.V4 or something. But oh well, as long as it works. :D

V4 or V7 are just how you initialize them (constructor), but then this the same representation, so they don't need specific types.

Re: Go 1.27

#187

Post by dolmen »

e4m2 wrote: post #31

Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...

I seriously wonder why this isn't mentioned in release notes.

Re: Go 1.27

#188

Post by nopurpose »

abtinf wrote: post #84
IshKebab wrote: post #73

Earlier quoted context omitted.

That must be why traffic lights and electrical wires and transit maps are all black and white...

That’s an interesting point. The reason traffic lights are colored is because they are showing distinct states of the same thing and the color is the means of differentiating. Same for transit maps: different routes are colored to distinguish them from other routes, which is especially useful if they overlap. But that’s not what syntax highlighting does. The equivalent of your examples would be to not highlight the s…

> The reason traffic lights are colored is because they are showing distinct states of the same thing and the color is the means of differentiating

I wonder if traffic lights were invented today, would it be just one light changing colour?

Re: Go 1.27

#189

Post by amiga386 »

pjmlp wrote: post #185
amiga386 wrote: post #180

Earlier quoted context omitted.

Go has had this behaviour for promoting fields ( provided they don't clash ) for some time, this is just extending the language feature to initialisers. Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity. https://go.dev/ref/spec#Comp…

Which error? https://go.dev/play/p/CFWVXkFBOEX Note that I added a name field to Line. Data: {edge black} -- {{edge black} {{ } 0 0 0} {{ } 0 0 0} diagonal} Oops now Object.name is empty, which is my point.

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

Re: Go 1.27

#190

Post by dolmen »

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

Post reply on HN