10 ms·

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create small binaries and cross compilation ”just works”. Go projects usually dont have many dependencies, but IF you need something there always a package for it. Go takes BC serioisly, 10 year old Go code compiles (usually) fine with the lastest version. Overall its a really good ”get shit done” language, and a good fit for larger teams

ingoaf 3y ago
Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.
- Cthulhu_ 3y ago
  They may be geniuses, but some - mainly Ken Thompson - are also luddites, eschewing things like syntax highlighting. I mean they have a point - if you need colors to make your code readable, your code isn't readable. But yeah, I love how everything is well thought out and they just say "no" a lot.
- infecto 3y ago
  This was one of the troubles I always had with Java. It was very hard for me to reason about with some of the wildly nested inheritance.
- coffeebeqn 3y ago
  I remember looking through this insane taxonomy of abstractions of a button to find the code for when it got pressed. There weren’t that many buttons and they had no special requirements. Just trying not to find some real actual code that does the thing. I work on much bigger projects now with much less abstraction and my quality of life is much higher
- kyrra 3y ago
  It depends on what libraries you use and how you structure your code. Yes, you can create inheritance hell within Java code. But you can also use composition (what Go uses) within Java and create sane code bases. Inheritance is a foot gun that got overused in the '90s and early 2000s. But people have learned mostly to avoid it unless really needed.
- zimpenfish 3y ago
  > it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a single HTTP handler actually does.
  - baby 3y ago
    I’ve seen one Golang codebase like this and it was made by Java people
  - mrweasel 3y ago
    A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their tool of choice.
    - munificent 3y ago
      > I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else I've also seen the opposite where people revolve their entire identity around not being the person and they swing too far the other direction and end up being a masochist and doing things the dumb way because they're too afraid of coming across like a snob.
    - ingoaf 3y ago
      This is actually a real gem of a comment. Thank you for that!
    - mostlylurks 3y ago
      You are mistaken if you think that the abundant use of interfaces etc. is motivated by anything along those lines. As someone who often puts basically everything behind an interface and abstracts everything in sight, it's not because it has anything to do with being smart, quite the opposite; it's the only way I can keep any meaningful portion of the code in my head. Give me a 5000-line straightforward / unabstracted implementation of something and I'll struggle, but give me thingDoer.doThing(), behind an interface so I don't even have to know how to construct one, and I'll be happy and able to focus on the task at hand. This applies even if I'm the one who wrote the ThingDoer interface and its implementation(s), and even if it was only 30 minutes ago.
- Thrymr 3y ago
  > All in all Go was created by geniuses and it shows. This is not necessarily a compliment to the language. I'm OK with a language created by merely somewhat smart pragmatists.
- EnergyAmy 3y ago
  > geniuses That's very strong language. Go was created by some smart people that have completely ignored programming language developments that happened after the 70's.
  - lambda_garden 3y ago
    Ironically, we had more advanced languages than Go in the 70s.
    - Ferret7446 3y ago
      Advanced != good. It takes some genius to realize that.
    - Cthulhu_ 3y ago
      Yeah, but advanced languages are also a problem for long-term maintainability. Remember, Go was developed at Google - jokingly, while waiting for stuff to compile. They deal with tens of millions of lines of C++ written by thousands of engineers with varying skill levels and career paths. The advancedness of C++ did not reduce the compile times or readability of the code. At those scales you can't rely on being familiar with a particular section of code; you need to be able to drop in anywhere and know what's going on, without having to learn which subset of the advanced language they used for that particular feature. Go is not advanced by design.
      - lambda_garden 3y ago
        Advanced languages can compile quickly - it depends on the feature set chosen. For example, do-notation is an advanced feature not found in most languages, but it compiles quickly as it is syntactic sugar. Operator overload, on the other hand, might require a solver and thus compile slower. It's not a particularly advanced feature, however. Binary optimization passes do not make the language any more advanced (on the user side), but will slow down compilation. Advanced design and compile-times are pretty orthogonal. As for maintainability, it's not clear to me that reams of imperative code is easier to maintain than something terse and declarative. In fact, probably the opposite.
- fh973 3y ago
  You can write 90s object oriented code in any language.
- geraneum 3y ago
  Go was first and foremost created to serve the needs of Google. Kudos to them for releasing, open sourcing and backing it but it was designed to serve their needs. It’s not a criticism but it explains why it’s quirky in many areas. The authors being genius is not as important as the goals and intentions.
- pron 3y ago
  To know which interfaces a Go type implements (and so where it can be used) requires reading more, not fewer files than in Java.
hotnfresh 3y ago
My favorite thing about Go is that I can read a dependency’s source and there’s a very low probability that the author favors some totally different 30% of the language than I’m accustomed to, so I find it illegible without great effort. Or has imported libraries to add so many language features that it looks totally alien (fucking JavaScript—it’s getting better these days, to be fair, but there was a decade-plus when you just had no clue what you’d see when you opened up an unfamiliar codebase)
avgcorrection 3y ago
> No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. I don’t understand this template? 1. No matter your opinion on X: 2. Opinion Y is true about X! If all you have are compliments about X: just go directly to (2). You’re not making a begrudging concession, after all.
- Nullabillity 3y ago
  Or the related fallacy, "X was designed to be good at Y, so clearly X is good at Y!" (or worse, "is the best way to do Y!").
- phplovesong 3y ago
  I basically mean: No matter if you dislike Go you cant argue with the fact that it is a good fit for larger teams collaborating on a big multi-year/multi-decade project.
- papichulo2023 3y ago
  Well... It kinda replaced Java for most cloud stuff except for Kafka.
- wsc981 3y ago
  I think the way it's meant to be read and understood is as follows: "There may (or may not) be many problems with Go, but building bigger projects is not one of those".
  - stouset 3y ago
    This is actually kind of funny because one of the classical arguments made by gophers eight or so years ago when I first started learning it was that golang's limited abstraction power makes the pain of large codebases obvious enough that teams are incentivized to keep projects small.
- deleted 3y ago
  [deleted]
- goodpoint 3y ago
farresito 3y ago
IMO, Go is a mediocre language with great tooling and a great company behind it, and it turns out ultimately if you don't have the latter, the former is irrelevant.
- phplovesong 3y ago
  Yes, i can agree. Go is not my favorite language, but when it comes to pragmatism and developer productivity, Go is up there.
- packetlost 3y ago
  Most developers are mediocre, so having a language that can match the skill level of the average dev is a win for many situations, no?
  - kadoban 3y ago
    No. A better language would make things safer for the average dev. You don't give the new guy at work the saw with all of the safety features removed. Or maybe you do, but you're not doing it for his benefit at least.
  - mostlylurks 3y ago
    A mediocre language is not the same as a language appropriate for developers of mediocre skills. Go could have been made a better language [0] in many ways that would have actually made it easier than it is right now, by avoiding some of the footguns built into the language. This also wouldn't have made the language more prone to being used in a complex manner by metaprogramming enthusiasts and the like. Better often means simpler, not more complex. [0]: Not that it's not already decent.
  - deleted 3y ago
    [deleted]
- baby 3y ago
  Yes, like Python and Javascript right? Turns out you don’t need a great language when you provide what most people want: great tooling, good resources to ramp up, great stdlib, etc. Believe it or not Golang was the first language to do this, and probably still the only one? (Rust misses the mark on great stdlib)
pif 3y ago
> they nailed it for bigger projects. Yeah, indeed, big projects did not exist before!
- phplovesong 3y ago
  They sure did! But in what shape do they exist in today? Depending on the language you might find N ways of doing something, where N = amount of devs who has worked on the project. Most likely you have a huge mess.
baby 3y ago
The way I describe it is that Golang is optimized for reading, other languages are often optimized for writing. If you have to deal with someone else’s codebase, then Golang is a godsend. I also like that you pointed out that every Golang codebase looks the same. I think part of that is that Golang’s formatter can’t be customized. I pushed for that to happen in Rust but lost the battle.
- theshrike79 3y ago
  Exactly. Code is read WAY more often than it's written. Go is verbose, that's true. And if the speed of writing code is the biggest hurdle in your productivity you're either a true 100x coder savant or deluded. Go is boring, boring is good when you need shit to work every time. And especially when you can't pick the top1% geniuses to work on it and might need to bring some rando up to speed to the project AND language quickly.
  - dave4420 3y ago
    Go is verbose. That slows me down when I’m _reading_ code. Especially when it means the chunk of code I’m reading doesn’t fit on my screen.
    - baby 3y ago
      Java is verbose, C++ is verbose, Golang is not. Golang actually cared about verbosity. For example, uppercase letter means that your function is exposed, no keyword!
    - stouset 3y ago
      Or when I have to pick out what the actual logic is amidst a forest of error handling. Or mentally deconstruct some complicated loop to figure out it's just doing a map, filter, reduce.
- ghayes 3y ago
  I've actually found Golang codebases to be the hardest to read, mostly due to the non-locality of effects from channels. It's just to easy to read a line of code and not know where to move next.
throwawa14223 3y ago
As someone with the misfortune of inheriting a million plus loc Go project I disagree. Go is a nightmare from the duck typing to dependency management.
- phplovesong 3y ago
  I assume your only part of a larger larger team working on this 1M LOC project? If you are alone with no previous context/knowledge the language does no really matter, you would be in a world of hurt nonetheless.
  - throwawa14223 3y ago
    I agree with you but that pretty much invalidates Go. The whole selling point is that it is lacking anything to make the language interesting to use but you can drop in and any two Go programmers write the same understandable code.
- bogota 3y ago
  I assume with the duck typing you are talking about interfaces? How has that caused issues? With huge projects that pull in packages i have seen the dependency management become a mess but most of the time its not that bad.
  - throwawa14223 3y ago
    It was sloppy coding on the project I took over, but it still made me wish for explicit style interfaces. Cleaning up frequently broke the project in non-local ways, because someone would break an interface without meaning to.
    - rplnt 3y ago
      Unless you are doing some (possibly unsafe) magic the interfaces are strongly typed, external dependencies are locked, so one cannot really break an interface without meaning to. Or I guess without realizing it immediately.
mFixman 3y ago
I used Go for many years. My issue is that it's _almost_ a great language, but in its current version it's just a collection of foot guns that makes it difficult to get shit done. Go doesn't have some of the most library functions, so large codebases shared between teams end up with a dozen different implementations of functions like "minimum" or "filter". Good luck debugging a bug in one of the implementations. The exception-less error handling would be great if they used sum types instead of (val, error) tuples. Return types are required to have a "default" value if you want to return an error, and good luck finding bugs where you use that value and forget the "if err != nil"`. Worst of all, they removed most "fun" C things about pointers (like subtracting pointers in the same array) but kept the null pointers themselves. There's no way to ask for a not-null pointer at the type level, so you have to check for nullity everywhere and good luck debugging those runtime panics.
- phplovesong 3y ago
  A general "min/max" function could be implemented with Generics?
  - Cthulhu_ 3y ago
    And has, since Go 1.21, but that's very recent so everything written before August this year may have the problem of a min/max utility and the like: https://go.dev/blog/go1.21 https://go.dev/blog/go1.21
- Mawr 3y ago
  > There's no way to ask for a not-null pointer at the type level, so you have to check for nullity everywhere and good luck debugging those runtime panics. You can write a simple Option type yourself using generics [1]. It's not strictly idiomatic and you do have to remember to use it, but it works well. [1]: (my post) https://news.ycombinator.com/item?id=38331565 https://news.ycombinator.com/item?id=38331565
- willsmith72 3y ago
  > a dozen different implementations of functions like "minimum" or "filter" this is too real and my number 1 gripe with go
distortedsignal 3y ago
Ok, maybe you can help me figure something out that I haven’t been able to. I’ve got a project broken down into modules. Module A uses module B. These are both checked into GitHub, so the module path is something like guthub.com/distortedsignal/my-project/src/a or whatever. I need to make a change across both of these modules. Will my compilation pick up the changes? What if I need to make a backward-incompatible change in b when b is a fully separate project?
- Groxx 3y ago
  >I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Import and use that. Backwards incompatible in practice: few projects actually do that reliably, IMO because tooling to help you do this or detect the need is somewhere between "bad" and "horrifyingly bad". Most just make the breaking change, increase the minimum version in A, and it'll work for anyone who stays up to date on A (this is often good enough for internal use). Though people updating B separately by hand might break.
  - distortedsignal 3y ago
    Ok, I wasn’t able to figure that out when I was in the codebase. What do you do if you’re working in a fork of the project and you need to make those changes?
    - Groxx 3y ago
      Should be the same. You can replace to any location, and with modules it doesn't even need to follow GOPATH naming conventions. E.g. clone A and fork-B into adjacent folders regardless of fork status or import paths, and change A/go.mod to include replace original.com/B ../B and that should work fine. With GOPATH you would need to clone the fork into the original path. Which you can do if needed / modules don't prevent that either, but modules don't need any specific locations at all. --- The official module doc is... huge and doesn't spell things out in an easily-usable form, so you're far from alone in your confusion, but I do think it's worth reading. I routinely find people spending way more time struggling with them than it would take to read the spec and become an expert on it: https://go.dev/ref/mod https://go.dev/ref/mod
asylteltine 3y ago
Go is an amazing language. I use it for everything. It’s easily the best new language of our generation for getting shit done
lambda_garden 3y ago
What's strange is that Java predates Go and has all of these attributes. C# too, for that matter.
closeparen 3y ago
As someone who mostly writes request-handling services, I just don't think propagating errors through gateway/repository -> controller -> handler layers deserves 90% of my attention. But unfortunately that it is where it goes doing microservices glue type stuff in Go.
turtleyacht 3y ago
Backward compatibility (BC)

ingoaf 3y ago

Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.

Cthulhu_ 3y ago
They may be geniuses, but some - mainly Ken Thompson - are also luddites, eschewing things like syntax highlighting. I mean they have a point - if you need colors to make your code readable, your code isn't readable. But yeah, I love how everything is well thought out and they just say "no" a lot.
infecto 3y ago
This was one of the troubles I always had with Java. It was very hard for me to reason about with some of the wildly nested inheritance.
coffeebeqn 3y ago
I remember looking through this insane taxonomy of abstractions of a button to find the code for when it got pressed. There weren’t that many buttons and they had no special requirements. Just trying not to find some real actual code that does the thing. I work on much bigger projects now with much less abstraction and my quality of life is much higher
kyrra 3y ago
It depends on what libraries you use and how you structure your code. Yes, you can create inheritance hell within Java code. But you can also use composition (what Go uses) within Java and create sane code bases. Inheritance is a foot gun that got overused in the '90s and early 2000s. But people have learned mostly to avoid it unless really needed.
zimpenfish 3y ago
> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a single HTTP handler actually does.
- baby 3y ago
  I’ve seen one Golang codebase like this and it was made by Java people
- mrweasel 3y ago
  A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their tool of choice.
  - munificent 3y ago
    > I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else I've also seen the opposite where people revolve their entire identity around not being the person and they swing too far the other direction and end up being a masochist and doing things the dumb way because they're too afraid of coming across like a snob.
  - ingoaf 3y ago
    This is actually a real gem of a comment. Thank you for that!
  - mostlylurks 3y ago
    You are mistaken if you think that the abundant use of interfaces etc. is motivated by anything along those lines. As someone who often puts basically everything behind an interface and abstracts everything in sight, it's not because it has anything to do with being smart, quite the opposite; it's the only way I can keep any meaningful portion of the code in my head. Give me a 5000-line straightforward / unabstracted implementation of something and I'll struggle, but give me thingDoer.doThing(), behind an interface so I don't even have to know how to construct one, and I'll be happy and able to focus on the task at hand. This applies even if I'm the one who wrote the ThingDoer interface and its implementation(s), and even if it was only 30 minutes ago.
Thrymr 3y ago
> All in all Go was created by geniuses and it shows. This is not necessarily a compliment to the language. I'm OK with a language created by merely somewhat smart pragmatists.
EnergyAmy 3y ago
> geniuses That's very strong language. Go was created by some smart people that have completely ignored programming language developments that happened after the 70's.
- lambda_garden 3y ago
  Ironically, we had more advanced languages than Go in the 70s.
  - Ferret7446 3y ago
    Advanced != good. It takes some genius to realize that.
  - Cthulhu_ 3y ago
    Yeah, but advanced languages are also a problem for long-term maintainability. Remember, Go was developed at Google - jokingly, while waiting for stuff to compile. They deal with tens of millions of lines of C++ written by thousands of engineers with varying skill levels and career paths. The advancedness of C++ did not reduce the compile times or readability of the code. At those scales you can't rely on being familiar with a particular section of code; you need to be able to drop in anywhere and know what's going on, without having to learn which subset of the advanced language they used for that particular feature. Go is not advanced by design.
    - lambda_garden 3y ago
      Advanced languages can compile quickly - it depends on the feature set chosen. For example, do-notation is an advanced feature not found in most languages, but it compiles quickly as it is syntactic sugar. Operator overload, on the other hand, might require a solver and thus compile slower. It's not a particularly advanced feature, however. Binary optimization passes do not make the language any more advanced (on the user side), but will slow down compilation. Advanced design and compile-times are pretty orthogonal. As for maintainability, it's not clear to me that reams of imperative code is easier to maintain than something terse and declarative. In fact, probably the opposite.
fh973 3y ago
You can write 90s object oriented code in any language.
geraneum 3y ago
Go was first and foremost created to serve the needs of Google. Kudos to them for releasing, open sourcing and backing it but it was designed to serve their needs. It’s not a criticism but it explains why it’s quirky in many areas. The authors being genius is not as important as the goals and intentions.
pron 3y ago
To know which interfaces a Go type implements (and so where it can be used) requires reading more, not fewer files than in Java.

hotnfresh 3y ago

My favorite thing about Go is that I can read a dependency’s source and there’s a very low probability that the author favors some totally different 30% of the language than I’m accustomed to, so I find it illegible without great effort. Or has imported libraries to add so many language features that it looks totally alien (fucking JavaScript—it’s getting better these days, to be fair, but there was a decade-plus when you just had no clue what you’d see when you opened up an unfamiliar codebase)

avgcorrection 3y ago

> No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. I don’t understand this template? 1. No matter your opinion on X: 2. Opinion Y is true about X! If all you have are compliments about X: just go directly to (2). You’re not making a begrudging concession, after all.

Nullabillity 3y ago
Or the related fallacy, "X was designed to be good at Y, so clearly X is good at Y!" (or worse, "is the best way to do Y!").
phplovesong 3y ago
I basically mean: No matter if you dislike Go you cant argue with the fact that it is a good fit for larger teams collaborating on a big multi-year/multi-decade project.
papichulo2023 3y ago
Well... It kinda replaced Java for most cloud stuff except for Kafka.
wsc981 3y ago
I think the way it's meant to be read and understood is as follows: "There may (or may not) be many problems with Go, but building bigger projects is not one of those".
- stouset 3y ago
  This is actually kind of funny because one of the classical arguments made by gophers eight or so years ago when I first started learning it was that golang's limited abstraction power makes the pain of large codebases obvious enough that teams are incentivized to keep projects small.
deleted 3y ago
[deleted]
goodpoint 3y ago

farresito 3y ago

IMO, Go is a mediocre language with great tooling and a great company behind it, and it turns out ultimately if you don't have the latter, the former is irrelevant.

phplovesong 3y ago
Yes, i can agree. Go is not my favorite language, but when it comes to pragmatism and developer productivity, Go is up there.
packetlost 3y ago
Most developers are mediocre, so having a language that can match the skill level of the average dev is a win for many situations, no?
- kadoban 3y ago
  No. A better language would make things safer for the average dev. You don't give the new guy at work the saw with all of the safety features removed. Or maybe you do, but you're not doing it for his benefit at least.
- mostlylurks 3y ago
  A mediocre language is not the same as a language appropriate for developers of mediocre skills. Go could have been made a better language [0] in many ways that would have actually made it easier than it is right now, by avoiding some of the footguns built into the language. This also wouldn't have made the language more prone to being used in a complex manner by metaprogramming enthusiasts and the like. Better often means simpler, not more complex. [0]: Not that it's not already decent.
- deleted 3y ago
  [deleted]
baby 3y ago
Yes, like Python and Javascript right? Turns out you don’t need a great language when you provide what most people want: great tooling, good resources to ramp up, great stdlib, etc. Believe it or not Golang was the first language to do this, and probably still the only one? (Rust misses the mark on great stdlib)

pif 3y ago

> they nailed it for bigger projects. Yeah, indeed, big projects did not exist before!

phplovesong 3y ago
They sure did! But in what shape do they exist in today? Depending on the language you might find N ways of doing something, where N = amount of devs who has worked on the project. Most likely you have a huge mess.

baby 3y ago

The way I describe it is that Golang is optimized for reading, other languages are often optimized for writing. If you have to deal with someone else’s codebase, then Golang is a godsend. I also like that you pointed out that every Golang codebase looks the same. I think part of that is that Golang’s formatter can’t be customized. I pushed for that to happen in Rust but lost the battle.

theshrike79 3y ago
Exactly. Code is read WAY more often than it's written. Go is verbose, that's true. And if the speed of writing code is the biggest hurdle in your productivity you're either a true 100x coder savant or deluded. Go is boring, boring is good when you need shit to work every time. And especially when you can't pick the top1% geniuses to work on it and might need to bring some rando up to speed to the project AND language quickly.
- dave4420 3y ago
  Go is verbose. That slows me down when I’m _reading_ code. Especially when it means the chunk of code I’m reading doesn’t fit on my screen.
  - baby 3y ago
    Java is verbose, C++ is verbose, Golang is not. Golang actually cared about verbosity. For example, uppercase letter means that your function is exposed, no keyword!
  - stouset 3y ago
    Or when I have to pick out what the actual logic is amidst a forest of error handling. Or mentally deconstruct some complicated loop to figure out it's just doing a map, filter, reduce.
ghayes 3y ago
I've actually found Golang codebases to be the hardest to read, mostly due to the non-locality of effects from channels. It's just to easy to read a line of code and not know where to move next.

throwawa14223 3y ago

As someone with the misfortune of inheriting a million plus loc Go project I disagree. Go is a nightmare from the duck typing to dependency management.

phplovesong 3y ago
I assume your only part of a larger larger team working on this 1M LOC project? If you are alone with no previous context/knowledge the language does no really matter, you would be in a world of hurt nonetheless.
- throwawa14223 3y ago
  I agree with you but that pretty much invalidates Go. The whole selling point is that it is lacking anything to make the language interesting to use but you can drop in and any two Go programmers write the same understandable code.
bogota 3y ago
I assume with the duck typing you are talking about interfaces? How has that caused issues? With huge projects that pull in packages i have seen the dependency management become a mess but most of the time its not that bad.
- throwawa14223 3y ago
  It was sloppy coding on the project I took over, but it still made me wish for explicit style interfaces. Cleaning up frequently broke the project in non-local ways, because someone would break an interface without meaning to.
  - rplnt 3y ago
    Unless you are doing some (possibly unsafe) magic the interfaces are strongly typed, external dependencies are locked, so one cannot really break an interface without meaning to. Or I guess without realizing it immediately.

mFixman 3y ago

I used Go for many years. My issue is that it's _almost_ a great language, but in its current version it's just a collection of foot guns that makes it difficult to get shit done. Go doesn't have some of the most library functions, so large codebases shared between teams end up with a dozen different implementations of functions like "minimum" or "filter". Good luck debugging a bug in one of the implementations. The exception-less error handling would be great if they used sum types instead of (val, error) tuples. Return types are required to have a "default" value if you want to return an error, and good luck finding bugs where you use that value and forget the "if err != nil"`. Worst of all, they removed most "fun" C things about pointers (like subtracting pointers in the same array) but kept the null pointers themselves. There's no way to ask for a not-null pointer at the type level, so you have to check for nullity everywhere and good luck debugging those runtime panics.

phplovesong 3y ago
A general "min/max" function could be implemented with Generics?
- Cthulhu_ 3y ago
  And has, since Go 1.21, but that's very recent so everything written before August this year may have the problem of a min/max utility and the like: https://go.dev/blog/go1.21 https://go.dev/blog/go1.21
Mawr 3y ago
> There's no way to ask for a not-null pointer at the type level, so you have to check for nullity everywhere and good luck debugging those runtime panics. You can write a simple Option type yourself using generics [1]. It's not strictly idiomatic and you do have to remember to use it, but it works well. [1]: (my post) https://news.ycombinator.com/item?id=38331565 https://news.ycombinator.com/item?id=38331565
willsmith72 3y ago
> a dozen different implementations of functions like "minimum" or "filter" this is too real and my number 1 gripe with go

distortedsignal 3y ago

Ok, maybe you can help me figure something out that I haven’t been able to. I’ve got a project broken down into modules. Module A uses module B. These are both checked into GitHub, so the module path is something like guthub.com/distortedsignal/my-project/src/a or whatever. I need to make a change across both of these modules. Will my compilation pick up the changes? What if I need to make a backward-incompatible change in b when b is a fully separate project?

Groxx 3y ago
>I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Import and use that. Backwards incompatible in practice: few projects actually do that reliably, IMO because tooling to help you do this or detect the need is somewhere between "bad" and "horrifyingly bad". Most just make the breaking change, increase the minimum version in A, and it'll work for anyone who stays up to date on A (this is often good enough for internal use). Though people updating B separately by hand might break.
- distortedsignal 3y ago
  Ok, I wasn’t able to figure that out when I was in the codebase. What do you do if you’re working in a fork of the project and you need to make those changes?
  - Groxx 3y ago
    Should be the same. You can replace to any location, and with modules it doesn't even need to follow GOPATH naming conventions. E.g. clone A and fork-B into adjacent folders regardless of fork status or import paths, and change A/go.mod to include replace original.com/B ../B and that should work fine. With GOPATH you would need to clone the fork into the original path. Which you can do if needed / modules don't prevent that either, but modules don't need any specific locations at all. --- The official module doc is... huge and doesn't spell things out in an easily-usable form, so you're far from alone in your confusion, but I do think it's worth reading. I routinely find people spending way more time struggling with them than it would take to read the spec and become an expert on it: https://go.dev/ref/mod https://go.dev/ref/mod

asylteltine 3y ago

Go is an amazing language. I use it for everything. It’s easily the best new language of our generation for getting shit done

lambda_garden 3y ago

What's strange is that Java predates Go and has all of these attributes. C# too, for that matter.

closeparen 3y ago

As someone who mostly writes request-handling services, I just don't think propagating errors through gateway/repository -> controller -> handler layers deserves 90% of my attention. But unfortunately that it is where it goes doing microservices glue type stuff in Go.

turtleyacht 3y ago

Backward compatibility (BC)