This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics). I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.
Go 1.27
161–170 of 277 posts
Re: Go 1.27
#162Earlier quoted context omitted.
This is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn't count.
You can also add support for exhaustive switches on tags.
Re: Go 1.27
#163Earlier quoted context omitted.
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.
(Having the go statement return a handle that you can block on would of course be completely fine, but at this point they're probably not going to do that either.)
Re: Go 1.27
#164Earlier 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.
Re: Go 1.27
#165FYI golangci-lint and gopls are both broken if you try using generic methods.
However I’ve not had much success running it on CI, with at least the 1.27rcs. I encountered some panic deep within staticcheck, and ended up turning off that specific linter on CI (better than not running it at all).
There was a tracking issue for go1.27 support at [1]. However that is now closed, which might imply that it should be working.
Re: Go 1.27
#166Earlier quoted context omitted.
Tagged unions can be implemented in user code, you dont actually need language support to use them. https://github.com/splizard/tagged
That is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.
Re: Go 1.27
#167Earlier 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...
Wow, that thread is a piece of work > Gofmt was written to reduce the number of pointless discussions about code formatting. It succeeded admirably. I'm sad to say it had no effect whatsoever on the number of pointless discussions about syntax highlighting, or as I prefer to call it, spitzensparken blinkelichtzen. > When I was a child, I used to speak like a child, think like a child, reason like a child; when I beca…
Oh come on, I like syntax highlights, but this is not "insufferable". It's just opinions expressed strongly, with probably some tounge-in-cheek
Re: Go 1.27
#168Struct 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…
Re: Go 1.27
#169Earlier quoted context omitted.
> Generics were always planned, of course ... This is provably incorrect. The position held for many years by the language authors was[0]: Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to t…
> Generics are convenient but they come at a cost in complexity in the type system and run-time. By run-time they mean compile-time? There shouldn't be a run-time penalty right? Also, is there some measure of the additional compilation cost now that generics has been added?
Re: Go 1.27
#170Earlier quoted context omitted.
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
"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.