One of the reasons we are stuck with C and C++ is because other language vendors, including Microsoft, dropped the ball regarding performance of type safe languages.

Do you think C++ would have been kept around if Java and the CLR had been AOT compiled to native code with focus on compiler optimisations since day one?

I really appreciate the efforts of the .NET team in adopting the Midori lessons in the standard .NET stack.

Consider virtual generic methods, for example. If your set of types is not statically bound, you can't allocate the appropriate number of vtable slots in advance, because you don't know all the instantiations.

I was already using dlls with plugins in Windows 3.1 and C++.

For that matter, it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template) - and then only for those explicit instantiations. So it is effectively impossible to have a generic C++ API using templates that is not statically linked.

Borland C++ for Windows 3.x had an initial implementation for templates as they started to be discussed at ANSI and also supported exporting classes across dlls, providing both producer and consumer were Borland C++.

Here is the link for the Borland C++ compiler documentation, I was actually using the Turbo C++ version for Windows 3.1.

https://archive.org/details/bitsavers_borlandborn3.1Programm...

The BIDS, Borland International Data Structures were the template based library that replaced the object based one and could be accessible as a DLL as well.

To export classes from DLL one would do something like

    // On the DLL side
    class _export MyClass {...}

    // On the consumer side
    class huge MyClass {...}

If you check the the templates documentation, the generated code code could be externalized, page 152, via the -Jgx.

I was only a BIDS user across DLLs, but I can easily imagine a combination of _export/huge and -Jgd/-Jgx being what was necessary to make it all work.

"it doesn't allow any templates across ABI boundary, except when you manually instantiate them (extern template)"

So you can export template instantiations, yes. But you cannot export the template itself. For fairly obvious reasons - to instantiate a template requires compiling C++ code after substituting the tempalte parameters, so to export it across ABI boundary would require including the entirety of the C++ language (or at least a substantial subset - I guess you could desugar a bunch of stuff like, say, lambdas before) in that ABI.

And virtual templates are a whole other kettle of fish, because every instantiation of a virtual template would require a new slot in the vtable - or else the generic would have to dispatched by a single method, and the caller would have to supply runtime type information. In practice, C++ just forbids virtual templates outright.

In C#, this all works just fine, because generics still exist on bytecode level, which is what gets exported - and at runtime, the JIT will instantiate the generic by compiling that bytecode to native code, separately for every instantiation (in practice they unify them for reference types, because pointers are always of the same size; but value types get distinct JIT-compiled versions each).

For virtual generics, I'm actually not entirely sure how this works, but I would assume that vtable slots are allocated in batches and filled with instantiations as needed - and when you run out of slots and need to reallocate the vtable (and potentially shift indices of other methods in it), you can just JIT-recompile the bytecode for any method that happens to use the class with affected vtable.

There are many pieces of code that you probably use every day that go to great lengths to squeeze as much power as possible. Why not help these folks help us? I'm glad there is more focus on performance because we all benefit. (Hoping to see more on the CLR side.)

Rust or D seem like the best bet here

What is missing is a company like Microsoft to push it down to mainstream developers, at all costs, like it happen to all luddites.

Try OCaml.

Use a tractor.