21–28 of 28 posts
Why caring about ABI stability? It's easier just to link anything statically. Benefits of dynamic linking are negligible or even negative and thus it doesn't have any sense to have headache maintaining ABI stability. That's exactly what Rust does.
There is a much simpler solution to the C++ language: just freeze it. Fork it if you want or just create your own language. This is what zig creator did. The idea is that C++ can’t move because of its own weight. Too much history, too much responsibility. Just freeze it, let new languages create new ways. It’s not that software written in it will become unmantainable. A frozen, feature complete language can still wor…
They did. It's called C++14.
> Fork it if you want or just create your own language.
They did. It's called C++17, etc.
There is a much simpler solution to the C++ language: just freeze it. Fork it if you want or just create your own language. This is what zig creator did. The idea is that C++ can’t move because of its own weight. Too much history, too much responsibility. Just freeze it, let new languages create new ways. It’s not that software written in it will become unmantainable. A frozen, feature complete language can still wor…
> Every ABI concern constrains future evolution permanently Why caring about ABI stability? It's easier just to link anything statically. Benefits of dynamic linking are negligible or even negative and thus it doesn't have any sense to have headache maintaining ABI stability. That's exactly what Rust does.
Edit:
Redox OS might be a better example, though its dynamic linking is for its Rust implementation of the C standard library.
https://www.redox-os.org/news/release-0.9.0/
> Relibc is also now key to our “stable ABI” strategy. The plan is for files to dynamically link against Relibc, which will provide a stable ABI for the dynamic linker. New POSIX functions will be added to Relibc, but none will be removed. That will leave us free to change the implementation of the services as Redox evolves, but still be able to run binaries compiled for older Redox versions.
There is a much simpler solution to the C++ language: just freeze it. Fork it if you want or just create your own language. This is what zig creator did. The idea is that C++ can’t move because of its own weight. Too much history, too much responsibility. Just freeze it, let new languages create new ways. It’s not that software written in it will become unmantainable. A frozen, feature complete language can still wor…
C++ instead needs language editions, legacy and modern. Let compilers implement a switch for which edition you're targeting. Legacy does not touch backwards incompatibly changes or language features. Modern cleans up everything.
> Every ABI concern constrains future evolution permanently Why caring about ABI stability? It's easier just to link anything statically. Benefits of dynamic linking are negligible or even negative and thus it doesn't have any sense to have headache maintaining ABI stability. That's exactly what Rust does.
I think there are some smaller Rust ecosystems where they try to have some kind of ABI stability or dynamic linking. For instance, Bevy has some support for dynamic linking. Edit: Redox OS might be a better example, though its dynamic linking is for its Rust implementation of the C standard library. https://www.redox-os.org/news/release-0.9.0/ > Relibc is also now key to our “stable ABI” strategy. The plan is for fil…
> The Zig language, created by Andrew Kelley, takes a deliberate position on standard library scope. I'm missing the significance of this callout. Is Andrew Kelley synonymous with/well known as a representative of a particular approach to language or software design?
...yes? Does he need to create more than one language to take stance on library scope?
Turns out the article is AI slop, so makes sense.
it's full of wrong assertions about zig