3 ms·
A rewrite of such technologies would not fix their semantic problems and related architecture decisions around tractability, debugging etc. For example, rewriti
by matu3ba 2y ago
A rewrite of such technologies would not fix their semantic problems and related architecture decisions around tractability, debugging etc. For example, rewriting LLVM and GCC does not fix the underlying problem of missing code semantics leading to miscompilations around provenance optimizations in the backend.
Likewise, Vulkan is not an ideal driver API (to argue on GPU performance) and let's not even start with OpenGL.
POSIX is neither optimal, nor has it a formal model for process creation (security). So far there is no good one for non-micro Kernels.
From my experience with C++ I do expect
1. "verschlimmbessern"/aggravate-improving due to missing edge cases,
2. only spatial problems aka bound-checks to be usable (because temporal ones are not even theoretically discussed) and
3. even higher language complexity with slower compile times by front-end (unless C++ v2 like what Herb is doing becomes available).
- pjmlp 2y agoMost likely, however then the question is what technoglies get to replace those with safer approaches. Which as proven by the failure to push safer whole OS stacks, tends to fail on the political front, even if the technologies are capable to achieve the same. I would have loved to Managed DirectX and XNA to stay around and not be replaced by DirectXTK, that Singularity, Midory, Inferno, Oberon, Midori,.... would gotten a place in the market, and so forth.
- lambdaone 2y agoThis is why Rust is the leading alternative to C/C++; it was designed from the start to both call and be called from other languages to enable progressive migration, rather than requiring an incompatible and impractical big bang change that would never happen. The mitigations in the cited article are good too, but they don't replace the need for safer languages.