Not sure if there is an official announcement to link here vs the toot, either way a very well deserved award and a success story for fundamental PL research influencing industry practice and vice versa.
The easy answer when bringing up something like IntelliJ is that we very much intend to go beyond the IDE (local edit-build-debug loop) and beyond an specific programming language (or set of related languages in the case of IntelliJ). But it is generally true that we aren't the first or only company to think about multiple parts of the development workflow. You could point to, say, Jetbrains Space as a better example of something from them in the same space (pun not intended).
We want to build an integrated development platform that goes from locally writing code, to code review, to continuous monitoring of code quality, to enabling automated dependency upgrades and migrations, to compiler optimizations guided by usage data and constraints. That doesn't mean that every tool in the platform will be something we build from scratch, though, we are looking to integrate with existing developer tools along a number of supported "golden paths", besides making our tooling available a la carte for others.
For linting, specifically. It's easy to add linting frameworks and checks, for most languages, but there are a few things we need to be considered when a diagnostic is surfaced locally:
- Is it a suggestion or an actual error?
- Is there an automated fix available?
- Is the right set of checks turned on for the right subset of the code?
Then there is also the aspect of visibility and observability. Here is an example of an issue for which a lint was readily available, but ignored: https://imgur.com/a/wWqa0Wg. We believe that's common and not a matter of human error, but a direct consequence of the tooling not surfacing the issue in the right ways or providing an easy path to fix it once the code is already in the codebase.
Or, consider code refactoring. Many IDEs support code refactoring with full AST information, but for large codebases it can hit limits fairly easily: for a large monorepo, it might not scale in the sense of being able to keep all code indexed in memory within the same session; for a set of microrepos, it can struggle to perform refactorings across repo boundaries. One approach here is to build a powerful refactoring engine and expose it via integrations to the IDE (including IntelliJ!), code review system, and some sort of global management UI.
For each of the questions above you can find potential solutions, both from companies and in open-source, and yet, companies that can afford it benefit from having a "dev platform" team integrating, customizing, and maintaining various such tools benefit from that investment. I'd argue there isn't currently a clear go to answer for "Developer Platform as a service", particularly one that doesn't care to tie you to a particular language or stack.
A cliche, perhaps, but build times and land times have always been a top priority of developers, particularly as tooling, specially code analysis, grows more complex. Developer tooling should be as blazingly fast as we can make it! (And obviously we aren't the only ones aiming for that, but it's good to have it as an explicit top priority!)
Hi, everyone! We are some of the authors behind Uber’s OSS developer tools, which have appeared in HN previously, including: Piranha (automated stale flag cleanup and code refactoring), NullAway/NilAway (NPE/nil panic static detection), OkBuck, etc.
While we think all those tools are great (they are not going away and there are hopefully more to come both from us and from the team remaining at Uber!), we believe that the main thing a developer platform team brings to a company is an integrated experience. We started Gitar to provide that same experience across multiple companies, including those which do not (yet) have a large developer platform team!
We have plenty of ideas (starting with some interesting tooling around code refactoring!), but also happy to hear about the challenges you all see at various scale companies related to developer experience and tooling.
Well, an IDE is not fundamentally out of scope, but for the foreseeable future the plan there is more along the lines of plugins for common IDEs (e.g. VSCode, Jetbrains) and integrations with existing code review and code hosting services (GitHub, GitLab, etc.).
We want to integrate with a few reasonable permutations of a development environment and overlay stuff like dead code deletion and refactoring (Already got a tool for that! More to come soon, but that's not the full business for us, just the first feature), static analysis (see NullAway/NilAway for examples that go beyond basic linting), tools for managing compatibility between dependencies and fixing flaky tests, and LLM-based code transformation and code review tools. At some point or another we have talked about how we'd rebuild each and every step of the development process (up to including version control), but for now there are easier and more urgent problems we think we can solve than that or building a new IDE :)
We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues
We definitely have gotten some useful reports there already since the blog post!
We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).
Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contracts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.
In one case, it couldn’t tell that a slice couldn’t go out of bounds because I was iterating through it backwards instead of forwards. In another case, I had a helper method on a type to deal with initializing a named map type, but it couldn’t see that and thought the map was going to explode from being nil. Those are two false positives I remember off the top of my head. I can look it up again later.
Actually, if we were running into cases where we aren't logging a panic which is actually happening in production, then the first thing to note is that we need to improve our observability. The issue might or might not be recoverable, but it should be logged. If nothing else, it should show up as a service crash somewhere within those logs, which is also something that service owners monitor and get alerts on.
The advantage of NilAway is not just detecting nil panic crashes after the fact (as you note, we should always be able to detect those eventually, once they happen!), but detecting them early enough that they don't make it to users. If the tool had been online when that panic was first introduced, it would have been fixed before ever showing up in the logs (Presumably, at least! The tool is not currently blocking, and developers can mistake a real warning for a false positive, which also exist due to a number of reasons both fundamental and just related to features still being added)
But, on the big picture, this is the same general argument as: "Why do you want a statically typed language if a dynamically typed one will also inform you of the mismatch at runtime and crash?" "Well, because you want to know about the issue before it crashes."
Beyond not making it all the way to prod, there is also a big benefit of detecting issues early on the development lifecycle, simply in terms of the effort required to address them: 'while typing the code' beats 'while compiling and testing locally' beats 'at code review time' beats 'during the deployment flow or in staging' beats 'after the fact, from logs/alerts in production', which itself beats 'after the fact, from user complains after a major outage'. NilAway currently works on the code review stage for most internal users, but it is also fast enough to run during local builds (currently that requires all pre-existing warnings in the code to either be resolved or marked for suppression, though, which is why this mode is less common).
That makes sense. I hope my first comment came across as I intended, which wasn't as criticism of the product but a suggestion about how to talk about the value of the product.
No worries, that's how I understood it too :) Just adding a bit more context on why we feel the approach does beat "grep panic" for people checking out this thread.
Native Spanish speaker here (ES-MX, specifically, if it matters). I think this is one of the cases where a solid general rule breaks down in the specifics.
You are correct about the difference between "ser" (to be, permanently/over an indeterminate time) and "estar" (to be in a particular state right now). But "No soy feliz" sounds perfectly idiomatic to me, even for a relatively transient state of sadness. ("No estoy feliz" doesn't sound wrong to me either, but feels just slightly less natural than "No soy feliz" even in a context like "No soy feliz ahorita", with an explicit "right now").
As a note: "No estoy contento" (Also "I am not happy", or maybe "I am not in a good mood") is definitely "estoy", rather than "soy". No clue why "No soy feliz" does feel idiomatic.
> Isn't this pretty much the description of every company?
For the most part, sure. But that's the parent's point, I think. Central banks are not companies, they are part of the public financial infrastructure of a nation (or, in the EU case, group of nations).
Actually... it's complicated. The Bank of England, for example, was nationalized only in 1946, and it remains technically a company which is owned by the state, not actually part of the government.
In the US, the Fed is... well, it's not a company, but it's also not not a company... or group of companies...
Yeah, the Bank of England even used to offer account services to employees after it was nationalized. Which would be scandalous if we found it in some dubious ex-Soviet republic today, albeit there maybe they're lending the Bank's President $10M with no real security and the Bank of England was offering employees mortgages and similar modest run-of-the-mill secured loans.
The UK owns a whole bunch of banks and entities that would need a banking license if they weren't owned by the government, of which only the Bank of England acts as a central bank, but there are also a bunch of commercial banks in (or at least operating in) the UK that are named after parts of the UK even though they're not owned by the government, including the Bank of Scotland.
To be fair, unlike Tether, the Bank of Scotland actually does hold actual cash worth the same as the notes they issue.
Also, although these banks have permission to issue notes (whereas if you went around issuing "bank notes" you'd likely get arrested) the notes aren't necessarily worth anything except in the sense that you can assume the Banks will give you Bank of England notes for them if it came to it since they're required to hold those.
They aren't legal tender (Scotland doesn't really bother having legal tender laws anyway) and retailers can choose not to accept them if they want. You won't have a problem exchanging them for tourist stuff in Edinburgh or buying a fish supper in Dundee, but good luck getting some random corner store owner down South in Cornwall or Essex to accept them - even though these notes are in some sense worth the same as Bank of England notes, there is no law requiring retailers to accept any notes and so they might just tell you to fuck off with your weird-looking money.
The decision-making body of the Federal Reserve System – the thing that sets monetary policy, among other things – is a government agency (the Board of Governors of the Federal Reserve.)
The rest of the system is, as you note, complicated, but the rest of the system doesn’t set monetary policy.
While admittedly not as nice as having it built into the type system from day one, there are a number of tools one can integrate into their build to add various degrees of null safety to Java.
It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code.
Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.
And there is apparently already a discussion thread for it: https://news.ycombinator.com/item?id=40843778