There are two Graphite companies. The time series DB for metrics (not this) and the stacked diff code review platform (this). Looking at other comments under the post, they seem to have executed a hard AI pivot recently.
4o on ChatGPT.com vs. Opus in an IDE is like cooking food without kitchen tools vs. using them. 4o is neither a coding-optimized model nor a reasoning model in general.
I did work for a Russian financial multinational just before COVID-19, as a native Russian speaker, and it was a free-for-all mess interally. The IT side had a load-bearing, old-school sysadmin type with a personality for heroics.
They have an old-school enterprise sales operation that is doing superb work. Apart from that, ChatGPT's projects are useless crap (can't read other convos in a project; can't generate project documents from a convo), and so clearly they would get value out of just getting some developers who have built anything of use to a poweruser.
Having experience with digitizing a university textbook in physics by hand, this is a very nice LaTeX guide for everyone interested. One thing worth noting from 2025 perspective that the "default" local setup is most likely going to be VSCode with LaTeX Workshop[1] and LTeX+[2] extensions, and that you should use TeX Live on every platform supported by it (since MiKTeX and friends can lag). Also, use LuaTeX, as it's the officially recommended[3] engine since November 2024.
That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.
Pyright has semantic improvements (and also some differences) over MyPy. As for using the type checker as a language server, it's difficult to go back to “it's compiling” after you've had one stop you from typing bugs out in-flight.
To round out the big 4, there's also Pyre from Meta. I haven't used it myself, as when I last checked it had a low number of PEPs covered, but I've heard some good words for it.
> Pyright was designed with performance in mind. It is not unusual for pyright to be 3x to 5x faster than mypy when type checking large code bases. Some of its design decisions were motivated by this goal.
> Pyright was also designed to be used as the foundation for a Python language server. Language servers provide interactive programming features such as completion suggestions, function signature help, type information on hover, semantic-aware search, semantic-aware renaming, semantic token coloring, refactoring tools, etc. For a good user experience, these features require highly responsive type evaluation performance during interactive code modification. They also require type evaluation to work on code that is incomplete and contains syntax errors.
> To achieve these design goals, pyright is implemented as a “lazy” or “just-in-time” type evaluator. Rather than analyzing all code in a module from top to bottom, it is able to evaluate the type of an arbitrary identifier anywhere within a module. If the type of that identifier depends on the types of other expressions or symbols, pyright recursively evaluates those in turn until it has enough information to determine the type of the target identifier. By comparison, mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge.
> Pyright implements its own parser, which recovers gracefully from syntax errors and continues parsing the remainder of the source file. By comparison, mypy uses the parser built in to the Python interpreter, and it does not support recovery after a syntax error. This also means that when you run mypy on an older version of Python, it cannot support newer language features that require grammar changes.
Astral's type checker seems to an exercise in speeding up Pyright's approach to designing a type checker, and removing the Node dependency from it.