undefined | Better HN

0 pointssmcl2y ago0 comments

Ah thanks! That's interesting but a bit weird to me. That response sounds a little bit like someone who feels like they shouldn't do something and is thinking on-the-fly for reasons they can use to justify that feeling.

> We don't want to complicate the language

So I can understand if this complicates the implementation but I don't know if totally optional pragmas or annotations complicates the language itself. Like C has this but I don't think people say "Ah C is alright but the pragmas are a bit confusing and make things complicated".

> experience shows that programmers are often mistaken as to whether branches are likely or not

Your average programmer may mess that up, but those who would give optimisation hints aren't quite your average programmer. And insisting on introducing PGO to your build process (so build, run-with-profile, rebuild-with-profile) for some cases where someone isn't mistaken as to whether branches are likely (or whether some loops run minimum X times, etc) feels a bit needless.

Please remember though that I'm neither a Go programmer nor contributor so I'm really just an outsider looking in, it could be that this is a total non-issue or is really low-priority.

0 comments

anentropic2y ago

Not giving you nice things because "Your average programmer may mess that up" is the whole philosophy of Go though

smclOP2y ago

Yeah I know they don't tend to want to just hand you over low-level access, like an `asm(...)` statement in C (or maybe like instrinsics). But pragmas tend to be a bit less explicitly "mess it up". Like in the case we're talking about, a loop performs slightly worse by default and it might be nice to nudge the compiler into the right direction. Just as go isn't "messing [it] up" by selecting a slightly suboptimal instruction here, you're not "messing [it] up" if you annotate a loop slightly incorrectly.

j / k navigate · click thread line to collapse