Gitar: From the Team Behind Uber's Developer Platform
gitar.coHi, 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.
Congrats on founding a company here!
But what is it? An IDE?
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 :)
Perfect, thank you
I really enjoy much of Ubers tooling.
TFA seems to explain the problems they are trying to solve but not the solutions. Currently these problems seem well solved by the intellij line of products with [insert favorite linter here].
Maybe I'm missing something
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.
No, thanks. Uber is notorious for subpar low quality OSS
Huh. Do you have a few examples?
I thought jaeger was pretty popular for tracing.
> “everything should be blazing fast”
Ay there it is! It’s blazingly fast!
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!)