How to Design a Replacement for C++(2010)
apenwarr.ca
apenwarr.ca
And the unfulfilled items are questionable anyway, like "do not remove the cpp preprocessor", "implicit pass-by-reference", and "typesafe varargs".
It's probably not useful to think about a generally workable swap-out replacement for C++ the language too much, since there could be no single language that fit the same odd set of niches but was still usefully different.
The emperor has new clothes now, all is well. ;-)
Yeah. Too often people complain they want a replacement, but then they want it to be a feature-complete super-set of what they didn't like too... trying to have it both ways and being oblivious to their internal inconsistency.
Objective C++ is the only mainstream, feature-complete superset of C++ that I know of. (I'm sure there are others.) Gluing two languages together is a feat, but does it solve anything? I think FFI C interfaces are the most universal heterogenous interoperability approach, rather than trying to figure out how to mangle names or pass objects that can have funky vtables.
Other no GC are oldies: Ada, Pascal, Forth, COBOL (not OO-COBOL), ObjC w/o ARC, PL/I
GC: D, Go
Non-embeddable GC: Pony, Crystal
GC claimed faster than Zulu C4 (JVM fork) and BEAM/HiPE.
Does rust do that in any way?
#![no_std] is a crate-level attribute that indicates that the crate will link to the core-crate instead of the std-crate. The libcore crate in turn is a platform-agnostic subset of the std crate which makes no assumptions about the system the program will run on. As such, it provides APIs for language primitives like floats, strings and slices, as well as APIs that expose processor features like atomic operations and SIMD instructions. However it lacks APIs for anything that involves platform integration. Because of these properties no_std and libcore code can be used for any kind of bootstrapping (stage 0) code like bootloaders, firmware or kernels.