[Ericson2314]

The point is, as usual, Go is trying to catch up to what everyone else has had for years. The use of non-standard terminology here is suspicious, raising the question that the Go people are trying to hide the fact that they are playing catch-up.

[enneff]

Comments like these are so depressing. Someone does a bunch of work to improve the Go compiler and writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it), and gives it all away for free. This is textbook open source citizenry, which should be applauded.

But instead, you come along and criticize them for being too specific with their terms (!!) and also accuse them of being deceptive. This is not a marketing exercise. There is no conspiracy here.

[vorg]

> writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it

Perhaps Ericson2314's gripe is that it's being posted (and upvoted) on HN, rather than just a Go-specific forum (e.g. reddit.com/r/golang), and by implication it's intended to be read by a more general audience.

[enneff]

Well that's just silly. People post random stuff to HN all the time. That something is appears here does not mean that HN is the intended audience.

[solidsnack9000]

Nothing about giving your work away for free or wanting to do good necessarily puts one above criticism for misuse (or useless invention) of terminology. It's not a marketing exercise, you are correct -- all the more reason to expect a narrow use of terminology.

[weberc2]

If you're going to be pedantic, you might at least be strictly correct. There is no existing term that would distinguish it from Go's prior state, so there is no misuse nor "useless invention". Even if there were and you were correct, this would still be pedantry at its finest.

[solidsnack9000]

> ...would still be pedantry at its finest.

Why would correct use of terminology be "pedantry at its finest"?

What people are concerned about is intellectual dishonesty. The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go. Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter?

[weberc2]

> Why would correct use of terminology be "pedantry at its finest"?

Because you're debating terminology when the wrong term caused no one confusion, thereby detracting from the actual conversation.

> What people are concerned about is intellectual dishonesty.

There's no cause for this concern.

> The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go.

Sure it does; see slides 3-6.

> Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter?

Perhaps the author omitted it from his deck because it's impractical to cover the whole breadth of inlining in a deck that's already 35 slides long. Perhaps he simply didn't think to include it. There are a lot of likely explanations for why this wasn't included besides nefarious motives. You sound paranoid.

[solidsnack9000]

> There's no cause for this concern.

Well, why do you think we are bringing it up, then? Due to some nefarious motive?

[infogulch]

No hiding or sneaking is necessary to explain anything here. They needed to come up with a way to describe the difference between how it is currently implemented and how they are changing it. That's all.

[jgalt212]

> The point is, as usual, Go is trying to catch up to what everyone else has had for years.

As far as programming languages go, Go is very new. Of course, there will be a number of areas that still need to be optimized or fully fleshed out. I think the Go compiler has only been written in Go for about a year. I'm sure you you find this pretty lame as well.

[weberc2]

I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?

[pcwalton]

> What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?

There isn't a standard term, because virtually all inliners always did what Go is now doing. It's pretty basic functionality.

[dilap]

Really? I feel like every C++ compiler I've used has given very unreliable stacktraces with optimizations enabled.

[jstarks]

Do most compilers preserve enough metadata to report accurate stacks?

[weberc2]

So they're not avoiding a standard term to be misleading; there simply isn't a standard term to use. Thank you for clarifying.

[Rusky]

The point is "inlining" already refers to this kind of inlining. The already-present form is more limited than the typical use of the term.

[sythe2o0]

Then what word would you have used in this presentation, given no established word existed?

[peteretep]

"Fixing Go's inlining"

[solidsnack9000]

"Go inlining improvements..." and then "Conventionally, inlining includes ... but Go has been limited to ... until recently. With ... Go now supports inlining in a broader array of circumstances."

[overcyn]

"Conventionally inclining includes ...?"

What does it include? You've conveniently managed to skip over the crucial part with ellipses. Calls in the middle of stacks perhaps?

You people have too much time on your hands to go and pick at the wording people use in their presentations.

[solidsnack9000]

> You people have too much time on your hands to go and pick at the wording people use in their presentations.

What kind of argument is that?

[blackrose]

Shitting on Go for sport: a HN pastime.