5 ms·

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

by 15155 11y ago

xrstf 11y ago
Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/
- masklinn 11y ago
  A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
  - AnimalMuppet 11y ago
    Slower to compile, but starting from a much faster starting point.
  - dekhn 11y ago
    I'm not even aware of go compiling most of the time (it's typically under 1 second). go's build system handles these sort of things without a more complex workflow.
    - masklinn 11y ago
      > I'm not even aware of go compiling most of the time (it's typically under 1 second). That's besides the point, codegen from extra on-disk files can only be slower than codegen without extra on-disk files, so "generics are slow to compile" and "go has generate" don't make sense together, yet they are used together to assert that generics are bad and anyway go has a replacement. > go's build system handles these sort of things without a more complex workflow. No they don't. If you're using go generate you have to run go generate. That's a strictly more complex workflow than not having to run it.
      - dekhn 11y ago
        I didn't say generics were bad. I said compilation is so fast that I didn't notice it. While I agree that "strictly" your assessment is corect it's more complex, I think you're being a bit literal; it's just another command. most of my builds have hundreds of commands.
  - yokohummer7 11y ago
    This is exactly the case that the problems of a language are solved by tooling. This attitude can be easily found in the Java ecosystem, where the answer to every question is "to use IDE". Interestingly, Java recently abandoned the idea of feature stagnation and started improving the language. I'm curious when this will happen to Go.
AnimalMuppet 11y ago
> Developer time costs more than compiler time. I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.
- lmm 11y ago
  > I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the computers get faster and the developers stay the same. > Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects. No, the cost of being unable to abstract increases exponentially as your system grows. If using language X lets you cut 500 lines from a 1000-line Go project, then when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X. And you pay the cost of extra lines every time you read or debug, year after year.
  - tracker1 11y ago
    It depends on the use case... C# is a wonderful language, since the addition of generics and lambdas, it's downright beautiful to work with. But this does come with a cost... Even a simple hello world console app has a pretty significant spin up time compared to go, or anything that is truly compiled. In some cases, if you have long-lived services, then Java and .Net make sense... You can get farther with the code in place. If you are running one-off executable handlers, that need to start and finish quickly, then you probably would favor go. It's entirely possible for different options to be part of a larger solution.. and while I agree, the lack of generics is truly painful... I remember C# before, and feel that Java's generics are a horrible implementation... I'd rather wait for a nice implementation just the same.
staticint 11y ago
I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly. The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with. While that is less than ideal, I cannot see that increasing developer time by a significant margin.
- 15155 11y ago
  > It is not like someone is going to manually write out identical functions twenty times for each type they want to support. I'll stop you right there. Have you seen a modern Go codebase? They most certainly duplicate the simplest of functions, resort to `go generate`, or use reflection.
  - staticint 11y ago
    I am afraid I am not entirely sure of what you are trying to get across here. Your mere mention of go generate indicates to me that you do understand my point about computers being able to free the programmer from doing the drudgery of implementing the same generalized function twenty times. And since you are familiar with go generate, I expect you also realize there are seemingly endless tools that exist to solve this specific problem. I _think_ what you are trying to say is that templates in Go are less convenient than in some other languages. That is a completely fair assertion. But the idea of having to type `go generate` occasionally adding significant man hours to a project seems a little far fetched. You could even: alias go='go generate && go' I completely understand the appeal of templates/generics being a first-class language feature. Not even the Go authors themselves discount the usefulness. I don't understand why the lack of them is adding so many more man-hours to your projects? The overhead of working around the lack of them should not be that significant, even if less pleasant.
geon 11y ago
Slow compilers waste developer time.
- 15155 11y ago
  Incremental compiles have existed for quite some time. Go is only unique in that it can do a complete recompile in very attractive times. The only hitch, of course, is that you sacrifice features known and loved in other languages for over a decade.

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

by 15155 11y ago

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

xrstf 11y ago

Which is why Go is advocating using "go generate" to generate code. See projects such as https://clipperhouse.github.io/gen/ https://clipperhouse.github.io/gen/

masklinn 11y ago
A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
- AnimalMuppet 11y ago
  Slower to compile, but starting from a much faster starting point.
- dekhn 11y ago
  I'm not even aware of go compiling most of the time (it's typically under 1 second). go's build system handles these sort of things without a more complex workflow.
  - masklinn 11y ago
    > I'm not even aware of go compiling most of the time (it's typically under 1 second). That's besides the point, codegen from extra on-disk files can only be slower than codegen without extra on-disk files, so "generics are slow to compile" and "go has generate" don't make sense together, yet they are used together to assert that generics are bad and anyway go has a replacement. > go's build system handles these sort of things without a more complex workflow. No they don't. If you're using go generate you have to run go generate. That's a strictly more complex workflow than not having to run it.
    - dekhn 11y ago
      I didn't say generics were bad. I said compilation is so fast that I didn't notice it. While I agree that "strictly" your assessment is corect it's more complex, I think you're being a bit literal; it's just another command. most of my builds have hundreds of commands.
- yokohummer7 11y ago
  This is exactly the case that the problems of a language are solved by tooling. This attitude can be easily found in the Java ecosystem, where the answer to every question is "to use IDE". Interestingly, Java recently abandoned the idea of feature stagnation and started improving the language. I'm curious when this will happen to Go.

AnimalMuppet 11y ago

> Developer time costs more than compiler time. I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.

lmm 11y ago
> I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the computers get faster and the developers stay the same. > Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects. No, the cost of being unable to abstract increases exponentially as your system grows. If using language X lets you cut 500 lines from a 1000-line Go project, then when you have a 2000-line Go project, in language X you'd be able to cut 500 lines from each half of it considering each half in isolation - and then you'd be able to cut some more because of things that were common between the two halves - so you'd end up with just 750 lines of language X. And you pay the cost of extra lines every time you read or debug, year after year.
- tracker1 11y ago
  It depends on the use case... C# is a wonderful language, since the addition of generics and lambdas, it's downright beautiful to work with. But this does come with a cost... Even a simple hello world console app has a pretty significant spin up time compared to go, or anything that is truly compiled. In some cases, if you have long-lived services, then Java and .Net make sense... You can get farther with the code in place. If you are running one-off executable handlers, that need to start and finish quickly, then you probably would favor go. It's entirely possible for different options to be part of a larger solution.. and while I agree, the lack of generics is truly painful... I remember C# before, and feel that Java's generics are a horrible implementation... I'd rather wait for a nice implementation just the same.

staticint 11y ago

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly. The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with number types, for example. You leave the burden on the programmer to ensure their generalized function is applied only to types which it is intended to be used with. While that is less than ideal, I cannot see that increasing developer time by a significant margin.

15155 11y ago
> It is not like someone is going to manually write out identical functions twenty times for each type they want to support. I'll stop you right there. Have you seen a modern Go codebase? They most certainly duplicate the simplest of functions, resort to `go generate`, or use reflection.
- staticint 11y ago
  I am afraid I am not entirely sure of what you are trying to get across here. Your mere mention of go generate indicates to me that you do understand my point about computers being able to free the programmer from doing the drudgery of implementing the same generalized function twenty times. And since you are familiar with go generate, I expect you also realize there are seemingly endless tools that exist to solve this specific problem. I _think_ what you are trying to say is that templates in Go are less convenient than in some other languages. That is a completely fair assertion. But the idea of having to type `go generate` occasionally adding significant man hours to a project seems a little far fetched. You could even: alias go='go generate && go' I completely understand the appeal of templates/generics being a first-class language feature. Not even the Go authors themselves discount the usefulness. I don't understand why the lack of them is adding so many more man-hours to your projects? The overhead of working around the lack of them should not be that significant, even if less pleasant.

geon 11y ago

Slow compilers waste developer time.

15155 11y ago
Incremental compiles have existed for quite some time. Go is only unique in that it can do a complete recompile in very attractive times. The only hitch, of course, is that you sacrifice features known and loved in other languages for over a decade.