I worked with C# for a decade and it's become a really great general purpose language. I'd still prefer never to work with it ever again after having worked with Go. This isn't for technical reasons at all, but because Golang is so easy to work with for "people reasons". There are brilliant parts of Go, but the only thing I find myself missing in other languages is the simplistic module isolation, where every folder is a module, every file within the folder is part of it and then you expose functions with capital letters at the beginning of their name. Holy hell did I wish Python had that. Anyway, the thing that makes Go nice to work with over time is the explicity of everything and a lot of the very opinionated decisions. With a piece of Go code I can jump in and immediately know what is going on regardless of who wrote it. With C# I'll often have to go down long "go to definition" paths. Often you will end up trying to figure out just how someone was trying to "fight" the implicit magic of the non-STL Microsoft dependencies they used. Usually because they didn't really understand what they were doing. All of these are human issues and no fault of C# or .Net as such.
Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things.
I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive.
The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go.
I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.
> I hate the fact that they didn't want runtime assertions as an example,
So you hate writing:
if (something != 1) {
panic("oh no!")
}
vs
assert(something != 1, "oh no!")
? Reminds me of people complaining about Python's significant indentation. If that's what you're complaining about, you have nothing to complain about.
I think your point is fair as you can do runtime safety in Go by wrapping Panic, but that's not exactly what Panic is meant to be used for. I guess it's more of a intent vs syntax thing, aside from the part where Panic can be Recover()ed.
You're taking it out of a context of me praising Golang, however, and while I do hate the fact that they didn't just do runtime assertions, it's not like I dislike Go as a whole because of it.
Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things.
I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive.
The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go.
I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.