4 ms·

> 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

> 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.

jpc0 1y ago
> 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.
cratermoon 1y ago
If you haven't touched Go since 2013, give it another try. Quite a lot of the developer QOL has improved.
- 90s_dev 1y ago
  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.
taco9999 1y ago
Was it this article? https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
- deleted 1y ago
  [deleted]
- 90s_dev 1y ago
  No, the one I saw had little to no code.

jpc0 1y ago

> 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.

cratermoon 1y ago

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

90s_dev 1y ago
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.

taco9999 1y ago

Was it this article? https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

deleted 1y ago
[deleted]
90s_dev 1y ago
No, the one I saw had little to no code.