lazaroclapp

Interestingly, there are basically two kinds of programs I am sometimes happy to see guided tours embedded in:

* Creation programs (image/video editors, 3D rendering... hell, even a slides program or an IDE). Doesn't mean I won't dismiss them sometimes anyways, but these are tools that often I do want to get an initial idea how to use, that I have allotted some time to play around with, and that are sufficiently complex that a tutorial is justified. These are also places were I can spend 2-5 minutes learning the basics of the tool, because whatever I am about to do with it is going to take the next few hours anyways.

* Videogames (i.e. the tutorial). For very similar reasons to the above ;)

Also, this is always on first install. Getting a tutorial on update for an authoring tool (and to a lesser extent a game) is far less likely to be welcome.

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.

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!)

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 :)

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.

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.

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).

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.