Live data from Hacker News

Go 1.27

go.dev

161–170 of 277 posts

Re: Go 1.27

#161

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.

Having worked a couple of greenfield go shops post generics, it’s still quite rare to find them in first party code. They’re just not that useful outside of library APIs. Proper algebraic data types would be a huge game changer.

Re: Go 1.27

#162

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

Just as a linter config though?

Re: Go 1.27

#163
post #156

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

Non-cooperatively terminating a shared-memory thread is an inherently unsafe thing to do, and basically every runtime that has an API for it regards it as a design mistake. See, e.g., https://docs.oracle.com/javase/8/docs/technotes/guides/concu... and https://learn.microsoft.com/en-us/windows/win32/api/processt.... (POSIX's pthread_cancel is somewhat different, and avoids some of the worst failure modes, but at the cost of not actually consistently killing the thread when you call it—and it still has a lot of problems besides that.) So I don't think Go is ever going to add this, nor should it.

(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

#164

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.

I like to alternate. or use constructions that make it ambiguous.

Re: Go 1.27

#165
post #6

FYI golangci-lint and gopls are both broken if you try using generic methods.

I’ve been able to run golangci-lint locally just fine.

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.

[1] https://github.com/golangci/golangci-lint/issues/6643

Re: Go 1.27

#166
post #37

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

[deleted]

Re: Go 1.27

#167
post #120

Earlier 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…

> because otherwise, he sounds insufferable

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

#168
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…

I'd say it is as expected https://go.dev/play/p/sy6SMrOiw4y

Re: Go 1.27

#169

Earlier 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?

The “runtime” as in the compiler runtime which provides the scheduler, garbage collector, etc.

Re: Go 1.27

#170
post #103

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

no

see also https://www.reddit.com/r/BoneAppleTea/

Post reply on HN