4 ms·

> Frankly, people make too big a deal about generics. Different strokes for different folks, but I think generics are a huge deal. They make libraries so much

> Frankly, people make too big a deal about generics. Different strokes for different folks, but I think generics are a huge deal. They make libraries so much more ergonomic and reduce toil generally. It's a case of dealing with many, many small papercuts over a long period of time rather than a big-bang sort of thing. > tooling quality I'm a huge proponent of tools, so much so that I worked on programming language tools for 5 years. My perspective is that tools are there to optimize an existing experience, but reach a local maxima in the overall experience because they're limited by language semantics. When you improve language semantics, tools get to improve experience again. That's why it's so important to do language design in a way that strongly considers the tooling experience, and a big reason why you see so much love for languages like TypeScript and C#. They work hand in hand. And generics are an example of how semantics can push tools to be better.

throwaway894345 5y ago
When I think about tooling, I'm thinking about things like build systems and dependency managers. In Go, I don't need to script my own build system like I would do in C, C++, Java, etc. Similarly, reproducible package management works out of the box--I don't need to try in vain to get the right versions of the right dependencies installed to the right locations like I do in C and C++ (and Python, to a lesser extent). Moreover, Go produces native static binaries out of the box by default--I don't have to cobble together a bunch of configuration in every one of my projects only to have it broken by the odd transitive dependency which can't be statically compiled (well, this is probably the case in some Go packages, but I contend that it's far rarer than in the Java, Python, Rust, etc worlds--certainly I've never run into this in my decade with Go). Further still, in Go, I don't have to write CI pipelines to build and publish code packages nor documentation packages. And then there is the toil reduced by having good performance. I have about 15 years of experience with Python, and almost invariably there's some hot path in the code which needs something between Python's level of performance and Go's level of performance. Unlike Go, Python affords relatively little headroom for optimization--you can't easily parallelize anything or pull some allocation out of a tight loop for a 10x performance gain. Usually this looks like rearchitecting your codebase so that "rewrite the hotpath in C/multiprocessing/etc" is attainable and on top of that you're probably implying significant changes to your build system and/or runtime environment as well as a load of maintainability problems associated with anything that touches the language/process boundary. By comparison, I think the gains from generics are relatively small.
- phillipcarter 5y ago
  > I'm thinking about things like build systems and dependency managers. Ah, that's a different kind of tooling. This matters, but there are loads of developers out there who care just as much (if not more) about IDE tooling and other things that assist in the writing and refactoring of source code itself. Features like generics open up new ways to make this tooling better. It's also worth pointing out that you can have your cake and eat it too. .NET and Rust are fine examples of having great build/package management tooling, runtime performance, compiler performance (.NET far more than Rust), artifact management, and so on. And great IDE tooling in different environments.
  - throwaway894345 5y ago
    Yes, I agree that IDE tooling is nice and that it doesn’t conflict with having good build tooling; my only point is that, given the choice between good tooling and generics (or any type system feature), I would choose the tooling hands down every single time.
    - phillipcarter 5y ago
      Why make it an either/or thing? We should demand more of corporate-controlled software. The money exists to make both a reality.
      - throwaway894345 5y ago
        I was speaking about evaluating languages, especially existing ones. If you pick a language based on type system without considering other factors, you’ll end up in a bad place. If you pick a language with good tooling/ecosystem and a mediocre type system, you’ll still be in a pretty good place. As far as I know, there aren’t many general purpose languages with good type systems and tooling.

throwaway894345 5y ago

When I think about tooling, I'm thinking about things like build systems and dependency managers. In Go, I don't need to script my own build system like I would do in C, C++, Java, etc. Similarly, reproducible package management works out of the box--I don't need to try in vain to get the right versions of the right dependencies installed to the right locations like I do in C and C++ (and Python, to a lesser extent). Moreover, Go produces native static binaries out of the box by default--I don't have to cobble together a bunch of configuration in every one of my projects only to have it broken by the odd transitive dependency which can't be statically compiled (well, this is probably the case in some Go packages, but I contend that it's far rarer than in the Java, Python, Rust, etc worlds--certainly I've never run into this in my decade with Go). Further still, in Go, I don't have to write CI pipelines to build and publish code packages nor documentation packages. And then there is the toil reduced by having good performance. I have about 15 years of experience with Python, and almost invariably there's some hot path in the code which needs something between Python's level of performance and Go's level of performance. Unlike Go, Python affords relatively little headroom for optimization--you can't easily parallelize anything or pull some allocation out of a tight loop for a 10x performance gain. Usually this looks like rearchitecting your codebase so that "rewrite the hotpath in C/multiprocessing/etc" is attainable and on top of that you're probably implying significant changes to your build system and/or runtime environment as well as a load of maintainability problems associated with anything that touches the language/process boundary. By comparison, I think the gains from generics are relatively small.

phillipcarter 5y ago
> I'm thinking about things like build systems and dependency managers. Ah, that's a different kind of tooling. This matters, but there are loads of developers out there who care just as much (if not more) about IDE tooling and other things that assist in the writing and refactoring of source code itself. Features like generics open up new ways to make this tooling better. It's also worth pointing out that you can have your cake and eat it too. .NET and Rust are fine examples of having great build/package management tooling, runtime performance, compiler performance (.NET far more than Rust), artifact management, and so on. And great IDE tooling in different environments.
- throwaway894345 5y ago
  Yes, I agree that IDE tooling is nice and that it doesn’t conflict with having good build tooling; my only point is that, given the choice between good tooling and generics (or any type system feature), I would choose the tooling hands down every single time.
  - phillipcarter 5y ago
    Why make it an either/or thing? We should demand more of corporate-controlled software. The money exists to make both a reality.
    - throwaway894345 5y ago
      I was speaking about evaluating languages, especially existing ones. If you pick a language based on type system without considering other factors, you’ll end up in a bad place. If you pick a language with good tooling/ecosystem and a mediocre type system, you’ll still be in a pretty good place. As far as I know, there aren’t many general purpose languages with good type systems and tooling.