Live data from Hacker News

Go 1.27

go.dev

151–160 of 277 posts

Re: Go 1.27

#151
post #84

Earlier quoted context omitted.

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…

Your comment makes me think of LabVIEW - if you're not familiar with it, it uses a visual programming language ("G") in which data flows down wires. The color of the wire indicates the wire's data type (blue for ints, orange for floats, green for bools, pink for strings) and the width of the wire indicates the dimensionality of the data (thin line = scalar, thick line = 1D array, double-thick = 2D array). The color i…

I still wonder why every open-source visual programming language is either a toy for teaching or straight up awful, often not implementing but even loops, when LabVIEW has been doing it right for decades.

Despite its huge size and it installing several services that constantly run in the background, it's still one of my favorite "languages" of all time. It's the only one I've ever seen people going from never having programmed before to making simple but meaningful contributions in within a single day.

Re: Go 1.27

#152

Earlier quoted context omitted.

that's an extremely odd explanation and it makes me think that he has some hidden PTSD. it's also insane that one person's preference trumps the rest of the world's.

He also doesn't capitalize his sentences.

Maybe he was talking in private.

Re: Go 1.27

#153
post #63

Earlier quoted context omitted.

That makes sense as a personal preference for him, but it's odd for that to still be the company/project stance. Like, surely he knows he's the minority for not wanting highlighting?

Oceania had always been at war with Eastasia.

Apart from the fact that your comment is against the rules: please don't trivialize that quote. It has a profound meaning, and is completely out of place here.

Re: Go 1.27

#154

Earlier quoted context omitted.

that's an extremely odd explanation and it makes me think that he has some hidden PTSD. it's also insane that one person's preference trumps the rest of the world's.

Welcome to Go as a project.

Born out of C++ trauma apparently, for context

Re: Go 1.27

#155
post #80
post #59

Earlier quoted context omitted.

There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text. I don't know why it's still like that but that's the original reasoning.

I understand and respect this position. I think syntax highlighting is a highly subjective matter, bordering on personal preference with regard to shell interactions, editor configurations, bindings, shortcuts, snippets, and the like. It's also... insignificant somehow, like quibbles over formatting rules that Go settled once and for all with `go fmt`. I often prefer not to enable syntax highlighting just for color.…

> The creators deliberately avoided the questions of IDEs and editors for Go, leaving them to the community. I think the same principle applies here.

Exactly. This is fundamentally about accessibility (in the broadest sense). Do people have opinionated screenreader settings they like to force on others too?

Re: Go 1.27

#156
post #95

does it have goroutine termination, i recently found out you need a runtime patch for it

What exactly do you mean by "goroutine termination"?

I suppose: a "go" returns an id, and then you call kill(id) to terminate it, as if it were a pthread or a process. In which case the answer is: no.

Re: Go 1.27

#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 SIMD are nice additions as well.

Re: Go 1.27

#159
post #48

Earlier quoted context omitted.

The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...

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

Re: Go 1.27

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

When I started learning Go I went all in including using the recommended editor (acme editor) which has no syntax highlighting, no autocomplete and a very different way of writing code. My production went down a lot but the quality of the code went up a lot. I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledge…

I go through intervals of turning autocomplete on and off. I think autocomplete is useful for boilerplate (similarly LLMs are useful for boilerplate), but I prefer not to use either when writing code where correctness is particularly important. This is because it’s easier for me to internalize what something is doing by typing it out. It’s actually more effort for me to understand code by reading it rather than writing it.

I experience something similar with system design, where the act of creating a diagram helps me to understand much faster than trying to read someone else’s diagram. It’s not because only I can create good diagrams (I cannot) but again because the act of creating one helps me internalize the design.

Post reply on HN