I wonder if there was a point in the history of Instagram's codebase at which it would've been cost-effective to rewrite it in a statically typed language.
If you find yourself in a hole, stop digging.
Static Analysis at Scale: An Instagram Story
31–36 of 36 posts
Re: Static Analysis at Scale: An Instagram Story
#32I wonder if there was a point in the history of Instagram's codebase at which it would've been cost-effective to rewrite it in a statically typed language. If you find yourself in a hole, stop digging.
how would static typing help with "method fn is deprecated use foo' linting ?
Re: Static Analysis at Scale: An Instagram Story
#33> we have hundreds of engineers shipping hundreds of commits every day Can someone with (any) experience explain to me why do seemingly perfectly functional websites need change all the time? Is the production version hacked together or what? Why can't websites be coded once and left to run with the rest of the effort being devoted to maintance/adding more servers as the load increases? I admit that I know almost not…
I think a big part is just technical debt acquired through the years, when you are just starting you hack some version of the site that works because you need to grow fast, but that's not scalable, so a part of becoming a big company is to "refactor" or "re-architect" your app to either more modern designs or in some cases into a completely different app (On the inside)
Re: Static Analysis at Scale: An Instagram Story
#34I wonder if there was a point in the history of Instagram's codebase at which it would've been cost-effective to rewrite it in a statically typed language. If you find yourself in a hole, stop digging.
how would static typing help with "method fn is deprecated use foo' linting ?
Quoting the article:
"The benefits of better typed code are obvious, but leads to yet another benefit: Having a fully-typed codebase unlocks even more advanced codemods."
Re: Static Analysis at Scale: An Instagram Story
#35Earlier quoted context omitted.
The coverity paper may be interesting to you: http://delivery.acm.org/10.1145/1650000/1646374/p66-bessey.p...
The link doesn’t work, I’m interested to read it though.
Whoops! Should've noticed that was an ephemeral link, but yes, mdibiase@ linked the one I meant to. It's Coverity's "A Few Billion Lines of Code Later" ACM paper.
Re: Static Analysis at Scale: An Instagram Story
#36A third static analyzer for Python! I wonder what this landscape is going to look like in a few years... (There are probably others, but this is the first I'd heard of Pyre, and I'd only known about mypy and pytype up until today - if there are others I'd love to hear about them!) On a more substantive note, static analysis is one of those things that sounds like you shouldn't even need it but in reality is a surpris…
if there are others I'd love to hear about them!
I've been collaborating with Duo Security to build a new Python static analysis tool that focuses on security deficiencies: https://github.com/duo-labs/dlint
In general, I agree, static analysis is a very powerful technique. I'd like the computer to double-check my work as thoroughly as possible when I'm working with code. Static analysis tools are often very fast and essentially "free" to run, so why not? False positives often become the limiting factor, but in my experience they at least point to locations in code that someone has deemed noteworthy, and perhaps should be investigated. Squelching false positives is also typically an easy process.
Whether it's simple stylistic recommendations for code consistency, security best practices, or even disseminating codebase information (e.g. function deprecation notices from the Instagram article), static analysis is a very useful technique.