Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.
The conformance test suite is currently mostly focused on “what does an explicit type annotation mean”
A shared spec for this is important because if you write a Python library, you don’t want to have to write a different set of types for each Python type checker
Here are some things the spec has nothing to say about:
Inference
You don’t want to annotate every expression in your program. Type checkers have a lot of leeway here and this makes a huge difference to what it feels like to use a type checker.
For instance, mypy will complain about the following, but pyright will not (because it infers the types of unannotated collections as having Any):
x = []
x.append(1)
x[0] + "oops"
The spec has nothing to say about this.
Diagnostics
The spec has very little to say about what a type checker should do with all the information it has. Should it complain about unreachable code? Should it complain if you did `if foo` instead of `if foo()` because it’s always true? The line between type checker and linter is murky. Decisions here have nothing to do with “what does this annotation mean”, so are mostly out of scope from the spec.
Configuration
This makes a huge difference when adapting huge codebases to different levels of type checking. Also the defaults really matter, which can be tricky when Python type checkers serve so many different audiences.
Other things the spec doesn’t say anything about: error messages quality, editor integration, speed, long tail of UX issues, implementation of new type system features, plugins, type system extensions or special casing
And then of course there are things we would like to spec but haven’t yet!
In case you’re not well versed in Python typecheckers, in the mypy vs Pyright example, Pyright can be configured to complain about not annotating the collection (and so both typecheckers will yell at the code as written).
TypeScript takes the same approach in this scenario, and I assume this helps both be fast.
They were "on the Python Typing Council and helped put together the spec, the conformance test suite, etc" so I assume they are an expert on Python typecheckers
I think the idea is not that there are features that aren’t listed, but rather that if a typechecker supports 10 features people care about and is missing 10 that people don’t really use, it will look a lot worse on a list like this than a typechecker with 100% compliance, when in practice it may not really be worse at all.
Edit: Based on this other comment, the point was also about things not covered by the spec. “The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference.”
https://news.ycombinator.com/item?id=46296360
The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.
Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.
This isn't the primary part of this conversation but I found this quote pretty interesting:
> Now, we are starting to work on Safari again but look at Chrome. They put out releases at least every month while we basically do it once a year.
Even though this was in 2013 nothing about the release cycle (still only major changes with the major OS release versions). I wonder if some of the other emails have more context on this.
I think the truth is the vast majority of people don't care much about their browser anymore. They are pretty much all good enough.
There is only one reason why chrome got so much market share: because they put an ad on the Google homepage "Try a faster browser!". The marketing was bullshit (bloated websites don't load any faster in Chrome than in other browsers), but it worked.
If any other company advertised their browser so heavily, they would be the leading browser maker today. But noone else can put ads on every load of the Google homepage.
> I think the truth is the vast majority of people don't care much about their browser anymore. They are pretty much all good enough.
I think browsers are just so complex that most people don't understand that there's something wrong with their browser or operating system and just blames the website. Few years back it feels that everybody knew that if something is a bit off on the web they should try a different browser. Now, this idea seems to be more or less gone - most people only have 1 browser installed to begin with.
Safari is the Chrome around webkit on the platform, so it tends to reflect platform major version number changes. Chrome is its own platform and does not have semantic version numbers AFAIK (or, they just break compatibility once a month)
Non-APNS push notifications landed on macOS in 16.1. They get webkit features in minor releases. Mouse and keyboard support for iPad also landed in a minor release. They average about 6 releases a year.
I thought they released Safari for Windows to enable developers to test their web based iPhone apps. Before the App store all iPhones were supposed to only run web based apps, and Windows was a much larger platform for developers.
"Basically" means "not literally but for all practical purposes might as well be" but in fewer words. Safari's major features, for all practical purposes, are released annually and not with point upgrades unless they were planned features (same with iOS, iPadOS, and macOS) that didn't make it into .0.
Among my iPhone-owning friends, it is common to hear “they didn’t add X to Safari in iOS 16 but I hope they will in iOS 17” or “did you watch the iOS 16 promos? They’re adding X to Safari.” It is expected that major Safari features coincide with major iOS releases.
I’m not comparing the features of iOS Safari and Chrome on Android. I’m just saying they approach the release schedule differently, like the exec said in the email.
I've had similar problems contributing to bazel (Google's open source build tool) for the past few years. I've found contributing only goes smoothly if there is a single Googler working in your area who cares about open source. Otherwise everything is very Google centric and the open source community is definitely a secondary concern (which is of course their right!)
I did that page was a log in or sign up page, which required an @google.com email to sign up: someone has fixed it now, it wasn’t working on Friday which was the last time I checked.
For bazel users there is also this project[0] which runs the tools natively on Linux without requiring this layer. Although you lose tools like ibtool / actool which don't have open source re-implementations.
