Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.
Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?
Think about what you are doing and choose appropriately. This was true before LLMs.
Token use didn't seem to be a criteria from my casual reading, but maybe you can illuminate me what section pointed to that, I may have been too superficial in my reading
> Is it better than zig if you are outputting minimal wasm deliverables?
Which tradeoffs are you willing to accept? Zig (along with several other languages) is superior in a lot of ways for that type of job, but I still settled on Go for a particular minimal WASM (browser) project. It wasn't my first choice, but it was where I ended up because LLMs kept going out to lunch in other languages and I didn't have anywhere close to the required budget to write it by hand. I read some comments like these about Go in the past so the Go attempt was mostly a contrarian Hail Mary after so many previous failed attempts in more technically well suited languages and... it worked! Shockingly well.
It still isn't my first choice for it, but having something useful with happy users beats technical imperfection every day of the week as far as my needs go. Go really did show its worth as an LLM target for that particular workload. Whether or not that is reproducible for any other project remains to be seen, but there seems to be a growing sentiment that echos the same. There just might be something to it.
the Go runtime comes along for the ride when producing a wasm file, if you are interested in "minimal" (as in small or without extra cruft) then languages that do not require such a thing might be more adequate
Tinygo's base runtime is only around 10kb. It was minimal enough for my needs. gc's runtime would have been a non-starter for that task, to be fair, but Go isn't an implementation. It is, quite explicitly, a language.
There are language implementations that would have been more minimal than that, sure, but there was no obvious way to get LLMs into alignment. I tried. Multiple times. When I switched to Go, it just worked. It may not be technical perfection, but it let me ship something I had almost given up on and it has satisfied users. The tradeoff was worthwhile for my needs. That tradeoff may not be acceptable in all cases. Hence what is best being meaningless without at least defining which tradeoffs you are willing to accept.
Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C.
> more Go-like or adjacent
It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use it to compile their C code. There is usually a little grace given.
It is not like Solod that is Go-like but trying to do something quite different. Tinygo is intended to be a proper Go compiler implementation and has achieved that, aside from the recover situation.
> 10KB still matters a lot in a lot of minimal target/usage scenarios
But, of course, if the LLM cannot wrangle the language then it doesn't matter. Nobody cares how large or small your program is if you never ship it. That only matters if you are using LLMs, but since that's what we have always been talking about...
Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.
I regret not going with bash or even sh when I had the chance. Nothing beats that for ubiquity and getting shit done.
Go is behind, specifically, you have no guarantees that a given machine has Go installed, and doing stuff like gluing commands together, inspecting some files, pipe output around, or automate the boring thing in 30 seconds.
Sure Go beats bash or sh when the thing you are doing starts to become real software, but that is a problem that sits between the chair and the keyboard.
That kept me away from the rewrite, but actually you can just throw a bin onto your server. At least for all my servers, I can do that. Migrating to Go helped me clean like hundreds of scripts into just a handful (tens) of slightly more complex, but unified programs with shared logic. I kept sticking to bash, not realising the complexity grew up already, and having a pile of simple scripts isn’t as simple as I thought. Go solved this beautifully, all the scripts were rewritten within just a month (with Claude assistance, but I’ve been checking on the code, it was OK), and now I can maintain them with less mental overhead.
Most of the time I use go build, or precisely make install with custom Makefile. For the one-time ad-hoc tools (vibe coded, by the way), I may use go run. My point is use the simplest tool, if it’s a little bit more complex than a few lines, it’s better in Go than bash. Here, I rather mean it’s better in any real programming language. Just… well, Go is really simple and with some GPT assistance you may be just one prompt and a minute away from automating some routine tasks. I try to automate as much as I can notice. E.g. I have a special script (now program) which moves files and directories from one location (synced documents) to another (archive on a disk). This is just a very simple operation, but doing it automatically feels very different. I’d highly recommend on trying something similar. Previously, I thought bash is good enough for this (and it is!), but Go is just better for me personally. And bonus thing, it works much faster.
Not sure if it's obvious, but "go run" is just a thin wrapper around "go build" which compiles your Go code to a temporary location and then runs it in a single step.
The article is about which tool is more appropriate, and you're dodging that question. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like if you're writing a typical web API backend with LLM assistance from scratch, which do you use between JS, Py, Java, Go, Rust, etc?
Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?
Think about what you are doing and choose appropriately. This was true before LLMs.
Are you having fun? Chose LISP then