4 ms·
Rust's main problem is that libc is effectively the system API on POSIX. There's a major barrier to interacting with other libraries, particularly safely. There
by BearOso 2y ago
Rust's main problem is that libc is effectively the system API on POSIX. There's a major barrier to interacting with other libraries, particularly safely. There's also a ton of C++ libraries, like Qt, which aren't easy to do FFI bindings for.
The kernel has its own set of API primitives because it can't use user space libraries. That means the ecosystem is tiny, and rust can bring its unique advantage when experimenting with secondary languages in the kernel.
- jll29 2y ago> Rust's main problem is that libc is effectively the system API on POSIX. True, that is what makes things harder for Rust in practice. But interestingly, theoretically speaking it's more C's problem rather than Rust's - a legacy effect originating from the UNIX-C co-evolution. Good design would command a stricter separation of concerns/sub-systems (some LISP machine people will disagree, and I say it because there are a ton of them on HN, of course).
- actionfromafar 2y agoA huge chunk of C's problems in the wild is due to the unfortunate string conventions and library. Just fixing that alone, would make C much more robust in practice. Imagine a libc with actually sane strings, and a tiny tweak to the language so "some string" produces such a sane string, whatever it may be. Maybe an extension could be @"sane string".
- amszmidt 2y ago> Good design would command a stricter separation of concerns/sub-systems (some LISP machine people will disagree, and I say it because there are a ton of them on HN, of course). The Lisp Machine did have a good and strict separation of concerns, probably much better than UNIX even.