Hacker News Reader

Comment by bluejekyll | Hacker News Reader

Rust has extremely good FFI to C as well, if you were using that as a differentiation. No memory layout issues, etc like Go's issues.

(Nothing against Nim, I haven't worked with it yet)

View on HN

Rust FFI is not nearly as simple as Nim's interface to C where you pretty much just call C functions.

That's exactly Rust's FFI.

In its most basic form, yes, but because of Rust's safety guarantees it's not quite that simple. C functions can only be called from unsafe blocks and there is a lot to be desired when you have to pass strings back and forth (I don't know how well Nim handles this). It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api.

I strongly prefer Rust's safety but it's not quite the same as a blind FFI like Nim.

> It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api.

Can you elaborate on to how not having to type unsafe makes debugging of this easier?

Go doesn't have memory layout issues as far as the FFI is concerned. Its memory layout is basically as defined as C's is.

I thought Go had to treat compact structs from C specially.

But I stand corrected.

Note though that C++ is something very different. And c2nim can produce C++ wrappers, see for example Urhonimo, a Nim wrapper of Urhod3D. Of course this is a benefit from going via C/C++ offsetting the disadvantage. Btw, I am not negative towards Rust, although I prefer Nim for my use cases (but eventually I will try Rust) - I just wish people could view and critique languages from their respective design goals.

Reply on news.ycombinator.com