deleted
reply> a subtle data race and a rare deadlock
replyThat's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).
No language protects from dead lock.
replyGo 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.
replyYou should be using rust... mm kay :\
replyDoing 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.
replyMeanwhile 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~
Good use case for Elixir. Apparently it performs best across all programming languages with LLM completions and its concurrency model is ideal too.
replyThis is the exact opposite of my experience.
replyClaude 4.6 has been excellent with Go, and truly incompetent with Elixir, to the point where I would have serious concerns about choosing Elixir for a new project.
Shouldn't you have concerns picking Claude 4.6 for your next project if it produces subpar elixer code? Cheapy shot perhaps, but I have a feeling exotic languages will remain more exotic longer now that LLM aided development is becoming the norm.
replyWe've finally figured out how to spread ossification from network protocols to programming languages! \o/
reply