[flagged]
Using go fix to modernize Go code
91–97 of 97 posts
Re: Using go fix to modernize Go code
#92I think tooling that can modify your source code to make it more modern is really cool stuff. OpenRewrite comes to mind for Java, but nothing comes to the top of my mind for other languages. And heck, I into recently learned about OpenRewrite and I've been writing Java for a long time. Even though I don't like Go, I acknowledge that tooling like this built right into the language is a huge deal for language popularit…
Does anyone have experience transforming a typescript codebase this way? Typescript's LSP server is not powerful enough and doesn't support basic things like removing a positional argument from a function (and all call sites). Would jscodeshift work for this? Maybe in conjunction with claude?
ESLint (and typescript-eslint) has the concept of fixers, which updates the source code.
Re: Using go fix to modernize Go code
#93Earlier quoted context omitted.
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.
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.
The 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.
Re: Using go fix to modernize Go code
#94Earlier quoted context omitted.
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.
We live in different realities. 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.
I envy your reality.
Re: Using go fix to modernize Go code
#95Earlier quoted context omitted.
> 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).
No language protects from dead lock.
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
#96Earlier quoted context omitted.
You should be using rust... mm kay :\
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…
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
#97Earlier quoted context omitted.
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…
The person I was replying to sounded exactly like the Rust zealots roving the internet trying to convince people to change.
[deleted]