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.

▲

an hour ago | parent | next [-]

[deleted]

▲

Jyaif 2 hours ago | parent | prev | next [-]

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

	▲	kbolino an hour ago \| parent \| next [-]
		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.
	▲	awesome_dude an hour ago \| parent \| prev [-]
		You should be using rust... mm kay :\

▲

brightball 2 hours ago | parent | prev [-]

Good 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/

▲

monooso 31 minutes ago | parent [-]

This 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 18 minutes ago \| parent [-]
		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.