I used Go once, for a single small project, two years ago. Recently, I was forced to update the single dependency (acme/autocert) in the project due to bugs in it. But Go also had broken backwards compatibility during the last two years, so my project didn't work with the newest version of Go.
My project is a single main.go file. The Go website claimed they wouldn't break compatibility, which is why I tried using Go for the project. Regret.
@sunbather It refused to compile my project unless I turned it into a Go Module, and was directed to a manual on how to learn what Go Modules are and a bunch of philosophical stuff about Unix paths and environment variables and stuff.
My server was inaccessible due to a LetsEncrypt failure and revoked certs (not my fault.) I didn't have time for that BS.
@cancel there isn’t a way to just Go run it? Odd
@sunbather It needed to produce a binary that I could copy to another machine. 'go run' is not going to help.
@sunbather (afaik, anyway. The output binary that may or may not be produced by 'go run' is not suitable for moving out of the tmp directory where it's stored.)
@cancel I’m not familiar enough to know but I have a feeling it’s possible through some sort of go build arguments. At least it wasn’t incompatible syntax (though the result is the same)
@sunbather I'd have preferred editing code to being presented with a treatise on modular package management while my server is down.
@cancel seems like a job for a script anyhow 
@sunbather No, it's a server that runs persistently and listens on a socket, and needs to do a bunch of stuff with binary data. It's not appropriate for a script.
@sunbather (unless you mean there should have been some automated script to turn my thing into a module)
@cancel ah my bad I read your first post too quickly, something something autocert
@sunbather yeah it needs acme/autocert (or equivalent) because it has to listen on HTTPS. And the thing it's integrating with doesn't allow self-signed certs (ugh) so I either have to use LetsEncrypt or I have to buy and renew a real SSL cert. LetsEncrypt was supposed to be hands off. Guess not!
@sunbather I have no problem handling SSL certs. I've done it for years. But I specifically tried LetsEncrypt here because I just wanted to set this server running and bother it as little as possible.
@cancel how dare you try something new
@sunbather my fault
@cancel I’m here if you need to vent more
@sunbather nah it's not that bad. beats working in a coal mine and getting black lung
@cancel hey now, I work in a coal mine
@sunbather is that a euphemism for javascript
@cancel yes, I’m a junior on the front end team here at Coal Mine. things are getting dire. NPM and Yarn are killing each other in the pit, IE9 is supported for our biggest clients, I physically can’t breath, we’re forced to use dark theme (light theme would vaporize our team), and they got rid of the bidets this year. 
@cancel
changes are always annoying, but is not difficult to 'go' with modules.
(cd path of main.go)
go mod init wtf
go mod tidy
go build
./wtf
@void There's no way to figure that out from the two things you're directed to
https://go.dev/blog/using-go-modules
https://go.dev/ref/mod
@cancel but Go was bad and now it's less bad.
@jonn not sure what you mean
@cancel generics are good, making Go less bad: https://doma.dev/blog/innovation-propagation/#generic-go
@jonn generics are completely irrelevant to the problem I faced
@cancel then i agree with you :)
@cancel
The same thing happened to me too recently, and completely destroyed what little confidence and enthusiasm I had left for Go. Which is a shame, because channels were really cool.
@cassvs they aren't that cool. and you can implement them in any language.
@cancel
That's true :)
I was impressed by named pipes and coroutines baked right into the language, but it really is a superficial thing. You're right: this stuff is possible in almost all languages.
@cancel you can disable modules: GO111MODULE=off
Most of the time, conversion to modules looks like this: go mod init module.com/foo && go mod tidy
The source code is compatible, the tooling has changed. The tooling never was part of the compatibility promise anyway.
@TeddyDD yeah try that in go 1.18
@cancel
I just did and it works.
@TeddyDD maybe I did it wrong, but ‘go get’ to update/install my single dependency didn’t work in 1.18
@cancel I'm happy to help if the code is not top secret 
@TeddyDD I'll just turn it into a module next time I have to mess with it. Thanks though :) (I don't know why they link to a bunch of long-winded documentation instead of just telling you the steps...)
@cancel I’m curious as to what changed. I’ve heard that Go promise as well