5 ms·

I can attest to the fact that programming in Go taught me a lot of good engineering. I certainly find myself better trained at handling errors, for example. Ho

by shaan7 5y ago

I can attest to the fact that programming in Go taught me a lot of good engineering. I certainly find myself better trained at handling errors, for example. However, I always feel exhausted when implementing real-world systems with Go given the lack of $things (that everyone feels is a virtue). Over time I realized that a lot of people just aren't as lazy (or scared of breaking things) as I am - they find it easier to copy code dozens of times and then fixing them all in one go using their ninja refactoring skills. Just a different kind of tradeoff, at the end. So given how laborious it is to make anything more than simple programs (because of the amount of copy-paste-driven-development required), I generally avoid Go unless I'm writing a webservice. For me Go's virtues are static typing and wide variety of community packages to do things. The whole "oh not having features is a feature" thing is just an opinion for the sake of having an opinion. otoh, I damn excited to have generics support soon finally :)

jerf 5y ago
If you are or your coworkers are constantly copying and pasting code, stop, and think a bit more. I do a lot of Go development and almost never copy and paste anything anywhere. (And even in those cases it's usually justified. I just a few minutes ago copied and pasted a big struct... but it's because the first struct was defining a JSON message, and the second struct was defining a very similar, but not quite identical, JSON message in another file. This doesn't seem like a big deal to me, because it's defining a separate external data format and while they are superficially similar they are not the same and really shouldn't share code.) Either you're not using the tools Go has to their full effect, or, possibly, you shouldn't have chosen Go. But I make that last concession not because it probably fits your case, but because it is technically true. (In particular, don't take Go for heavy math code where you need a type system that is ready for lots of mathematics.) But it's probably not applicable. You should not be copying and pasting all the time. There are several communities; I happen to hang out on the reddit /r/golang. If you've got something that you'd like to see how to refactor to not be copy and paste, consider posting a question there (ideally with a running version in the playground of whatever you're asking about). It is true that not everything can be improved, but most things can.
- 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.

by shaan7 5y ago

jerf 5y ago

If you are or your coworkers are constantly copying and pasting code, stop, and think a bit more. I do a lot of Go development and almost never copy and paste anything anywhere. (And even in those cases it's usually justified. I just a few minutes ago copied and pasted a big struct... but it's because the first struct was defining a JSON message, and the second struct was defining a very similar, but not quite identical, JSON message in another file. This doesn't seem like a big deal to me, because it's defining a separate external data format and while they are superficially similar they are not the same and really shouldn't share code.) Either you're not using the tools Go has to their full effect, or, possibly, you shouldn't have chosen Go. But I make that last concession not because it probably fits your case, but because it is technically true. (In particular, don't take Go for heavy math code where you need a type system that is ready for lots of mathematics.) But it's probably not applicable. You should not be copying and pasting all the time. There are several communities; I happen to hang out on the reddit /r/golang. If you've got something that you'd like to see how to refactor to not be copy and paste, consider posting a question there (ideally with a running version in the playground of whatever you're asking about). It is true that not everything can be improved, but most things can.

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.