Quarterly reminder that Go still exists.
I can imagine using it for simple web stuff. E.g. its perfect for something like Forgejo. But yeah... Seems like the world has moved on mostly.
Go 1.27
81–90 of 277 posts
Re: Go 1.27
#82Earlier quoted context omitted.
The .NET team have been similarly busy on post-quantum lately, it completely dominated the .NET API reviews for the dotnet 11 release. It seems there's a big push happening behind the scenes.
Ok, but when is it coming to our web browsers and email clients?
Re: Go 1.27
#83> First, generic methods are now supported > Generic functions can now be used without explicit type arguments Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12
Neat, stealing this.
Re: Go 1.27
#84Earlier quoted context omitted.
> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods ( http://en.wikipedia.org/wiki/Cuisenaire_rods ). I grew up and today I use monochromatic numerals. https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
That must be why traffic lights and electrical wires and transit maps are all black and white...
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 syntax at all, but only use color coding to distinguish variables.
The equivalent of how syntax highlighting currently works for your examples would be if the light fixture was one color, and the light pole was another, but then all the actual lights were the same color.
I actually think highlighting only the variables with distinct colors could be extremely valuable. Would certainly help avoid mistakes with nested i/j loop counters.
Edit to add: come to think of it, it would have been even more valuable in Go, until recently anyway. The variable color coding would expose the common loop variable instance bugs, because a programmer would be instantly puzzled by the unexpected coloring.
Re: Go 1.27
#85FYI golangci-lint and gopls are both broken if you try using generic methods.
Re: Go 1.27
#86Nice additions to go. I like to imagine that one day we'll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.
Re: Go 1.27
#87Earlier quoted context omitted.
Ah. This is a bold faced lie. There were plenty of options in 2016. Nist released final candidates in 2024 and published the candidates this year. ssh (as noted in tfa) has had pq defaults since 2022.
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
Re: Go 1.27
#88Re: Go 1.27
#89Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
The original Go team was trying to avoid this:
"Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0]
That team has since moved on, and now Go has begun to join that convergence.
The problem is that most programmers seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby.
[0] https://go.dev/talks/2015/simplicity-is-complicated.slide#5
Re: Go 1.27
#90Earlier 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…
In any case, my analogy was not perfect, but neither was Russ's! The point is it's totally normal and not "childish" to use colours to help distinguish things. Traffic lights do not technically need colours (you can use the position of the lights - I assume that's what badly colourblind people do). Nor do transit maps technically need colours - you could just label the lines, or use patterns.
https://www.flickr.com/photos/gywst/1407078279
It's completely absurd to say that colours are childish because they can help children.