4 ms·

I agree with the poster you're replying to. The large golang projects I've been involved with have been extremely tedious to work on, even on projects started f

by azth 5y ago

I agree with the poster you're replying to. The large golang projects I've been involved with have been extremely tedious to work on, even on projects started from scratch. The language is extremely weak (it's not expressive), which translates to overly verbose code that is difficult to traverse. Logic that can be expressed in a couple of lines in Java becomes 10+ lines in golang, with code scattered everywhere. Not to mention that golang lacks enums or sum types (the latter have now made it into Java), which are a huge safety and productivity booster.

jerf 5y ago
I work in Go all the time. While there are occasionally things that come out a bit more verbose, and they may stand out in your mind, if you are always writing things that much more verbose, stop, think, and make sure that there isn't some way to do it in Go correctly. Because there usually is. The problem is, a lot of people are used to working in languages which have an abundance of features, so when they have a problem, they have learned to reach for the feature that solves it. In Go, you have fewer tools, but they are sharp, and generally well-chosen and work together well. "Go doesn't have the feature I'm used to using to solve this problem" is not the same as "Go doesn't have a decent solution to this problem". If you are constantly copying and pasting or spreading things out in a way you don't think you should have to, run through the tools that Go does have again. There are several techniques that aren't going to be the first things you necessarily reach from from another language, but work just fine in Go. This is not a complete list but it gives several examples of such techniques: http://www.jerf.org/iri/post/2945 http://www.jerf.org/iri/post/2945 There are some things it really can't do. (Again, I just can't understand the people who are trying to jam their mathematical code into Go. It's just so bad at that.) But that set is smaller than the critics think, because they confuse missing features for missing solutions. It's just another variant of "don't write X in Y", which is never a good idea. And again, I invite you to post any such issues you may have to /r/golang. If I happen to pick it up, I won't be afraid to tell you straight out there isn't a good Go solution to that. I've done it before. But that happens less often than you might think. I also remind you my goal will be to come up with a good Go solution to the core problem, not "the closest approximation to the feature I expected to use" or anything like that. Write Go in Go, not anything else.
- azth 5y ago
  Sum types with exhaustive checking, and records are two extremely serious omissions in golang. Several times now we've run into issues because of this in the current project I'm working on.

by azth 5y ago

jerf 5y ago

I work in Go all the time. While there are occasionally things that come out a bit more verbose, and they may stand out in your mind, if you are always writing things that much more verbose, stop, think, and make sure that there isn't some way to do it in Go correctly. Because there usually is. The problem is, a lot of people are used to working in languages which have an abundance of features, so when they have a problem, they have learned to reach for the feature that solves it. In Go, you have fewer tools, but they are sharp, and generally well-chosen and work together well. "Go doesn't have the feature I'm used to using to solve this problem" is not the same as "Go doesn't have a decent solution to this problem". If you are constantly copying and pasting or spreading things out in a way you don't think you should have to, run through the tools that Go does have again. There are several techniques that aren't going to be the first things you necessarily reach from from another language, but work just fine in Go. This is not a complete list but it gives several examples of such techniques: http://www.jerf.org/iri/post/2945 http://www.jerf.org/iri/post/2945 There are some things it really can't do. (Again, I just can't understand the people who are trying to jam their mathematical code into Go. It's just so bad at that.) But that set is smaller than the critics think, because they confuse missing features for missing solutions. It's just another variant of "don't write X in Y", which is never a good idea. And again, I invite you to post any such issues you may have to /r/golang. If I happen to pick it up, I won't be afraid to tell you straight out there isn't a good Go solution to that. I've done it before. But that happens less often than you might think. I also remind you my goal will be to come up with a good Go solution to the core problem, not "the closest approximation to the feature I expected to use" or anything like that. Write Go in Go, not anything else.

azth 5y ago
Sum types with exhaustive checking, and records are two extremely serious omissions in golang. Several times now we've run into issues because of this in the current project I'm working on.