4 ms·

> I don't think these are the only outcomes, but lets go with it. A slightly slower compiler then. Solved. Except that a capital-F Fast compiler is a design go

by pdpi 12y ago

> I don't think these are the only outcomes, but lets go with it. A slightly slower compiler then. Solved. Except that a capital-F Fast compiler is a design goal for the language, so that's the _least_ desirable of the three. I feel tempted to go with slower execution times, simply because it's already a part of the design as well: you can't optimise too aggressively on a limited compilation time budget.

mhd 12y ago
Who says that "slower" doesn't still remain within the realm of "fast", perhaps even with a capital F? I wouldn't assume that the language as is is totally devoid of features that already complicate compilation -- that would probably result in some kind of polish notation proto pascal… So it's all about tradeoffs, and the go designers just say that this isn't worth it, at least for the current time and the current Plan9-ish Thompson compiler. Whether this crosses over from the pragmatic to the dogmatic is up for discussion (cf. dynamic linking).
ascotan 12y ago
Generics are a nice feature to avoid code duplication. However, they are not required to be used in every application. Whatever the solution is, it should not affect code that doesn't require the use of generics. If the entire language is affected (such as a slower runtime because of the need to box/unbox) that would be a step down.
- frowaway001 12y ago
  So how are you writing Go if you neither use arrays/slices, maps, channels, etc.?
scott_s 12y ago
That the compiler will be slower can be used as an argument against any new language feature. Slightly slower would, I think, still mesh with their design goals. But slower, and the amount of slowdown is a function of the number generics used in a module, or in a total application, might not mesh with their goal. Basically, I'm saying that if we're going to talk about compiler performance - and we should, since as you point out, it is a design goal of Go - we need to be a bit more concrete. Based on everything I know about Go's goals, they would be particularly worried about solutions that don't scale.
threeseed 12y ago
And if the additional compilation time is not perceptible ? Seems like a pretty stupid approach to ignore any language additions if they have any potential to impact the design goals. Implement it. Benchmark it. Then decide if it should be landed into mainline builds.
coldtea 12y ago
>Except that a capital-F Fast compiler is a design goal for the language, so that's the _least_ desirable of the three. Except the compiler is nothing to write home about in the "fast" department (others, including D are just as fast), and modular compiling and a good design of linking etc can solve the compile speed issue far better, and without sacrificing more important things... Besides, this only means they don't understand diminishing returns and opportunity cost.

by pdpi 12y ago

mhd 12y ago

Who says that "slower" doesn't still remain within the realm of "fast", perhaps even with a capital F? I wouldn't assume that the language as is is totally devoid of features that already complicate compilation -- that would probably result in some kind of polish notation proto pascal… So it's all about tradeoffs, and the go designers just say that this isn't worth it, at least for the current time and the current Plan9-ish Thompson compiler. Whether this crosses over from the pragmatic to the dogmatic is up for discussion (cf. dynamic linking).

ascotan 12y ago

Generics are a nice feature to avoid code duplication. However, they are not required to be used in every application. Whatever the solution is, it should not affect code that doesn't require the use of generics. If the entire language is affected (such as a slower runtime because of the need to box/unbox) that would be a step down.

frowaway001 12y ago
So how are you writing Go if you neither use arrays/slices, maps, channels, etc.?

scott_s 12y ago

That the compiler will be slower can be used as an argument against any new language feature. Slightly slower would, I think, still mesh with their design goals. But slower, and the amount of slowdown is a function of the number generics used in a module, or in a total application, might not mesh with their goal. Basically, I'm saying that if we're going to talk about compiler performance - and we should, since as you point out, it is a design goal of Go - we need to be a bit more concrete. Based on everything I know about Go's goals, they would be particularly worried about solutions that don't scale.

threeseed 12y ago

And if the additional compilation time is not perceptible ? Seems like a pretty stupid approach to ignore any language additions if they have any potential to impact the design goals. Implement it. Benchmark it. Then decide if it should be landed into mainline builds.

coldtea 12y ago

>Except that a capital-F Fast compiler is a design goal for the language, so that's the _least_ desirable of the three. Except the compiler is nothing to write home about in the "fast" department (others, including D are just as fast), and modular compiling and a good design of linking etc can solve the compile speed issue far better, and without sacrificing more important things... Besides, this only means they don't understand diminishing returns and opportunity cost.