[scripturial]

Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized.

Go is very much faster, you save time and money on computing resources.

Go has built in testing and type support, making it easier To write more reliable and more bug free code.

But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.

[90s_dev]

> But let’s not debate it, learn go for yourself and try it on a small little project

I wrote a lot of Go from like 2010 to 2013 or so.

A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go.

I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.

[cratermoon]

If you haven't touched Go since 2013, give it another try. Quite a lot of the developer QOL has improved.

[90s_dev]

When typescript-go was announced, I almost wanted to give it a serious try. But that article I referred to convinced me that it still has serious QOL issues.

[jpc0]

> I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.

I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed.

If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.

[taco9999]

Was it this article?

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

[90s_dev]

No, the one I saw had little to no code.

[90s_dev]

> Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized.

I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close).

But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets.

gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.

Having a standard is fine. But software is not just technical, it's an art too.

[haiku2077]

> This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.

Would you be willing to make a Long Bet about it? https://longbets.org

[90s_dev]

Interesting site, I bet it won't last more than 20 more years.

I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)