Specifically the problem here is automated reformatting. Gopls typically does this on save as you are editing, but it is good practice for your CI system to enforce the invariant that all merged *.go files are canonically formatted. This ensures that the user who makes a change formats it (and is blamed for that line), instead of the hapless next person to touch some other spot in that file. It also reduces merge conflicts.
But there's a second big (bigger) problem with this approach: you can't use a go.mod file in a one-off script, and that means you can't specify versions of your dependencies, which undermines the appeal to compatibility that motivated your post:
> The primary benefit of go-scripting is [...] and compatibility guarantees. While most languages aims to be backwards compatible, go has this a core feature. The "go-scripts" you write will not stop working as long as you use go version 1.*, which is perfect for a corporate environment.
> In addition to this, the compatibility guarantees makes it much easier to share "scripts". As long as the receiving end has the latest version of go, the script will run on any OS for tens of years in the future.
Yes, but so do your coworkers? Do you complain about every PR you need to read? Are they all compressed diamonds of pure genious, not a single missed character or unoptimised function? Not a bad or suboptimal decision in sight?
If so, shoot me a mail, I want to work where you're working =)
Edit: I was mistaken, confusing coal and petroleum. While petroleum comes from microscopic ocean life, coal forms from the remains of terrestrial plants.
England “gave up” scientific and technological leadership during the 20th century. (That’s a tongue-in-cheek take on it, don’t read too much into it.)
Was forced to give up, due to the economic devastation of WWII, might be more accurate (though of course there were other factors too).
Man that cracks me up.