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

And there is apparently already a discussion thread for it: https://news.ycombinator.com/item?id=40843778

Comments URL: https://news.ycombinator.com/item?id=40845540

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=40818564

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=40515882

Points: 2

# Comments: 2

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.

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

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.

Comments URL: https://news.ycombinator.com/item?id=39219833

Points: 15

# Comments: 11

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.

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

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.

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

Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway

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.

Place button A the user wants to interact with at position (X,Y), place iframe button B at position (X+W,Y), with as little a border as possible with the rest of the page, then offset fake cursor by -W. User will try to mouse over button A, mistakenly mouse over button B, and click it in the time it takes to register that the mouse pointer just jumped from the edge of one button to the edge of the other...

[1] Though I can see the trick below maybe working for some browser's permission request "tooltip" UIs...

This squares ok with geopolitical reasons, but not economic ones (although they certainly influence that map now and in the future).