Just fucking use the language your colleagues can understand and support for the next few years.
Just fucking use the language with the framework and tooling you need to get your job done efficiently and effectively, and one at the appropriate level of abstraction for the project.
Just fucking use the language which AI agents can read and write well, because we're in the End Times and this stuff matters.
Just fucking use the language with great testing and CI/CD support because you'll be spending longer supporting your code than writing it.
The skill is choosing well, and a key realisation is that it's never a one-size-fits-all thing. That's why an article like this is less than helpful, gosh darn it.
Citation needed. Go's fat binaries and big stdlib cause most enterprise-mandated CVE scanners to light up with zillions of false positives constantly, because too much shit is present in the binary.
Logger package technically could speak protobuf over gopher, even though you use it to write text to syslog? Congrats, gopher and protobuf ecosystems are compiled in, with their vulnerabilities! Multiply that by every single golang binary anywhere in your system (seriously, I was getting CVE alerts for un-hardened stdlib cryptography in a 50loc file copying backup tool that could have been a shell script, and audio format conversion buffer underflow CVEs for Traefik, and many many more for months) and it adds up to a pain in the ass.
And heaven help you if you do actually have a vuln in third-party software that needs to be patched without an upstream fix (usually because "upstream doesn't make distributions on golang-$LATEST or $TRANSITIVE-$LATEST and they have a roadmap item to do that next millenium"). You can't install an updated transitive and fix it, you have to recompile and somehow distribute the whole thing. Doing that is never as simple as "go build" for big projects: the remaining 20% of build/toolchain needs that Go itself doesn't cover are inevitably fulfilled by the same pile of it-works-on-the-maintainer's-machine rickety Makefile bullshit we always had, but without even the sanity and conventions of autoconf and friends--and yeah, building others' Go projects in anger/in a hurry is enough of a pain in the ass that it makes me miss fucking autoconf.
On balance, I like Go. And there's a lot to hate about dynamic linking and package manager hell. But Go's approach is definitely not without its drawbacks in the CVE/security space.
I would not consider anything else without a good reason and especially never going for Javascript or TypeScript for anything server related.
You cose something and if you don't use some weird 3rd party packages (Go stdlib is quite complete) you can check that code again in 3 years and will still work.
so Go + Templ + HTMX (aka the GOTH stack)
Or, if you prefer more of a power tools feel, then HTMX and Raku in functional style (https://harcstack.org) maybe to your liking. Which I call the Crotch Rocket of the programming world.
- https://raku.org (dog-fooding)
- https://harcstack.org
- https://cragcli.info
OCaml?
That's a DoS attack in the python world.