On Fri, Jul 1, 2016 at 10:23 PM, Andrew Mezoni <andrew.mez...@gmail.com>
wrote:
> Can I ask the question out of turn?
> Ok. I ask.
> What wrong in Java way?
> What wrong in C# way?
>
Nothing inherently. It just takes a performance penalty and it needs to be
justified that this performance penalty is worth it. That is the only thing
I am saying. The post by Russ doesn't say that any tradeoff is *wrong*. It
just says that a tradeoff must be made, explicitly and that there, so far,
seem to be no inherently correct way to make it. Unless you figure out a
way around the trilemma, you *must* justify why your choice of the three is
the correct one.
> Of course, they have a boxing/unboxing concepts.
>
Does this means that boxing/unboxing is very, very, very slow operations
> and should not be used even in Java or in C#?
> But they used. They used at least in generics programming in the languages.
>
Yes. And go has as one explicit design goal not to do them ("control over
memory layout"). This can be revised, of course, but you need to justify
why that cost is worth it.
> Does this means that generics programming in these languages are very,
> very, very slow?
>
No, just slower than in other languages (like C++ or rust) and that it is
not clear that this performance hit is obviously worth it.
> Does this means that generics programming in other languages are very,
> very, very fast?
>
Also no, generics programming is somewhat slow most of the time. But
faster, yes.
> Generics programming are always compromise between the performance and
> universality.
>
Where universality always means an usability.
>
*Exactly*. That is *precisely my point*. There is a tradeoff to be made but
that tradeoff *needs to be justified*. You need to make an argument for
which of the three you choose; slow programmers, slow compilers or slow
programs. Currently go chooses the former, because it was deemed good
enough like it is and the productivity hit of slow compilers wasn't deemed
acceptable (and when you see all the outrage about compile speeds since
1.4, the community seems to agree) and the hit on performance was deemed to
high a cost. It is possible to change that choice, but the change needs
justification and a simple "I don't like slow programmers" isn't a
particularly good argument.
> C++ way is out of the scope.
>
Why do you think that? You seem to both "slow compilers" and "slow
programmers" (otherwise we wouldn't have this argument) to be out of the
question. But where does that judgement come from? How do you justify this
particular choice in the Trilemma?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
