3 ms·

There’s a totally valid complaint that the ssa analysis pass and compiler’s ssa representation are different and should be merged (I have the same one, and I’m

There’s a totally valid complaint that the ssa analysis pass and compiler’s ssa representation are different and should be merged (I have the same one, and I’m pretty sure the Go team knows that), but what’s the problem with exposing this to user analyzer tools? The language is simple enough to allow you to write analyzers in the first place. I’m totally fine with people disliking the tool (it’s purpose built for one codebase!), but I sincerely fail to see how it serves as a bad example of Go’s simplicity.

Groxx 5y ago
I like the tool and it's great that it exists - I may try to attach it to a couple projects, small gaps in using mutexes and atomics have been a continual pain in projects handed between teams. The Analysis framework is broadly very successful too, and it's part of why the SSA analysis pass is fairly widely used. It's more that 1) I don't see how it's a positive thing that much of this logic had to be duplicated externally, and 2) it's definitely not a positive thing that the one and only implementation of this (AFAIK) was built by the same organization that builds the compiler. For 2, they're certainly in a good position to do so and I'm glad they did (it's very useful), but there being no third party equivalent seems to me like a fairly strong mark against "simplicity" - outsiders didn't figure out how to do this. If it was simple, they probably would have. And done so multiple times by now. Instead, much of the field seems to be waiting on the core team to provide things. That feels more like Rust to me (which I doubt many would claim is "simple"), except they've built an enormous amount of control into the language itself so many tools don't need to be external.
- amscanne 5y ago
  I think you’re missing context: I wrote most of this tool as part of another open source project (gVisor, which is the repository) and am not on or related to the core Go team. Google is a huge company with tens of thousands of engineers, and for all intents and purposes this is a third-party tool. It is also not duplicating any logic that I’m aware of, beyond the tangentially-related ssa issue? (Which is valid, but I would assume a low-priority problem for the Go team.) The tool is very much tailored to our individual project needs, so TBH I’m not sure how consumable it is. This is why I would surprised to see it here, and being used as the basis for any kind of statement about Go itself. I’m certainly open to making it consumable if there’s interest, but I don’t think it’s what folks are assuming from the title? Hope that clarifies.
  - Groxx 5y ago
    the "internally developed" part was only referring to the SSA pass, yeah. sorry, that was ambiguous. re consumable: in-struct is fine for the vast majority of cases I can think of, but my initial plans on anything like this are always "read, understand, then decide". so I'm plenty happy it's open source, it might give me ideas how to build things like this :) I'd have to dig in a lot deeper to see if it's immediately-applicable or not, but at a glance it sounds "good enough" + helps plug a very real, very dangerous gap. you may get some use if it's spread wider :) though at this point I might just wait for generics. building an ad-hoc guarded-value will be FAR easier then. I suspect the source will help me figure out how to build a couple more specialized tools though, I haven't dug into the SSA pass much yet.

Groxx 5y ago

I like the tool and it's great that it exists - I may try to attach it to a couple projects, small gaps in using mutexes and atomics have been a continual pain in projects handed between teams. The Analysis framework is broadly very successful too, and it's part of why the SSA analysis pass is fairly widely used. It's more that 1) I don't see how it's a positive thing that much of this logic had to be duplicated externally, and 2) it's definitely not a positive thing that the one and only implementation of this (AFAIK) was built by the same organization that builds the compiler. For 2, they're certainly in a good position to do so and I'm glad they did (it's very useful), but there being no third party equivalent seems to me like a fairly strong mark against "simplicity" - outsiders didn't figure out how to do this. If it was simple, they probably would have. And done so multiple times by now. Instead, much of the field seems to be waiting on the core team to provide things. That feels more like Rust to me (which I doubt many would claim is "simple"), except they've built an enormous amount of control into the language itself so many tools don't need to be external.

amscanne 5y ago
I think you’re missing context: I wrote most of this tool as part of another open source project (gVisor, which is the repository) and am not on or related to the core Go team. Google is a huge company with tens of thousands of engineers, and for all intents and purposes this is a third-party tool. It is also not duplicating any logic that I’m aware of, beyond the tangentially-related ssa issue? (Which is valid, but I would assume a low-priority problem for the Go team.) The tool is very much tailored to our individual project needs, so TBH I’m not sure how consumable it is. This is why I would surprised to see it here, and being used as the basis for any kind of statement about Go itself. I’m certainly open to making it consumable if there’s interest, but I don’t think it’s what folks are assuming from the title? Hope that clarifies.
- Groxx 5y ago
  the "internally developed" part was only referring to the SSA pass, yeah. sorry, that was ambiguous. re consumable: in-struct is fine for the vast majority of cases I can think of, but my initial plans on anything like this are always "read, understand, then decide". so I'm plenty happy it's open source, it might give me ideas how to build things like this :) I'd have to dig in a lot deeper to see if it's immediately-applicable or not, but at a glance it sounds "good enough" + helps plug a very real, very dangerous gap. you may get some use if it's spread wider :) though at this point I might just wait for generics. building an ad-hoc guarded-value will be FAR easier then. I suspect the source will help me figure out how to build a couple more specialized tools though, I haven't dug into the SSA pass much yet.