9 ms·

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 difficul

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
- patmorgan23 3y ago
  And it's funny because go has a whole http server in the standard lib, but not minimum?
  - kevincox 3y ago
    It couldn't have a minimum before generics. The function was not expressible in the general case. So they either would have had to add `minByte`, `minInt`, `minStr`, ... or make it a builtin generic. And every builtin is an admission that the language was not powerful enough, so those are kept to a minimum.
  - porjo 3y ago
    There is 'min': https://go.dev/ref/spec#Min_and_max https://go.dev/ref/spec#Min_and_max
    - richbell 3y ago
      Since v1.21, which wasn't released that long ago.
  - yobert 3y ago
    I know it sounds funny, but I have used the built in "net/http" in probably fifty projects now, and not a single one of them needed a min/max function.
amelius 3y ago
I tried Go for about a day, and the exception handling and null-pointer issues were exactly the things that made me lose interest.
- bborud 3y ago
  One day is not enough to even get a superficial understanding of any language. People tend to always exaggerate how little time it takes to learn a language to a meaningful degree. Sure, the first day I tried Go I was able to accomplish something useful, but it took me a few months to develop a basic understanding of how you use Go in an idiomatic manner. I'd say it took at least a couple of years before I could say I "knew" Go. And it wasn't exactly love at first sight. My initial impression of Go was that it was a bit too much like C, and, coming from Java, I was a bit confused about how you structure things. That takes time to figure out for any language. What sold me on Go eventually was that for my uses (writing multi-protocol server applications that run on multiple architectures), it resulted in code that was very readable and productivity more than doubled because Go is a lot less fussy to work in than Java. Both in terms of encouraging more minimal designs and having a lot less fragility.
  - Cthulhu_ 3y ago
    I disagree; you can learn 90% of Go in an afternoon. However, you also do have a point; the power of Go is not apparent in an afternoon, but in longer term and larger projects spanning years or decades, and hundreds or thousands of developers. It was made by and for Google to solve Google's problems, which include millions of LOC written and read by thousands of engineers over the span of decades. So while at first you think "eww, err != nil everywhere", at least in a decade of reading your own or someone elses' code you'll know exactly what's going on. How many languages are similar? I feel like a lot of languages in the past decade have had a steady migration in things like error handling, so 10 year old Java code is incomparable to today's Java. Whether that's a good thing (the language has evolved and is now more ergonomic) or a bad thing (I no longer know what's going on here) is the big debate.
    - 3y ago
Gibbon1 3y ago
I feel like the pointer stuff you could handle safely in a modern language. Because I think pointer and array notation are convertible so one isn't scarier than the other. But yeah not being able to tag pointers as 'can't be null' and have the compiler enforce that ignores everything we've learned in the last 40 years. You shouldn't be able to pass a potentially null pointer to a routine that can't deal with it. You end up with code finding a null pointer without any context that tells it what to do with that. Or it panics.
- madeofpalk 3y ago
  Using pointers just to get a 'null' is just an annoying hack reflective of poor design. Instead, "no value" should be able to be directly represented.
  - Cthulhu_ 3y ago
    In Go that's the zero value, which is usually things like empty string, 0, [], etc; in most cases that's good enough.
morsecodist 3y ago
I could not agree more with this. Go is so frustrating to me because there is so much I like but these things you listed make it miserable for me to use. A basic option and result type could fix a lot of the issues around errors and null pointers. I know languages like Scala, Haskell, and Rust have type systems that are often considered too complex but Go doesn't need all that to add these two.
- phplovesong 3y ago
  Having used Ocaml for quite some time, i can understand this. However, i cant tell people (junior devs, or devs who just want to work and does not care about comp-soyery) to learn an ML (+ all the FP idioms) with a straight face. Having a (val, err) tuple IS more easy than returning a monad. Sometimes (most times?) pure procedural code is just the best, and i really hate languages that have feature X but does not support it fully. As an example i would not be happy with an monadic return type if the language did not have the option to use some sort of bind/return combo, and have full pattern matching support. Thats why i champion Go for larger teams. Almost anyone can join the team in dive in without much previous Go knowledge. This is a rare feature and i dont know many other languages that has this property.
  - morsecodist 3y ago
    You really don't need to think about monads or functional programming to have option and result. The focus on explaining these in the context of sum types and monads only serves to distract most people. A list is a monad and people use them every day and they are fine. > Having a (val, err) tuple IS more easy than returning a monad. Arguments about which concept is easier for people to understand pretty quickly descend into subjectivity but I don't believe this is universally true. Why am I getting a value when there's an error? What do I return as my value when returning errors? Explaining to someone that a function returns (val, err) and only one of these values will be significant is more or less the same as describing a result. Option is even simpler. It's a list that can have at most one item. Or, you know how in python you can set a variable to None? Here's how to do it in a strongly typed language.
- 3y ago
bunderbunder 3y ago
This roughly lines up with my feelings. Go is a solid improvement over many languages that we inherited from the 70s, 80s and 90s. But it also retains a certain "we don't need a robust type system; weak-ish static typing is good enough" ethos that made sense in back then, when compilers were hard enough to write that it was easier to justify making the programmer handle more things manually for the sake of simplifying the compiler authors' job. This is always a tradeoff, of course, but I think that the optimum balance has shifted even further in favor of programmers. Some of Go's decisions still made sense in the 2000s when the language was first being created. But now, 15 or so years later, I think many of us could be forgiven for wishing for a language that's a lot like Go except that it dared to dream just a little bit bigger.
- d0mine 3y ago
  > 70s, 80s and 90s It reminded me of Go vs. Algol-69 http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
- bborud 3y ago
  Language design is always easier in retrospect. It is harder than it looks, and often harder than the people designing a language realize before it is too late. I think it was a good choice to take smaller steps and try to not be too ambitious too soon. Sure, Go isn't the most sexy language from an academic point of view, but it has a certain conservative and pragmatic approach that does work. It does generally result in code that is a lot easier to read and maintain than is my experience with C, C++, Java, C# and a few other languages I've worked in. Go is an engineering language - not an academic exercise. Take, for instance, the approach to generics. They could have designed that in from the beginning, but they showed restraint and didn't. That probably took a fair bit of courage. It is my impression that they hadn't figured out what generics should look like in Go, so they postponed until they had a better feel for how it ought to be done. Rather than risk making choices that would be hard (impossible?) to rectify later. When you add something to a language there is always the risk that you make it worse. (I'm not making any qualitative judgements on Go generics since, frankly, I don't feel qualified. I make very sparing use of it because it really isn't that often I actually need to make use of it) People tend to forget that Java didn't have generics until 1.5 (or 5.0 or however they prefer to version it now) - about 9 years after first being launched. And to be frank, that was not a fun experience at all. Not so much because there was something wrong with the design, but because suddenly a lot of people went overboard and started designing really hairy types that could be hard to figure out and use. If you consider C++: C++ spent 20+ years flailing wildly and the result was that you got lots of different C++ "traditions", subsets and practices. Sometimes within the same company. Depending on which era or tradition a C++ codebase is from you may have to adjust to a wholly different way of programming from what you are used to or prefer. And as for generic programming: in what world is STL a neat solution? And to this day, compilers are slow, they produce rubbish error messages, the toolchain still feels like a 1970s ad-hoc mess, and there is no definitive way to build things, resulting in lots and lots of additional complexity when trying to tame the horrific tool chain. Sure, they could have put loads of stuff in Go from the beginning. But I think they would have gotten a lot more wrong if they had. I really appreciate that they are evolving the language slowly and conservatively.
deleted 3y ago
[deleted]
tick_tock_tick 3y ago
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". Does https://pkg.go.dev/slices#DeleteFunc https://pkg.go.dev/slices#DeleteFunc not work for you or do you need it to be called filter? It's there for maps too https://pkg.go.dev/maps#DeleteFunc https://pkg.go.dev/maps#DeleteFunc
- mFixman 3y ago
  To be honest, I used to use Go before generics became a thing. I'm glad that they implemented some basic library functions 10 years down the line.
  - tick_tock_tick 3y ago
    Yeah no offense but most of the people online that I find complaining about Go used it a long time ago or got their talking points pre-generics and haven't touched it or really looked at it since then.

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

patmorgan23 3y ago
And it's funny because go has a whole http server in the standard lib, but not minimum?
- kevincox 3y ago
  It couldn't have a minimum before generics. The function was not expressible in the general case. So they either would have had to add `minByte`, `minInt`, `minStr`, ... or make it a builtin generic. And every builtin is an admission that the language was not powerful enough, so those are kept to a minimum.
- porjo 3y ago
  There is 'min': https://go.dev/ref/spec#Min_and_max https://go.dev/ref/spec#Min_and_max
  - richbell 3y ago
    Since v1.21, which wasn't released that long ago.
- yobert 3y ago
  I know it sounds funny, but I have used the built in "net/http" in probably fifty projects now, and not a single one of them needed a min/max function.

amelius 3y ago

I tried Go for about a day, and the exception handling and null-pointer issues were exactly the things that made me lose interest.

bborud 3y ago
One day is not enough to even get a superficial understanding of any language. People tend to always exaggerate how little time it takes to learn a language to a meaningful degree. Sure, the first day I tried Go I was able to accomplish something useful, but it took me a few months to develop a basic understanding of how you use Go in an idiomatic manner. I'd say it took at least a couple of years before I could say I "knew" Go. And it wasn't exactly love at first sight. My initial impression of Go was that it was a bit too much like C, and, coming from Java, I was a bit confused about how you structure things. That takes time to figure out for any language. What sold me on Go eventually was that for my uses (writing multi-protocol server applications that run on multiple architectures), it resulted in code that was very readable and productivity more than doubled because Go is a lot less fussy to work in than Java. Both in terms of encouraging more minimal designs and having a lot less fragility.
- Cthulhu_ 3y ago
  I disagree; you can learn 90% of Go in an afternoon. However, you also do have a point; the power of Go is not apparent in an afternoon, but in longer term and larger projects spanning years or decades, and hundreds or thousands of developers. It was made by and for Google to solve Google's problems, which include millions of LOC written and read by thousands of engineers over the span of decades. So while at first you think "eww, err != nil everywhere", at least in a decade of reading your own or someone elses' code you'll know exactly what's going on. How many languages are similar? I feel like a lot of languages in the past decade have had a steady migration in things like error handling, so 10 year old Java code is incomparable to today's Java. Whether that's a good thing (the language has evolved and is now more ergonomic) or a bad thing (I no longer know what's going on here) is the big debate.
  - 3y ago

Gibbon1 3y ago

I feel like the pointer stuff you could handle safely in a modern language. Because I think pointer and array notation are convertible so one isn't scarier than the other. But yeah not being able to tag pointers as 'can't be null' and have the compiler enforce that ignores everything we've learned in the last 40 years. You shouldn't be able to pass a potentially null pointer to a routine that can't deal with it. You end up with code finding a null pointer without any context that tells it what to do with that. Or it panics.

madeofpalk 3y ago
Using pointers just to get a 'null' is just an annoying hack reflective of poor design. Instead, "no value" should be able to be directly represented.
- Cthulhu_ 3y ago
  In Go that's the zero value, which is usually things like empty string, 0, [], etc; in most cases that's good enough.

morsecodist 3y ago

I could not agree more with this. Go is so frustrating to me because there is so much I like but these things you listed make it miserable for me to use. A basic option and result type could fix a lot of the issues around errors and null pointers. I know languages like Scala, Haskell, and Rust have type systems that are often considered too complex but Go doesn't need all that to add these two.

phplovesong 3y ago
Having used Ocaml for quite some time, i can understand this. However, i cant tell people (junior devs, or devs who just want to work and does not care about comp-soyery) to learn an ML (+ all the FP idioms) with a straight face. Having a (val, err) tuple IS more easy than returning a monad. Sometimes (most times?) pure procedural code is just the best, and i really hate languages that have feature X but does not support it fully. As an example i would not be happy with an monadic return type if the language did not have the option to use some sort of bind/return combo, and have full pattern matching support. Thats why i champion Go for larger teams. Almost anyone can join the team in dive in without much previous Go knowledge. This is a rare feature and i dont know many other languages that has this property.
- morsecodist 3y ago
  You really don't need to think about monads or functional programming to have option and result. The focus on explaining these in the context of sum types and monads only serves to distract most people. A list is a monad and people use them every day and they are fine. > Having a (val, err) tuple IS more easy than returning a monad. Arguments about which concept is easier for people to understand pretty quickly descend into subjectivity but I don't believe this is universally true. Why am I getting a value when there's an error? What do I return as my value when returning errors? Explaining to someone that a function returns (val, err) and only one of these values will be significant is more or less the same as describing a result. Option is even simpler. It's a list that can have at most one item. Or, you know how in python you can set a variable to None? Here's how to do it in a strongly typed language.
3y ago

bunderbunder 3y ago

This roughly lines up with my feelings. Go is a solid improvement over many languages that we inherited from the 70s, 80s and 90s. But it also retains a certain "we don't need a robust type system; weak-ish static typing is good enough" ethos that made sense in back then, when compilers were hard enough to write that it was easier to justify making the programmer handle more things manually for the sake of simplifying the compiler authors' job. This is always a tradeoff, of course, but I think that the optimum balance has shifted even further in favor of programmers. Some of Go's decisions still made sense in the 2000s when the language was first being created. But now, 15 or so years later, I think many of us could be forgiven for wishing for a language that's a lot like Go except that it dared to dream just a little bit bigger.

d0mine 3y ago
> 70s, 80s and 90s It reminded me of Go vs. Algol-69 http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
bborud 3y ago
Language design is always easier in retrospect. It is harder than it looks, and often harder than the people designing a language realize before it is too late. I think it was a good choice to take smaller steps and try to not be too ambitious too soon. Sure, Go isn't the most sexy language from an academic point of view, but it has a certain conservative and pragmatic approach that does work. It does generally result in code that is a lot easier to read and maintain than is my experience with C, C++, Java, C# and a few other languages I've worked in. Go is an engineering language - not an academic exercise. Take, for instance, the approach to generics. They could have designed that in from the beginning, but they showed restraint and didn't. That probably took a fair bit of courage. It is my impression that they hadn't figured out what generics should look like in Go, so they postponed until they had a better feel for how it ought to be done. Rather than risk making choices that would be hard (impossible?) to rectify later. When you add something to a language there is always the risk that you make it worse. (I'm not making any qualitative judgements on Go generics since, frankly, I don't feel qualified. I make very sparing use of it because it really isn't that often I actually need to make use of it) People tend to forget that Java didn't have generics until 1.5 (or 5.0 or however they prefer to version it now) - about 9 years after first being launched. And to be frank, that was not a fun experience at all. Not so much because there was something wrong with the design, but because suddenly a lot of people went overboard and started designing really hairy types that could be hard to figure out and use. If you consider C++: C++ spent 20+ years flailing wildly and the result was that you got lots of different C++ "traditions", subsets and practices. Sometimes within the same company. Depending on which era or tradition a C++ codebase is from you may have to adjust to a wholly different way of programming from what you are used to or prefer. And as for generic programming: in what world is STL a neat solution? And to this day, compilers are slow, they produce rubbish error messages, the toolchain still feels like a 1970s ad-hoc mess, and there is no definitive way to build things, resulting in lots and lots of additional complexity when trying to tame the horrific tool chain. Sure, they could have put loads of stuff in Go from the beginning. But I think they would have gotten a lot more wrong if they had. I really appreciate that they are evolving the language slowly and conservatively.

deleted 3y ago

[deleted]

tick_tock_tick 3y ago

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". Does https://pkg.go.dev/slices#DeleteFunc https://pkg.go.dev/slices#DeleteFunc not work for you or do you need it to be called filter? It's there for maps too https://pkg.go.dev/maps#DeleteFunc https://pkg.go.dev/maps#DeleteFunc

mFixman 3y ago
To be honest, I used to use Go before generics became a thing. I'm glad that they implemented some basic library functions 10 years down the line.
- tick_tock_tick 3y ago
  Yeah no offense but most of the people online that I find complaining about Go used it a long time ago or got their talking points pre-generics and haven't touched it or really looked at it since then.