4 ms·
I don't agree fully with the idea of getting rid of compilation units, object files and libraries. I think their existence is necessary for fundamental technica
by choeger 6y ago
I don't agree fully with the idea of getting rid of compilation units, object files and libraries. I think their existence is necessary for fundamental technical reasons. I also consider the "link everything statically" approach failed, because in the end you want at least some run-time linking (vdso for instance and actually also the fundamental system libraries).
But also languages like rust and swift and before them OCaml and Haskell show that the current prevalent C/C++ ABI is not powerful enough. And in principle, there is not much of a difference between the reason for header-only libraries in C++ and rust not having a composable ABI. It is always about the lack of information one can pass through the ABI.
Interestingly, one does not even need to exchange the definition of a rust function or that of a C++ template for monomorphisation. One could easily define an extensible library that will create the new specialisation for any given input. One would only need to "freeze" the compiler that was used to create the library and ship it with that library. Ok, easier said than done, of course.
- fouric 6y agoWould you describe these "fundamental technical reasons"?
- choeger 6y agoWell, I think that we need an executable format that is universal, transparent, and standardized. With ELF I can take a debugger and attach it to a rust binary as well as a C++ or go binary. Also, we want to be able to interface different languages in an efficient manner. Now with a universal executable file format that becomes possible, but requires us to have a way to combine different object files. From here on, I think it becomes obvious that we should have compilation units. A language that does not allow the definition of such a standardized object is a bad citizen, IMO. Rust, for instance does allow it, but is severely hampered by the limitations of the C-ABI.
- fouric 6y agoI still don't understand what the "fundamental technical limitation is". It seems more like you're making the argument that "an executable format that is universal, transparent, and standardized" is a predicate for getting rid of translation units - which means that it's not a fundamental problem. Additionally, I don't see how removing translation units precludes multi-language integration.
- kevin_thibedeau 6y agoThese issues were solved by Ada. If we had gotten modules in 98 C++ wouldn't have become such a gnarly beast to build.
- deleted 6y ago[deleted]
- matheusmoreira 6y ago> the current prevalent C/C++ ABI is not powerful enough Can complex binary interfaces be useful though? People still write software in C. Not because it's a particularly good language but because there is a simple binary interface: symbols and calling conventions. Libraries built from this code can be used from virtually every other language. People actually rewrite stuff in C just to obtain this property. Complex binary interfaces restrict software reusability. If it's too complex, it will be extremely difficult to build and maintain the links between programs. Modern languages approach this problem by getting rid of the links. All code and interfaces are visible to the compiler, the resulting binary image is a perfectly optimized version of the whole program and nobody cares about the machinery the compiler outputs. Nothing else can interface with these programs though... I don't see people calling Rust functions from Python without using the C ABI.
- choeger 6y agoI don't think that binary interfaces should be overly complex. But I do think that we need a replacement for C at some point. And that replacement should not only be designed better, but also more powerful, yet still yield efficient code. Hence I conclude that we need some form of monomorphisation or specialisation ABI. Maybe I will some day write a blog about this...