6 ms·

I have been following Go since before it even had a Windows build. I love that everything I learned back in 2011 when I finally started experimenting with it, s

I have been following Go since before it even had a Windows build. I love that everything I learned back in 2011 when I finally started experimenting with it, still applies. I never got the opportunity to work with it, so most of my efforts with Go have been small one off projects to learn it. Only thing that bothered me was hearing an interview with the Go devs where one of the key devs sounded like Generics would never make its way into Go and it put me off the way he seemed so adamantly against such a feature, but now that generics are in I might start doing some of my side projects with Go moving forward just to force myself to become more familiar with Go.

BugsJustFindMe 2y ago
> Only thing that bothered me was hearing an interview with the Go devs where one of the key devs sounded like Generics would never make its way into Go and it put me off the way he seemed so adamantly against such a feature Everything about the development trajectory of Go so far indicates that What Is Right And Good at any given moment is largely determined by whatever makes building the compiler easier and not what makes the lives of external developers easier, until the external developers get loud enough about how the language is failing to learn from the mistakes of the past that the internal team relents with an "ok, ok, you win, our bad". And if I never see another apologist refrain of "You don't need <x>. Just use this code generator to flood your repo with thousands of lines of project-specific-for-no-good-reason boilerplate" again it will be too soon.
- maccard 2y ago
  Code generation has a time and a place, but that time and place isn't replacing missing language features.
  - XorNot 2y ago
    I really wish proper enum types would be added. You always codegen them, but it's the same code everytime.
    - therein 2y ago
      Same. People go around listing relatively controversial improvements but I think we can all agree on this one. It is the one that'd make my life easier the most when it comes to day to day stuff.
      - elvlysh 2y ago
        I don't really agree. I find Iota perfectly serviceable.
- throwaway894345 2y ago
  I think most Go devs have been pretty happy with Go’s trajectory. I think it’s mostly the people who aren’t using Go and are unlikely to start using Go no matter its feature set who are the ones who are mostly ignored. It has also been a really good thing that Go “doesn’t learn from the ‘mistakes’ of the past” or else it would have exceptions and monads and lifetimes and inheritance and a Haskell-like syntax. Go isn’t perfect, but it’s wildly more productive in my experience than any other language, and that matters a lot more to me than being able to be maximally expressive or abstract.
  - renhanxue 2y ago
    I've coded golang for four years. Web services. I hated it at the start and I hate it even more now. The generics are miserable to use and are very limited in what they can do, the standard library is awful (database/sql in particular is offensively bad, but you have to use it because all the third party tools rely on its interfaces), there's footguns and dangerous syntax subtleties everywhere, and the idea of the zero values for uninitialized struct fields is to me an even worse mistake than the concept of null. At least if you make a mistake with null the program crashes, which is obvious, instead of just silently doing the wrong thing, which is not. The language claims to be simple; it's not, it's just pointlessly restrictive in weird ways wherever it happens to offend Rob Pike's personal sense of aesthetics. At least it compiles quickly, I guess??? I wish we could use some boring language that works, like C# or Kotlin.
    - elvlysh 2y ago
      More than one person designed the language than Pike, you know. He's retired. Maybe you can find another member of the devteam to pick on?
      - renhanxue 2y ago
        Both (for example) Russ Cox and Ian Lance Taylor have contributed some very notably bad ideas to the project, yes. Does rephrasing it to "Rob Pike and people who think like him" make you happier?
- dimgl 2y ago
  Have you ever used Golang? I have not needed to use codegen once.
  - BugsJustFindMe 2y ago
    It should be trivial for you to google for go code generation and the cases and reasons for it. That you've personally never done it speaks only to the bounds of the work you've done.
    - dimgl 2y ago
      I’m playing devil’s advocate. Again, I worked with Go in a production setting for 3+ years and didn’t need to do any code generation. Maybe my use case was simple… or maybe it’s unnecessary.
      - BugsJustFindMe 2y ago
        > I’m playing devil’s advocate. https://shkspr.mobi/blog/2019/11/you-are-not-the-devils-advocate/ https://shkspr.mobi/blog/2019/11/you-are-not-the-devils-advo... > Again, I worked with Go in a production setting for 3+ years The amount of time you spent doing whatever you were doing is not relevant. The google search you seek is mere keystrokes away.
        dimgl 2y ago
        Can you show me? You keep talking about Google search and yet haven't brought up a single example.
MisterTea 2y ago
The creators came from Bell Labs and are known to be pragmatic where needed as well as deeply think about a problem and how to solve it correctly. Languages are foundational so getting things right the first time is critical to building a stable ecosystem. Honestly, I am glad they pushed back against the constant demands and gave themselves time to think about the problem.
- pas 2y ago
  Go is definitely a step up from C (and from C++ in many important ways), but maybe they could have spent a tiny bit more of that deep thinking about the problem of error handling, so they would have come up with something better than `if err != nil {}` ... no? Just me? Hm, okay.
  - bee_rider 2y ago
    To be fair, though, error handling is terrible in every language, independent of how much the designers think about it.
    - deleted 2y ago
      [deleted]
    - XorNot 2y ago
      Seriously. For the amount people glaze Rust on HN, error handling when you actually try to use Rust is overtly discussed as "oh yeah it's completely broken, most people try to replace the whole thing..."
      - vlovich123 2y ago
        Huh? I find error handling in Rust to be quite nice to use. You do probably want to use thiserror to make it easier to define the Error type for your crate, but other than that it's super smooth IMO.
    - kibwen 2y ago
      Let's not flirt with false equivalences. I've seen languages that do error handling worse than Go. I've also seen languages that do better.
geodel 2y ago
My thinking is you are better off without Go. There is no way to stop Go devs from saying something again you may not like and at that point your effort in using Go would be a waste.
- mappu 2y ago
  Is any language immune from that?
divan 2y ago
I’ve been using Go since shortly after it got Windows support. I’ve used it across both small and large codebases — for tooling, libraries, fun experiments, serious side projects, and as the main language for backend systems. I even used it on the frontend with GopherJS. Still use it daily. Since generics were introduced in Go 1.18, I’ve used them exactly zero times. I’ve had zero need for them. I still haven’t encountered generics in any of the real-world code I work with — and honestly, I’ve dreaded the day I’d see something like `func Foo[K comparable, V any, R any, F ~func(K, V) R](m map[K]V, f F) map[K]R {` That’s exactly the kind of code I try to avoid — unless I plan to replace every developer with an AI.

BugsJustFindMe 2y ago

> Only thing that bothered me was hearing an interview with the Go devs where one of the key devs sounded like Generics would never make its way into Go and it put me off the way he seemed so adamantly against such a feature Everything about the development trajectory of Go so far indicates that What Is Right And Good at any given moment is largely determined by whatever makes building the compiler easier and not what makes the lives of external developers easier, until the external developers get loud enough about how the language is failing to learn from the mistakes of the past that the internal team relents with an "ok, ok, you win, our bad". And if I never see another apologist refrain of "You don't need <x>. Just use this code generator to flood your repo with thousands of lines of project-specific-for-no-good-reason boilerplate" again it will be too soon.

maccard 2y ago
Code generation has a time and a place, but that time and place isn't replacing missing language features.
- XorNot 2y ago
  I really wish proper enum types would be added. You always codegen them, but it's the same code everytime.
  - therein 2y ago
    Same. People go around listing relatively controversial improvements but I think we can all agree on this one. It is the one that'd make my life easier the most when it comes to day to day stuff.
    - elvlysh 2y ago
      I don't really agree. I find Iota perfectly serviceable.
throwaway894345 2y ago
I think most Go devs have been pretty happy with Go’s trajectory. I think it’s mostly the people who aren’t using Go and are unlikely to start using Go no matter its feature set who are the ones who are mostly ignored. It has also been a really good thing that Go “doesn’t learn from the ‘mistakes’ of the past” or else it would have exceptions and monads and lifetimes and inheritance and a Haskell-like syntax. Go isn’t perfect, but it’s wildly more productive in my experience than any other language, and that matters a lot more to me than being able to be maximally expressive or abstract.
- renhanxue 2y ago
  I've coded golang for four years. Web services. I hated it at the start and I hate it even more now. The generics are miserable to use and are very limited in what they can do, the standard library is awful (database/sql in particular is offensively bad, but you have to use it because all the third party tools rely on its interfaces), there's footguns and dangerous syntax subtleties everywhere, and the idea of the zero values for uninitialized struct fields is to me an even worse mistake than the concept of null. At least if you make a mistake with null the program crashes, which is obvious, instead of just silently doing the wrong thing, which is not. The language claims to be simple; it's not, it's just pointlessly restrictive in weird ways wherever it happens to offend Rob Pike's personal sense of aesthetics. At least it compiles quickly, I guess??? I wish we could use some boring language that works, like C# or Kotlin.
  - elvlysh 2y ago
    More than one person designed the language than Pike, you know. He's retired. Maybe you can find another member of the devteam to pick on?
    - renhanxue 2y ago
      Both (for example) Russ Cox and Ian Lance Taylor have contributed some very notably bad ideas to the project, yes. Does rephrasing it to "Rob Pike and people who think like him" make you happier?
dimgl 2y ago
Have you ever used Golang? I have not needed to use codegen once.
- BugsJustFindMe 2y ago
  It should be trivial for you to google for go code generation and the cases and reasons for it. That you've personally never done it speaks only to the bounds of the work you've done.
  - dimgl 2y ago
    I’m playing devil’s advocate. Again, I worked with Go in a production setting for 3+ years and didn’t need to do any code generation. Maybe my use case was simple… or maybe it’s unnecessary.
    - BugsJustFindMe 2y ago
      > I’m playing devil’s advocate. https://shkspr.mobi/blog/2019/11/you-are-not-the-devils-advocate/ https://shkspr.mobi/blog/2019/11/you-are-not-the-devils-advo... > Again, I worked with Go in a production setting for 3+ years The amount of time you spent doing whatever you were doing is not relevant. The google search you seek is mere keystrokes away.
      - dimgl 2y ago
        Can you show me? You keep talking about Google search and yet haven't brought up a single example.

MisterTea 2y ago

The creators came from Bell Labs and are known to be pragmatic where needed as well as deeply think about a problem and how to solve it correctly. Languages are foundational so getting things right the first time is critical to building a stable ecosystem. Honestly, I am glad they pushed back against the constant demands and gave themselves time to think about the problem.

pas 2y ago
Go is definitely a step up from C (and from C++ in many important ways), but maybe they could have spent a tiny bit more of that deep thinking about the problem of error handling, so they would have come up with something better than `if err != nil {}` ... no? Just me? Hm, okay.
- bee_rider 2y ago
  To be fair, though, error handling is terrible in every language, independent of how much the designers think about it.
  - deleted 2y ago
    [deleted]
  - XorNot 2y ago
    Seriously. For the amount people glaze Rust on HN, error handling when you actually try to use Rust is overtly discussed as "oh yeah it's completely broken, most people try to replace the whole thing..."
    - vlovich123 2y ago
      Huh? I find error handling in Rust to be quite nice to use. You do probably want to use thiserror to make it easier to define the Error type for your crate, but other than that it's super smooth IMO.
  - kibwen 2y ago
    Let's not flirt with false equivalences. I've seen languages that do error handling worse than Go. I've also seen languages that do better.

geodel 2y ago

My thinking is you are better off without Go. There is no way to stop Go devs from saying something again you may not like and at that point your effort in using Go would be a waste.

mappu 2y ago
Is any language immune from that?

divan 2y ago

I’ve been using Go since shortly after it got Windows support. I’ve used it across both small and large codebases — for tooling, libraries, fun experiments, serious side projects, and as the main language for backend systems. I even used it on the frontend with GopherJS. Still use it daily. Since generics were introduced in Go 1.18, I’ve used them exactly zero times. I’ve had zero need for them. I still haven’t encountered generics in any of the real-world code I work with — and honestly, I’ve dreaded the day I’d see something like `func Foo[K comparable, V any, R any, F ~func(K, V) R](m map[K]V, f F) map[K]R {` That’s exactly the kind of code I try to avoid — unless I plan to replace every developer with an AI.