4 ms·

That is a great point about C#, C FFI is very simple as compared to Java. Though, you are incurring the cost of C#'s GC for the rest of the program. But, even

That is a great point about C#, C FFI is very simple as compared to Java. Though, you are incurring the cost of C#'s GC for the rest of the program. But, even in that case, if you're using C/C++ then all of that is unsafe and needs to be proved, where as if you used Rust for that FFI, then you'd have less unsafe surface area to prove.

Const-me 6y ago
> incurring the cost of C#'s GC for the rest of the program With some care, it's possible to code C# without using GC much, or at all. That Linux h264 video player I've linked above doesn't allocate anything on GC while playback, it's mostly using stack (including stack-allocated spans) and very rarely for some mkv files calls .NET equivalents of malloc/free to allocate on unmanaged heap. Otherwise it probably wouldn't work due to GC issues, I think I only buffer like 150ms of uncompressed audio. Total compressed bitrate can exceed 10 mbit/sec, uncompressed is much more, I didn't expect GC to handle that much data well, especially on raspberry pi. > all of that is unsafe and needs to be proved It depends on the project. If you're working on avionics then yes in theory, but in practice you still have to use C because there's no FAA-certified builds of Rust compiler. If you're working on a videogame, desktop software, or a mobile app, good engineering and management practices are usually enough. Proving would be nice for them too if it would be free, but not at the cost of development time. > then you'd have less unsafe surface area to prove I'm not sure it becomes much less. C interop, and COM interop too, works both ways, one can easily call .NET code from C++ in the same process. I don't usually write C++ code for disk I/O, logging, compression, encryption, serialization, instead I'm passing C#-implemented COM interfaces to native code.

Const-me 6y ago

> incurring the cost of C#'s GC for the rest of the program With some care, it's possible to code C# without using GC much, or at all. That Linux h264 video player I've linked above doesn't allocate anything on GC while playback, it's mostly using stack (including stack-allocated spans) and very rarely for some mkv files calls .NET equivalents of malloc/free to allocate on unmanaged heap. Otherwise it probably wouldn't work due to GC issues, I think I only buffer like 150ms of uncompressed audio. Total compressed bitrate can exceed 10 mbit/sec, uncompressed is much more, I didn't expect GC to handle that much data well, especially on raspberry pi. > all of that is unsafe and needs to be proved It depends on the project. If you're working on avionics then yes in theory, but in practice you still have to use C because there's no FAA-certified builds of Rust compiler. If you're working on a videogame, desktop software, or a mobile app, good engineering and management practices are usually enough. Proving would be nice for them too if it would be free, but not at the cost of development time. > then you'd have less unsafe surface area to prove I'm not sure it becomes much less. C interop, and COM interop too, works both ways, one can easily call .NET code from C++ in the same process. I don't usually write C++ code for disk I/O, logging, compression, encryption, serialization, instead I'm passing C#-implemented COM interfaces to native code.