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.
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.
Opus and Sonnett practically writes the same idiomatic elixir (phoenix, mind you) code that I would have written myself, with few edits.
It's scary good.
That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).
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~
On concurrency, Go has the bolts screwed in; it basically was 'lets reuse everything we can from Plan9 into a multiplatform language'.
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).
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.