Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was going to make this argument, but I actually don't think it's true in almost any case.

Most functions could be inferred, but the ultimate source of basically all of these write only APIs is FFI functions, which in turn call systemcalls.

You're at least going to need a way to annotate the FFI calls and systemcalls to describe to the compiler how they access data.



If you're calling FFIs in an inner loop, you have bigger issues than the time it takes to clear the buffer, right?


No? It depends on your definition of inner loop I guess.

If you're doing some sort of zero-copy IO, the time to clear the buffer might be non-trivial (not huge, but non-trivial). It's true that you need a large enough buffer that syscall/ffi overhead doesn't dominate, but that's not unrealistic.

It's rare that we care about this, that's true, that's why generally rust has been fine with "just zero buffers". There are definitely domains that care though.


In some languages, like Java, go and probably Javascript, this is probably true, depending on how much memory needs to to be initialized. But in rust FFI isn't any more expensive than any other non-inlined function call.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: