8 ms·

Frankly, having used Go for years, I started using generics right after they were released and I'm very happy with them so far. Sure, the performance character

Frankly, having used Go for years, I started using generics right after they were released and I'm very happy with them so far. Sure, the performance characteristics could be improved, but other than that they solve all my main pain points I wanted them to solve while being constrained enough to not result in ivory towers on every corner. My main pain points having been duplicated functions for each type as well as data structures.

bsudnshdbd 4y ago
haolez 4y ago
Where you see "modern", I see complicated type systems that solve the least interesting pains when programming. What they do provide is a feeling of "solving a puzzle" when all your type signatures are matching your usage patterns, but then again it's easy to mistake the puzzle solving with actual productivity. Rich Hickey's talks can be very insightful in this regard. He surely convinced me :)
- throwaway894345 4y ago
  I think type systems have diminishing returns. I’ve used Python professionally for 15 years and a whole lot of time is wasted trying to figure out exactly what properties a given parameter must have. In the best case, you have stuff like “file like object” which doesn’t tell you if it just needs a “read()” method or also write, seek, close, etc. In the common cases you have annotations that are incorrect or outdated. On the other extreme, you have Rust and Haskell type systems where you spend gratuitous time on pacifying the type checker for negligible quality gains (arguably negative gains). I always felt Go hit the sweet spot.
  - klabb3 4y ago
    Violently agreeing with this. Both extremes hinder productivity, just at different times during the development cycles. It's easy to confuse type systems with correctness or clarity of thought. I've fallen victim to this myself – "oh this didn't map well to Rust's type system, I must be thinking wrong", kinda. It tickles this ocd nerve and I lose focus on the problem I'm trying to solve, often without realizing that I'm just wasting time. I also like Go for these reasons. It's dumb and predictable, which let's me focus on the problem I'm solving. My only annoyance is really verbosity and small amounts of boilerplate.
    - throwaway894345 4y ago
      Yeah, and there is a time and place for rigorous static analysis. If you’re writing embedded code for a car which is mission critical and prohibitively expensive to update frequently (firmware updates require people to bring their cars into dealerships for technicians to update), then you probably want to verify everything you can. On the other extreme you have SaaS software where you can get a bug report, diagnose it, and deploy a patch in an afternoon and no one’s life is at jeopardy (but the rewards for rapid iteration are huge). Unfortunately, this nuance is missing from the discussion with people mostly talking about software as though it’s all mission critical / infrequently updated / rapid iteration doesn’t matter which is exactly incorrect for the general case.
- sanderjd 4y ago
  My counterpoint: I find it very hard to mistake writing a bunch of tedious repetitive code with productivity.
  - cube2222 4y ago
    Fortunately, we now have Copilot to write it. I'm not kidding. Go is at a very nice verbosity level as far as reading code goes, but writing it is indeed tedious occasionally. However, in practice, Copilot is able to handle those bits extremely well, giving us the best of both worlds.
    - LAC-Tech 4y ago
      But what the code reviewers - aren't they the real victims?
    - sanderjd 4y ago
      How does it do if I need to change one small thing in every copy of the code I generated? (Edit: This is a serious question; I recently semi-seriously commented that maybe solutions like Copilot are particularly well suited to solve this problem with Go, so I'm curious how well it works in practice.)
      - erik_seaberg 4y ago
        It should always be regenerated as a compilation target, never maintained by developers made of meat.
        sanderjd 4y ago
        What should? Are we talking about the same thing? My understanding of the Copilot workflow is that you use it as a programmer to "write" code by accepting suggestions and then checking the suggested code in as if you had written it the normal way.
        4y ago
- bitwize 4y ago
  When programming in the small, I can see where a robust type system might feel like it's adding complexity and "getting in the way". When programming in the large, type systems are flat out an unmitigated win. The more you can confidently assert about your program before run time, the more time and money your team will save. If you are programming a large system and not using strong static typing, optimally with higher-level features like parametric types, then you are doing it wrong.
  - haolez 4y ago
    Not necessarily. This smells like a badly architected system with strong coupling and mixing of concerns. The overall complexity of the complete solution doesn't have to make each small module complex as well. And if the modules are not complex, type systems are not strictly necessary.
- LAC-Tech 4y ago
  I think my sweet spot is gradual typing. In the early stages of developing something complex you often want to play fast and loose with the type system - get some code running, and some tests set up, and go from there. But later on you want to refine it and start catching some more errors statically. The pendulum has swung really far to static typing - and I get why. But if it swings back I hope we don't forget about gradual typing.
  - eweise 4y ago
    Gradual typing sounds like the worst of all worlds. You end up having to type things so you lose the supposed implementation speed of dynamic typing. But then you also can't rely on all the types being checked.
    - acoard 4y ago
      I'd argue it's the exact opposite - the best of both worlds. But it is what you make of it. The poster child of gradual typing has to be TypeScript, and it's been a wild success. TypeScript allows gradual implementation to any JavaScript project and there's almost a million small different gradients you can use. From simply using a js file, to noImplicitAny, to simple types, to using complicated built-in types (eg Partials). With TypeScript, you never lose the speed of dynamic typing. The whole point of gradual typing is you can jump between more and less types, so at no point are you restricted from reverting to full dynamic typing. And it is true, you can't rely on all types being checked, but the point is you add it to the important/stable bits. And having your largely stable important bits being typed while your more experimental unstable code can be dynamic (while still getting the benefit of consuming the stable types) is a nice place to be. As I said, it is what you make of it. If you spend all your time typing the unstable bits and leave the stable core bits untyped, well, you've just wasted your time and would get the worst of both worlds.
      - eweise 4y ago
        My only experience with gradual typing is in Dart and I was surprised that I got runtime errors around types that should have been correct. I don't follow Typescript but guessing its a wild success because it checks your types and gradual typing is a way to incrementally adopt the language. Regarding wasting time, type inference takes a lot of boilerplate out of the strictly typed code.
Winsaucerer 4y ago
With Go, I use a decent amount of generated code to create repetitive bits of code that only have small variations (e.g., the type!). Most of this code seems to not be possible for me to replace with generics yet, so I'm still finding myself using generated code. For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface.
- xyzzyz 4y ago
  > For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface. You can easily and cleanly work around this by exposing getter and setter method in your interface.
  - tapirl 4y ago
    but is it cleanly? BTW, accessing common fields is temporarily disabled before releasing Go 1.18, because there is another fundamental problem which needs to be resolved firstly. ref: https://github.com/golang/go/issues/51259 https://github.com/golang/go/issues/51259
    - deleted 4y ago
      [deleted]
    - throwaway894345 4y ago
      Right. It’s definitely not “clean” IMO.
      - xyzzyz 4y ago
        Which other language has interfaces specifying field access, that does not go through indirect method call anyway? I guess if you consider C++ templates to be interfaces, that would apply, but C++ templates are even less clean (given that there isn’t even any clean way to specify interface expected by C++ template, all you have is type traits, which are opposite of clean).

bsudnshdbd 4y ago

haolez 4y ago

Where you see "modern", I see complicated type systems that solve the least interesting pains when programming. What they do provide is a feeling of "solving a puzzle" when all your type signatures are matching your usage patterns, but then again it's easy to mistake the puzzle solving with actual productivity. Rich Hickey's talks can be very insightful in this regard. He surely convinced me :)

throwaway894345 4y ago
I think type systems have diminishing returns. I’ve used Python professionally for 15 years and a whole lot of time is wasted trying to figure out exactly what properties a given parameter must have. In the best case, you have stuff like “file like object” which doesn’t tell you if it just needs a “read()” method or also write, seek, close, etc. In the common cases you have annotations that are incorrect or outdated. On the other extreme, you have Rust and Haskell type systems where you spend gratuitous time on pacifying the type checker for negligible quality gains (arguably negative gains). I always felt Go hit the sweet spot.
- klabb3 4y ago
  Violently agreeing with this. Both extremes hinder productivity, just at different times during the development cycles. It's easy to confuse type systems with correctness or clarity of thought. I've fallen victim to this myself – "oh this didn't map well to Rust's type system, I must be thinking wrong", kinda. It tickles this ocd nerve and I lose focus on the problem I'm trying to solve, often without realizing that I'm just wasting time. I also like Go for these reasons. It's dumb and predictable, which let's me focus on the problem I'm solving. My only annoyance is really verbosity and small amounts of boilerplate.
  - throwaway894345 4y ago
    Yeah, and there is a time and place for rigorous static analysis. If you’re writing embedded code for a car which is mission critical and prohibitively expensive to update frequently (firmware updates require people to bring their cars into dealerships for technicians to update), then you probably want to verify everything you can. On the other extreme you have SaaS software where you can get a bug report, diagnose it, and deploy a patch in an afternoon and no one’s life is at jeopardy (but the rewards for rapid iteration are huge). Unfortunately, this nuance is missing from the discussion with people mostly talking about software as though it’s all mission critical / infrequently updated / rapid iteration doesn’t matter which is exactly incorrect for the general case.
sanderjd 4y ago
My counterpoint: I find it very hard to mistake writing a bunch of tedious repetitive code with productivity.
- cube2222 4y ago
  Fortunately, we now have Copilot to write it. I'm not kidding. Go is at a very nice verbosity level as far as reading code goes, but writing it is indeed tedious occasionally. However, in practice, Copilot is able to handle those bits extremely well, giving us the best of both worlds.
  - LAC-Tech 4y ago
    But what the code reviewers - aren't they the real victims?
  - sanderjd 4y ago
    How does it do if I need to change one small thing in every copy of the code I generated? (Edit: This is a serious question; I recently semi-seriously commented that maybe solutions like Copilot are particularly well suited to solve this problem with Go, so I'm curious how well it works in practice.)
    - erik_seaberg 4y ago
      It should always be regenerated as a compilation target, never maintained by developers made of meat.
      - sanderjd 4y ago
        What should? Are we talking about the same thing? My understanding of the Copilot workflow is that you use it as a programmer to "write" code by accepting suggestions and then checking the suggested code in as if you had written it the normal way.
        4y ago
bitwize 4y ago
When programming in the small, I can see where a robust type system might feel like it's adding complexity and "getting in the way". When programming in the large, type systems are flat out an unmitigated win. The more you can confidently assert about your program before run time, the more time and money your team will save. If you are programming a large system and not using strong static typing, optimally with higher-level features like parametric types, then you are doing it wrong.
- haolez 4y ago
  Not necessarily. This smells like a badly architected system with strong coupling and mixing of concerns. The overall complexity of the complete solution doesn't have to make each small module complex as well. And if the modules are not complex, type systems are not strictly necessary.
LAC-Tech 4y ago
I think my sweet spot is gradual typing. In the early stages of developing something complex you often want to play fast and loose with the type system - get some code running, and some tests set up, and go from there. But later on you want to refine it and start catching some more errors statically. The pendulum has swung really far to static typing - and I get why. But if it swings back I hope we don't forget about gradual typing.
- eweise 4y ago
  Gradual typing sounds like the worst of all worlds. You end up having to type things so you lose the supposed implementation speed of dynamic typing. But then you also can't rely on all the types being checked.
  - acoard 4y ago
    I'd argue it's the exact opposite - the best of both worlds. But it is what you make of it. The poster child of gradual typing has to be TypeScript, and it's been a wild success. TypeScript allows gradual implementation to any JavaScript project and there's almost a million small different gradients you can use. From simply using a js file, to noImplicitAny, to simple types, to using complicated built-in types (eg Partials). With TypeScript, you never lose the speed of dynamic typing. The whole point of gradual typing is you can jump between more and less types, so at no point are you restricted from reverting to full dynamic typing. And it is true, you can't rely on all types being checked, but the point is you add it to the important/stable bits. And having your largely stable important bits being typed while your more experimental unstable code can be dynamic (while still getting the benefit of consuming the stable types) is a nice place to be. As I said, it is what you make of it. If you spend all your time typing the unstable bits and leave the stable core bits untyped, well, you've just wasted your time and would get the worst of both worlds.
    - eweise 4y ago
      My only experience with gradual typing is in Dart and I was surprised that I got runtime errors around types that should have been correct. I don't follow Typescript but guessing its a wild success because it checks your types and gradual typing is a way to incrementally adopt the language. Regarding wasting time, type inference takes a lot of boilerplate out of the strictly typed code.

Winsaucerer 4y ago

With Go, I use a decent amount of generated code to create repetitive bits of code that only have small variations (e.g., the type!). Most of this code seems to not be possible for me to replace with generics yet, so I'm still finding myself using generated code. For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface.

xyzzyz 4y ago
> For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface. You can easily and cleanly work around this by exposing getter and setter method in your interface.
- tapirl 4y ago
  but is it cleanly? BTW, accessing common fields is temporarily disabled before releasing Go 1.18, because there is another fundamental problem which needs to be resolved firstly. ref: https://github.com/golang/go/issues/51259 https://github.com/golang/go/issues/51259
  - deleted 4y ago
    [deleted]
  - throwaway894345 4y ago
    Right. It’s definitely not “clean” IMO.
    - xyzzyz 4y ago
      Which other language has interfaces specifying field access, that does not go through indirect method call anyway? I guess if you consider C++ templates to be interfaces, that would apply, but C++ templates are even less clean (given that there isn’t even any clean way to specify interface expected by C++ template, all you have is type traits, which are opposite of clean).