A language’s type system doesn’t need to model every possible type of guarantee. It just needs to provide a type safe way to do 95% of things and force its users to conform to use the constructs it provides. Otherwise it becomes a buggy hodge podge of features that interact in poor and unpredictable ways. This is already the case in Scala; we’ve discovered almost 20 bugs in the compiler in the past year.

Until iPad OS actually becomes capable for complex work and multitasking, I can’t see what the benefit of strapping such a powerful chip to an iPad is.

Of course, LLMs can still speak about probabilities and mimic uncertainty, but that’s likely (heh) coming from their training data on the subject matter, not their actual confidence.

Humans are interesting because they employ a two-phased approach: when we’re learning, we fake confidence (you’d never write “I don’t know” on a test unless you truly had nothing of value to say), but during inference, we communicate our confidence. Some humans suffer from underconfidence or overconfidence, but most just seem to know innately how to do this.

Can anyone who works on LLMs clarify whether my understanding is correct?

That being said, anyone who’s operated a two-sided marketplace knows that one of the biggest problems is consumers using your site as an index, and then seeking to dodge your fee by meeting with the seller on another platform, where they don’t have to pay it. This was a big problem for my startup.

This is a negative externality, because they’re extracting value from your platform (the list of sellers, products, prices, ratings, etc.), without paying for that value. If left unchecked, this could make running the platform financially unviable. One way to prevent this is to paywall your platform, but not every consumer wants to pay a subscription.

I think it’d be fair for Amazon to prohibit sellers advertising other platforms on its own, but prohibiting them from offering lower prices outside of Amazon outright definitely seems anticompetitive.

I got the same feeling when they mandated USB-C on Apple devices. If the problem of waste were tackled categorically, then the state wouldn’t need to get involved in matters it has no business getting involved in.

It has to stop at some point. Eventually, the regulations will become so complicated, unknowable, and unenforceable, that they’ll have no choice but to say “this is enough” and start tackling the root of the problem instead.

You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, as a result, they're becoming very popular. I can pull down some code, run `cargo build`, and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community.

If you want your language/library/framework/layer in the stack to become popular, make the tooling good and make it easy for folks to get their questions answered. Everything else will follow.

Also, a side note: I dislike a lot of the popular conversation around the Baumol effect because they’re usually along the lines of “this can’t be the only reason my healthcare or education is expensive”, which is true (there are other factors at play), but the Baumol effect still explains a lot of it.

We do the work that’s too large in scope for other teams to handle, and clearly documenting and enforcing best practices is one component of that. Part of that is maintaining a comprehensive linting suite, and the other part is writing documentation and educating developers. We also maintain core libraries and APIs, so if we notice many teams are doing the same thing in different ways, we’ll sit down and figure out what we can build that’ll accommodate most use cases.

This has helped to explain why, at least for me, LLMs have been more useful for reading code than writing code. I’m also just reluctant to submit the code it’s written on my behalf without making hundreds of small adjustments, but I think I’ll need to get over that, as I wouldn’t be so nit-picky a junior engineer were completing the task.