Live data from Hacker News

Go 1.27

go.dev

211–220 of 277 posts

Re: Go 1.27

#211
post #108

Earlier quoted context omitted.

bold-faced lie is just the usual English drift that was actually questioned as incorrect when it first surfaced. If a lie is bold, you don't have to suggest that the user's face is bold when doing it. You can in thirty seconds of google searching find numerous sources explaining that "bold-faced" is a malapropism.

It's the usual English drift perhaps, but "bold faced lie" has been used since the 17th century, which is also apparent from "thirty seconds of Google searching". Three hundred years is enough usage for me to count it as correct. On a side note, "bold faced" does not mean the persons face is bold, only that it is said boldly, which implies a level of rudeness that "bald-faced" or "bare-faced" does not.

That it has been used does not imply it was used equivalently, or with the same acceptance.

You're probably referencing https://english.stackexchange.com/questions/137551/bald-face... — but see in particular the "Update" section of the top answer.

Modern references seem to align (for instance, Garner's): Bald-faced and bare-faced have slightly different connotation than bold-faced. Despite "bold-faced lie" being in somewhat common use, "bald-faced lie" is more common (over 2x according to google stats), and overwhelmingly agreed upon as the "literate" choice, unless an author intends to refer to the sort of lie that would headline an article.

Re: Go 1.27

#212
post #108

Earlier quoted context omitted.

It's the usual English drift perhaps, but "bold faced lie" has been used since the 17th century, which is also apparent from "thirty seconds of Google searching". Three hundred years is enough usage for me to count it as correct. On a side note, "bold faced" does not mean the persons face is bold, only that it is said boldly, which implies a level of rudeness that "bald-faced" or "bare-faced" does not.

Colloquialisms and slang have unstable meaning over history, location, and cultures. Generally, something to be avoided by people striving for clearer communication. =3

> Generally, something to be avoided by people striving for clearer communication

Their communication seemed pretty clear to me. If anyone actually claims that they didn't understand what they meant but would have understood it by using the other form of the expression, I think that's a bold-faced lie.

Re: Go 1.27

#213
post #196
post #176

Earlier quoted context omitted.

Do we know if Go team is working in 2.0 release?

We know they aren't. They have successfully been able to add major features such as generics without breaking 1.0 compatibility, and the trend is to continue than way. Well there is no major language feature in sight in fact. Also major figures of the Go team (Russ, Ian, Rob, Ken) are gone.

Oh I somehow completely missed Russ left. I was rather hoping there will be a version 2 from all the lessons they have learned.

Re: Go 1.27

#214

Earlier quoted context omitted.

In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.

They are also lying, it is an Italics-Faced lie ... thank you, I will see myself out. =3

If we wanted to make things really clear, we'd use strikethrough text for the lies!

Re: Go 1.27

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

Can just pass it a context, cancel the context, and handle for it in the goroutine.

Re: Go 1.27

#216
post #179

Earlier quoted context omitted.

I think that's a no-go because vet checks have no-false-positive policy. Ie, when go vet flags something, its a bug.

I would say that initialising the wrong field because a dev is unaware of a clash between Gopher.Burrow and Gopher.Habitat.Burrow (naturally in more complex code), when upgrading to 1.27 and taking advantage of the feature without realising it, is a bug.

Well either way, these things usually land in golangci-lint first and get promoted if they're deemed useful enough.

Re: Go 1.27

#217

I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.

This was my original take when I learned the language, but I later realised “errors as values” is one of the strengths of the language.

I have run both Go and Python backends in production for years. There is an entire class of bugs present in Python services (missing error handling) that simply does not happen in my Go services.

Python puts the burden of knowing what exception types a function call will raise on the caller, in Go I just check for err. Even if I do not anticipate every failure mode the Go call will raise, I will always log the error and handle it in a controlled manner. I couldn’t count the number of times I’ve encountered an unhandled exception in my Python code, and often in such a case the logging will be lacklustre because you will just see a huge stack trace, but lose the contextual logging I would have automatically added in Go.

Perhaps a syntactic sugar is in order to reduce verbosity.

Re: Go 1.27

#218
post #33

The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well. Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.

I still believe that SIMD support is one of the most underrated new features in Go. It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case. So SIMD not only increases performance on i…

Odin solves this by letting you declare all arrays as either normal (AoS) or SoA, which helps with this use case a lot. Otherwise very similar ideas, except all the memory goodies. Underrated language!

Re: Go 1.27

#219
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've missed something - what were you expecting from that code? Would anyone expect the `Burrow` inside the `Habitat` to be initialised instead of the top-level `Burrow`?

Re: Go 1.27

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

That's why we called ours uu.ID

https://pkg.go.dev/github.com/domonda/go-types@v0.0.0-202607...

Post reply on HN