Hacker News Reader

Comment by Locke1689 | Hacker News Reader

I think there are two schools of thought:

1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time.

2) Perf improvements should be "locked in" and not regressed, unless strenuously justified.

I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against other compilers" but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification.

I think both groups have valid points. I think (2) is especially good at preventing "perf creep" wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone's just slow, but they have no impetus to improve because they're still better than the competition.

View on HN

Group (3), of which I am a member:

If the developers take a specific principled stance against $really_useful_feature on account that it would introduce complexity and thus degrade performance, then compromise this same principle in order to accomplish $entirely_unnecessary_port, it put the obvious lie to their avowed principles.

I don't mind that go compiles more slowly. To Thomas's point, it's still really fast. What I mind is that a good portion of the go community has accepted the lack of generics on the basis of principles that they haphazardly violated in order to scratch the useless but fun intellectual itch of bootstrapping the compiler.

Now that they've done this, they have revealed themselves to be entirely dishonest about their complexity/performance principles, and now the one legitimate objection that has kept generics out of the language has nothing to stand on.

Again, I don't care about performance per se, I care about dishonesty and hypocrisy in the platform's objectives.

"Entirely dishonest". "Dishonesty and hypocrisy". In a discussion about compiler performance. Do you understand that framing things like this makes it seem like discussing things with you is intractable?

Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Why not consult the go faq to find their reasoning for omitting generics?

> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

The word performance doesn't appear in that paragraph.

Deleted comment

You're right, that was really stupid of me. I'll delete it.

Complexity in the type system can easily have a negative effect on compiler performance.

Is it possible that writing the compiler in go makes it easier to add efficient implementations of these missing features?

Reply on news.ycombinator.com