The C ABI can already be used, it comes with all the existing safety guarantees that C will provide. Isn’t this as good as C?

▲

pizlonator 6 hours ago | parent | next [-]

It is as good as C.

It's also as bad as C.

I'm saying that the chasm to cross is a safe ABI.

▲

sagarm 6 hours ago | parent [-]

There is no existing safe ABI, so this cannot be an adoption barrier.

	▲	pizlonator 6 hours ago \| parent [-]
		Lots of reasons why it is. I'll give you two. 1) It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable. 2) If you really have 20 libraries calling into one another using C ABI, then you end up with manual memory management and manual buffer offset management everywhere even if you rewrite the innards in Rust. So long as Rust doesn't have a safe ABI, the upside of a Rust rewrite might be too low in terms of safety/security gained to be worth doing

▲

ozgrakkurt 6 hours ago | parent | prev | next [-]

I found c ABI a bit too difficult in rust compared to c or zig. Mainly because of destructors. I am guessing c++ would be difficult in a similar way.

Also unsafe rust has always on strict-aliasing, which makes writing code difficult unless you do it in certain ways.

Having glue libraries like pyo3 makes it good in rust. But that introduces bloat and other issues. This has been the biggest issue I had with rust, it is too hard to write something so you use a dependency. And before you know it, you are bloating out of control

▲

ahartmetz 6 hours ago | parent | prev [-]

Not really. The foreign ABI requires a foreign API, which adds friction that you don't have with C exporting a C API / ABI. I've never tried, but I would guess that it adds a lot of friction.