Hacker News new | past | comments | ask | show | jobs | submit

//go:fix inline and the source-level inliner

https://go.dev/blog/inliner
loading story #47399922
If I follow, this isn't a compile time inline directive, it's a `go fix` time source transformation of client code calling the annotated function.

Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:

> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.

It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.

loading story #47392449
loading story #47393771
I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge.

https://wiki.c2.com/?HotComments

loading story #47392393
loading story #47395574
loading story #47393293
The //go:xyz comments are an established pattern in the Go tooling.
This is begging the question. Yes, but why did they do that over dedicated syntax?

(My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

loading story #47394622
//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.
It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.
I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.
loading story #47394784
loading story #47395296
loading story #47396236
Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
loading story #47395617
loading story #47395184
Good illustration that a seemingly simple feature could require a ton of functionality under the hood. Would be nice to have this in Python.
loading story #47396612
It looks the following code will be rewritten badly, but no ways to avoid it? If this is true, maybe the blog article should mention this.

    package main
    
    //go:fix inline
    func handle() {
        recover()
    }
    
    func foo() {
        handle()
    }
    
    func main() {
        defer foo()
        panic("bye")
    }
loading story #47392963
loading story #47392125
Or: your buggy code is no longer buggy.
loading story #47392387
loading story #47392470
loading story #47398356
loading story #47397465