3 ms·

I like Go, and it’s nice to see more safety being added, but it definitely feels bolted on in a less than ideal way. Soon enough we’ll have a similar tool that

I like Go, and it’s nice to see more safety being added, but it definitely feels bolted on in a less than ideal way. Soon enough we’ll have a similar tool that asserts that nilability is checked on certain fields, whereas we could have just had a language with null safety to begin with. I understand there are trade offs (for example non-nillability is add odds with useful zero defaults in some way), but I wonder what was missed that should have been built into the language and type system directly.

jolux 5y ago
Tools like this are often a sign that the language was under-designed.
- spenczar5 5y ago
  Yes, but it is also nice that Go is simple enough (simplistic enough, if you want) that these tools can be added on top, without requiring deep integration.
  - Groxx 5y ago
    I don't know of any language where building a static analyzer requires "deep integration". The closest I can think of is Java, where you can optionally do something during compilation with e.g. an annotation processor, which has a number of rather significant reliability and performance benefits. But that's an optional feature provided by an absurdly mature set of tools, definitely not a requirement - there are tons of java analysis tools that don't plug into javac. If anything, this one serves as a bad example of Go's simplicity being a benefit. It's using the SSA analysis pass to do much of what a compiler does, because the compiler doesn't give you enough data to do it otherwise. It's an extremely complex workaround with only one implementation which is also built by the language developers, though it does plug into a decent framework (x/tools/go/analysis).
    - amscanne 5y ago
      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.
- uluyol 5y ago
  C++ [1], Java [2], Python [3], and even Rust [4] all have static analyzers. There will always be room for analysis that is beyond the compiler's purview. [1] https://clang.llvm.org/extra/clang-tidy/checks/list.html https://clang.llvm.org/extra/clang-tidy/checks/list.html [2] https://spotbugs.github.io/ https://spotbugs.github.io/ [3] http://mypy-lang.org/ http://mypy-lang.org/ [4] https://github.com/rust-lang/rust-clippy https://github.com/rust-lang/rust-clippy
rtpg 5y ago
I think the reasonable alternative here is Clojure's metadata tagging, which would allow for more "principled" execution. Saying "it all has to be in the typesystem" can _also_ become a cludge (see languages that have built-in null handling vs languages that just require you to use Option and the like)
blub 5y ago
This kind of checking has a long history, I've seen it first referenced in the 2006 book Java Concurrency in Practice as class annotations and field and method annotations. Clang had similar annotations for years.

jolux 5y ago

Tools like this are often a sign that the language was under-designed.

spenczar5 5y ago
Yes, but it is also nice that Go is simple enough (simplistic enough, if you want) that these tools can be added on top, without requiring deep integration.
- Groxx 5y ago
  I don't know of any language where building a static analyzer requires "deep integration". The closest I can think of is Java, where you can optionally do something during compilation with e.g. an annotation processor, which has a number of rather significant reliability and performance benefits. But that's an optional feature provided by an absurdly mature set of tools, definitely not a requirement - there are tons of java analysis tools that don't plug into javac. If anything, this one serves as a bad example of Go's simplicity being a benefit. It's using the SSA analysis pass to do much of what a compiler does, because the compiler doesn't give you enough data to do it otherwise. It's an extremely complex workaround with only one implementation which is also built by the language developers, though it does plug into a decent framework (x/tools/go/analysis).
  - amscanne 5y ago
    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.
uluyol 5y ago
C++ [1], Java [2], Python [3], and even Rust [4] all have static analyzers. There will always be room for analysis that is beyond the compiler's purview. [1] https://clang.llvm.org/extra/clang-tidy/checks/list.html https://clang.llvm.org/extra/clang-tidy/checks/list.html [2] https://spotbugs.github.io/ https://spotbugs.github.io/ [3] http://mypy-lang.org/ http://mypy-lang.org/ [4] https://github.com/rust-lang/rust-clippy https://github.com/rust-lang/rust-clippy

rtpg 5y ago

I think the reasonable alternative here is Clojure's metadata tagging, which would allow for more "principled" execution. Saying "it all has to be in the typesystem" can _also_ become a cludge (see languages that have built-in null handling vs languages that just require you to use Option and the like)

blub 5y ago

This kind of checking has a long history, I've seen it first referenced in the 2006 book Java Concurrency in Practice as class annotations and field and method annotations. Clang had similar annotations for years.