I wonder if you could make a language that is NOT backward compatible if you develop a tool like this alongside it.
Using go fix to modernize Go code
51–60 of 97 posts
Re: Using go fix to modernize Go code
#52I 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?
[deleted]
Re: Using go fix to modernize Go code
#53I 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…
[deleted]
Re: Using go fix to modernize Go code
#54I 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…
eslint had `--fix` since like 10 years, so this is not exactly new.
Lebab too: https://lebab.github.io/
Re: Using go fix to modernize Go code
#55Go and its long established conventions and tools continues to be a massive boon to my agentic coding. We have `go run main.go` as the convention to boot every apps dev environment, with support for multiple work trees, central config management, a pre-migrated database and more. Makes it easy and fast to dev and test many versions of an app at once. See https://github.com/housecat-inc/cheetah for the shared tool for…
And the screamingly fast compilation speed is a boon to fast LLM iterations as well.
Re: Using go fix to modernize Go code
#56Earlier 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).
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 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~
Re: Using go fix to modernize Go code
#57[dead]
Re: Using go fix to modernize Go code
#58Self-service analyzers! This will be huge for big libraries and I can imagine heavily used by infra folks (although they could use analyzers already).
Re: Using go fix to modernize Go code
#59Earlier 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.
We've finally figured out how to spread ossification from network protocols to programming languages! \o/
Re: Using go fix to modernize Go code
#60Earlier quoted context omitted.
The use of LLMs will lead to homogeneous, middling code.
Middling code should not exist. Boilerplate code should not exist. For some reason we're suddenly accepting code-gen as SOP instead of building a layer of abstraction on top of the too-onerous layer we're currently building at. Prior generations of software development would see a too-onerous layer and build tools to abstract to a higher level, this generation seems stuck in an idea that we just need tooling to gener…
[dead]