7 ms·
They're particularly bad about concurrent go code, in my experience - it's almost always tutorial-like stuff, over-simplified and missing error and edge case ha
by Groxx 8mo ago
They're particularly bad about concurrent go code, in my experience - it's almost always tutorial-like stuff, over-simplified and missing error and edge case handling to the point that it's downright dangerous to use... but it routinely slips past review because it seems simple and simple is correct, right? Go concurrency is so easy!
And then you point out issues in a review, so the author feeds it back into an LLM, and code that looks like it handles that case gets added... while also introducing a subtle data race and a rare deadlock.
Very nearly every single time. On all models.
- Jyaif 8mo ago> 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).
- awesome_dude 8mo agoYou should be using rust... mm kay :\
- danudey 8mo agoDoing 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~
- awesome_dude 8mo agoThe person I was replying to sounded exactly like the Rust zealots roving the internet trying to convince people to change.
- deleted 8mo ago[deleted]
- Groxx 8mo agoYeah, I'd really have liked to see something like [Trio](https://trio.readthedocs.io/en/stable/ 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.
- anthk 8mo agoSo you are trying to explain concurrency to the folks who implemented CSP in both Plan9 and Go. Interesting. I should return "cspbook.pdf" back.
- awesome_dude 8mo agoOne day, maybe today, you will learn to read
- anthk 8mo ago(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'.
- kbolino 8mo agoGo 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.
- Thaxll 8mo agoNo language protects from dead lock.
- Jyaif 8mo agoI probably agree that they don't protect you from all deadlocks, but some languages protect you from some dead locks.
- Groxx 8mo agoNot true! There are a fair number of them, and they're even reasonably general-purpose, e.g. https://www.ponylang.io/ 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).
- aktau 8mo agoFor Go, there is https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks. There are some missing things from C++ Thread Safety annotations, but those could be added.
- brightball 8mo agoGood use case for Elixir. Apparently it performs best across all programming languages with LLM completions and its concurrency model is ideal too. https://autocodebench.github.io/ https://autocodebench.github.io/
- monooso 8mo agoThis is the exact opposite of my experience. Claude 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.
- hbogert 8mo agoShouldn'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.
- majewsky 8mo agoWe've finally figured out how to spread ossification from network protocols to programming languages! \o/
- monooso 8mo agoThe specific agent is irrelevant. This is related to a broader personal opinion regarding LLMs and language choice. Before we continue, the following opinion comes with several important caveats: 1. It only applies to paid professional work. If it's a hobby project, choose whatever makes you happy. 2. It ignores the strengths and weaknesses of different languages. These may outweigh any LLM-related concerns. 3. This is my opinion today. I _think_ it will survive longer than the next LLM cycle, but who knows these days. 4. May contain nuts. Okay, that's the ass-covering dispensed with, on to the opinion: If the choice is between a language which is "LLM friendly" (for want of a better phrase) and one which is not, it is irresponsible to choose the latter.
- 8mo ago
- deleted 8mo ago[deleted]