The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad.

1: http://savannah.gnu.org/bugs/?712

Gets the greenlight, everyone who worked on it is invested and motivated to make the results look good, and it builds from there.

A different vision: computers empower people. An OS provides APIs and UI conventions, and apps can use them to build upon each other, so that users can bring their knowledge from one app to another. Users invest in learning advanced techniques because it's worth it, because all our software participates (think keyboard shortcuts or Unix pipes).

The web has none of this. Websites are not cultivating a new UI vocabulary. Most websites don't support even basic interactions beyond click and tap. They may even actively parasitize the old: Google Docs supports cmd-Z but not Edit->Undo; we are being taught to distrust our UI, the OS itself is being eroded.

> users who cannot perceive or experience the web delivering great experiences

Then build those great experiences and Apple will change its tune. Seriously.

> The web was a lifeboat away from native apps for Windows XP users. That lifeboat won't come for iPhone owners because Apple won't allow it.

iPhone owners are happy and Apple knows it. On the iPhone, web apps are not a lifeboat; instead the web is displacing high-quality native apps with alien-feeling lowest-common-denominator stuff. No thanks.

Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.

What is creepy here is that a random website which I closed ten minutes ago get to know when I unplug my ethernet cable. I am happy to tell a website when I close it - that is its purview. But when I close a website I want it to be closed. Now I know it lingers.

That's a massive asterisk. In practice, copying values to the heap is complicated. Integer values may be memcpyed. Pointer values may require read and/or write barriers, or perhaps reference counting. Compound types may require some combination. Maybe you have copy-constructors and you need arbitrary callouts! These implementation details can't be hand-waved away.

> The difference between this case and the polymorphic case is that here the underlying structure (eg "compare" or "insert") isn't done in a homogeneous way (single routine) for every type: the polymorphism is ad-hoc and not parametric. The vtable solution is a form of boxing and that impacts runtime

Kindly, I think you have some confused terminology. Parametric vs ad-hoc polymorphism is a difference in the type system, and occurs long before the optimizer kicks in. Parametric polymorphism is a single function implementation parametrized by types. Ad-hoc polymorphism is multiple implementations, and the compiler chooses one based on types (e.g. C++ overloading or template specialization).

If the optimizer chooses to emit a specialization, that does NOT make it ad-hoc polymorphism. That's just a detail of the optimizer. And it is a distinct optimization from inlining, for good reasons, like not wanting to be tied to the inlining cost model.

> for efficient compilation of languages with generics you need to have an efficient compilation of parametrically polymorphic functions (by type erasure)

C++ and Rust both have efficient generics without using type erasure. Boxed generics are not necessary at all, as long as you accept static linking.

It sounds nice, but there's a huge performance difference between boxed and specialized. When you make a function generic, the compiler boxes values, conservatively emit retain/release, others.

The difference is so large, it justifies giving the programmer levers to control specialization. Swift team has added "@_specialize" as a hint. I think they should go further.

What I don't know is how specialized generics can participate in library evolution. If a dynamic library provides a sort routine, and you specialize it, what happens when the library changes? This is where a JIT or the .NET model (compile at install time) can pay off. Apple has laid some groundwork for this (bitcode, Rosetta 2) so they can certainly get there if they choose to.

Anyways I think the real dilemma is whether generics are meant to be a performance optimization (C++, Rust) or just for typechecking (Java, C#). The cost of saying yes to performance is library evolution.

If the app really is a game changer, if it's that compelling, Apple will absolutely change its tune.