2 ms·

> However, I must ask: is there a world in which interop didn't have to be so bad without hugely sacrificing memory safety? You can't really make interop nicer

by lmm 2y ago

> However, I must ask: is there a world in which interop didn't have to be so bad without hugely sacrificing memory safety? You can't really make interop nicer than the lowest common denominator, and when one of the sides is C then that lowest common denominator is very low. Rust is one of very few languages that can potentially interop with memory-safe languages without having to completely buy into a common runtime - e.g. it's increasingly popular to write Python extensions in Rust and I believe there are now libraries for doing that without having to go via C - and when you have richer abstractions available on both sides of the line then you can make use of them. But to work with C you have to work like C, at least at the boundary.

flohofwoe 2y ago
It's not "C - the language" but "C - the calling convention" that gets in the way of higher level languages. And it's actually also wrong to blame C alone, ABIs are mostly a convention between operating system and CPU vendors, C compilers have to play by those rules just as any other compiler that wants to output code that can call (efficiently) into operating system APIs (and we could just as well be stuck with Pascal calling conventions instead, which was used by 16-bit Windows versions).
- lmm 2y ago
  > ABIs are mostly a convention between operating system and CPU vendors, C compilers have to play by those rules just as any other compiler that wants to output code that can call (efficiently) into operating system APIs Yes and no. Unix has a very C-oriented ABI because it's written in and tied to C, and since Unix and C won other operating systems have felt pressure to make their ABI C-friendly. > we could just as well be stuck with Pascal calling conventions instead, which was used by 16-bit Windows versions If we'd gotten Pascal strings in the ABI that alone would have eliminated one major class of bugs.

by lmm 2y ago

flohofwoe 2y ago

It's not "C - the language" but "C - the calling convention" that gets in the way of higher level languages. And it's actually also wrong to blame C alone, ABIs are mostly a convention between operating system and CPU vendors, C compilers have to play by those rules just as any other compiler that wants to output code that can call (efficiently) into operating system APIs (and we could just as well be stuck with Pascal calling conventions instead, which was used by 16-bit Windows versions).

lmm 2y ago
> ABIs are mostly a convention between operating system and CPU vendors, C compilers have to play by those rules just as any other compiler that wants to output code that can call (efficiently) into operating system APIs Yes and no. Unix has a very C-oriented ABI because it's written in and tied to C, and since Unix and C won other operating systems have felt pressure to make their ABI C-friendly. > we could just as well be stuck with Pascal calling conventions instead, which was used by 16-bit Windows versions If we'd gotten Pascal strings in the ABI that alone would have eliminated one major class of bugs.