> 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.
> If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast.
Buying a fast machine only gets you so far. Large C++ projects take minutes to compile even on the fastest machines available. Plus, you'd need to buy one for every developer.
> 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.
While this is true in theory, in practice I think the effect is not quite as large. As the project grows, developers take ownership of certain parts of the code and become ignorant of other parts. This is the whole point of abstraction. Under these conditions it will take a heavy investment of time and effort to find and replace the things in common between the two halves. So you might cut 250 lines in common between two 1000-line halves, but you're not going to cut 25,000 lines in common between two 100,000-line halves without a serious amount of work.
I think Go's design shows awareness of this effect. The Go literature does not preach the battle against code duplication as strongly as, say, Java. The goal is to make it easy to understand the other team's 100,000 lines, even if that comes at the expense of some code duplication.
Note: I am not a Go programmer, but I do think that optimizing for ``code entropy'' (lack of duplicated code) over all else is a mistake.
> Under these conditions it will take a heavy investment of time and effort to find and replace the things in common between the two halves.
Maybe. I find the same patterns tend to show up in a lot of code, so very high-level libraries like scalaz or recursion-schemes (that you can't even think without a powerful type system) turn out to save code virtually everywhere.
> Note: I am not a Go programmer, but I do think that optimizing for ``code entropy'' (lack of duplicated code) over all else is a mistake.
Intuitively it does seem like other things should be more important, but I've become more attached to that measure through experience. Even seemingly innocuous duplication tends to go wrong over time.
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.
I cannot find any reason to believe that lambdas have anything, at all, to do with sin-up time. A hello world console app wouldn't even be using them much (closures are just objects so...).
And I doubt generics make a significant difference in runtime but I don't have a CLR v1.1 around to test it out. For comparison, a C# hello world takes about 10ms longer than a C one (both compiled with optimizations; .NET 4.6 C# 6 / MSVC 19) on my i5 Broadwell laptop. Timing as measured by "time" in bash (~25ms vs ~35ms).
I'm guessing you're talking about JIT in general and of course have a point there. I doubt it's significant for any significant values of significant.
I wasn't saying lambdas are a reason that it's slower.. only that it was a feature that made it really nice to work with.
I remember the difference being a bit more than that, on the order of half a second in difference.. but that was around the .Net 1.0 timeframe.. I still used it for a lot of things because it didn't matter to me.. but a couple of things I wanted to use it for at the time was too much lag for starting an EXE and getting output from the command prompt.. running as a service was a different story.
A 1.2Ghz early Athlon was a lot slower than what we have today as well... even so, depending on what you need, even 10ms can make a difference.
I don't think it has to be a tradeoff though. Look at OCaml or possibly D - decent type system, fast compilation and fast runtime performance. And I'd expect Rust to do even better.
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.