News for hackers. Stuff that matters.
Re:Using go fix to modernize Go code by Jyaif on Tuesday February 17, 2026 @02:54PM (#47052319)
> a subtle data race and a rare deadlock

That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).

Re:Using go fix to modernize Go code by kbolino on Tuesday February 17, 2026 @04:09PM (#47053387)
Go has a pretty good race detector already, and all it (usually) takes to enable it is passing the -race flag to go build/test/run/etc.
Re:Using go fix to modernize Go code by awesome_dude on Tuesday February 17, 2026 @03:43PM (#47053047)
You should be using rust... mm kay :\
Re:Using go fix to modernize Go code by danudey on Tuesday February 17, 2026 @06:36PM (#47055030)
Doing concurrency in Rust was more complex (though not overly so) than doing it in Golang was, but the fact that the compiler will outright not let me pass mutable refs to each thread does make me feel more comfortable about doing so at all.

Meanwhile I copy-pasted a Python async TaskGroup example from the docs and still found that, despite using a TaskGroup which is specifically designed to await every task and only return once all are done, it returned the instant theloop was completed and tasks were created and then the program exited without having done any of the work.

Concurrency woo~

Re:Using go fix to modernize Go code by awesome_dude on Tuesday February 17, 2026 @10:57PM (#47056982)
The person I was replying to sounded exactly like the Rust zealots roving the internet trying to convince people to change.
Re:Using go fix to modernize Go code by Groxx on Friday February 20, 2026 @01:33PM (#47091847)
Yeah, I'd really have liked to see something like [Trio](https://trio.readthedocs.io/en/stable/) gain mid more attention in Python. Structured approaches can prevent a huge amount of those issues, and Python code is absolutely riddled with concurrency problems in my experience. Much more so in practice than other languages except maybe javascript (when including async ordering mistakes). It makes it a real nightmare to try to build anything actually reliable.
Re:Using go fix to modernize Go code by anthk on Wednesday February 18, 2026 @01:49AM (#47058024)
So you are trying to explain concurrency to the folks who implemented CSP in both Plan9 and Go. Interesting. I should return "cspbook.pdf" back.
Re:Using go fix to modernize Go code by awesome_dude on Wednesday February 18, 2026 @02:10AM (#47058156)
One day, maybe today, you will learn to read
Re:Using go fix to modernize Go code by anthk on Wednesday February 18, 2026 @02:41AM (#47058345)
(eval) rather than (read), then.

On concurrency, Go has the bolts screwed in; it basically was 'lets reuse everything we can from Plan9 into a multiplatform language'.

Re:Using go fix to modernize Go code by Thaxll on Tuesday February 17, 2026 @07:37PM (#47055519)
No language protects from dead lock.
Re:Using go fix to modernize Go code by Jyaif on Wednesday February 18, 2026 @08:10AM (#47060566)
I probably agree that they don't protect you from all deadlocks, but some languages protect you from some dead locks.
Re:Using go fix to modernize Go code by Groxx on Friday February 20, 2026 @01:14PM (#47091610)
Not true! There are a fair number of them, and they're even reasonably general-purpose, e.g. https://www.ponylang.io/

Most that can recall achieve this by simply not having any locks at all. That's feasible with some careful design.

Outside proof-oriented languages though, I'm not aware of any that prevent livelocks, much less both. When excluding stuff that's single threaded but might otherwise qualify, e.g. Elm. "Lack of progress" is what most care about though, and yeah that realm is much more "you give up too much to get that guarantee" in nearly all cases (e.g. no turing completeness).

Re:Using go fix to modernize Go code by aktau on Wednesday February 18, 2026 @05:34AM (#47059552)
For Go, there is https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks. There are some missing things from C++ Thread Safety annotations, but those could be added.