5 ms·

The great part about ATS that I wish Rust had is that you can define linear types for C libraries, and in general the type system is strong enough that you don'

by PeCaN 10y ago

The great part about ATS that I wish Rust had is that you can define linear types for C libraries, and in general the type system is strong enough that you don't need unsafe{} sections. See e.g. https://bluishcoder.co.nz/2010/06/02/safer-c-code-using-ats.html https://bluishcoder.co.nz/2010/06/02/safer-c-code-using-ats.... That said, thanks for your work on Rust! Count me a big fan of the language.

doublec 10y ago
I like this one too as an example of what can be done to make a C FFI safe: https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-mem... You end up with a definition that checks at compile time that: * We don't exceed the memory bounds of the source buffer * We don't exceed the memory bounds of the destination buffer * The destination buffer is at least the minimium size required by the function documentation * We can't treat the destination buffer as a string if the function fails * We can't treat the destination buffer as an array of bytes if the function succeeds * Off by one errors due to null terminator handling are removed * Checking to see if the function call failed is enforced And there's no overhead at runtime.
dbaupp 10y ago
You can do exactly the same thing in Rust, just not in the same statement as importing the functions (which are just that, importing the functions). I regard this as one of the most powerful parts of Rust: wrapping unsafe code/APIs into safe interfaces without cost. Also, I think saying that the ATS has no unsafe{} sections is misleading: it isn't explicitly marked in the source, but the compiler still cannot check the "ownership" annotations in the imports are correct, or that, say, the preconditions of the functions (which may lead to undefined behaviour when violated) are satisfied. In other words, all of that code is implicitly surrounded in an `unsafe` block. A Rust API designed for people to use will also not have unsafe code, e.g. https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#safe-abstractions https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhe... (The linearity is essentially handled by destructors: the common case is the clean-up is just that, clean-up, and so destructors work well. It is definitely more annoying to 100%-type-check APIs that have more interesting clean-up/closing procedures but these are rarer.)

by PeCaN 10y ago

doublec 10y ago

I like this one too as an example of what can be done to make a C FFI safe: https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html https://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-mem... You end up with a definition that checks at compile time that: * We don't exceed the memory bounds of the source buffer * We don't exceed the memory bounds of the destination buffer * The destination buffer is at least the minimium size required by the function documentation * We can't treat the destination buffer as a string if the function fails * We can't treat the destination buffer as an array of bytes if the function succeeds * Off by one errors due to null terminator handling are removed * Checking to see if the function call failed is enforced And there's no overhead at runtime.

dbaupp 10y ago

You can do exactly the same thing in Rust, just not in the same statement as importing the functions (which are just that, importing the functions). I regard this as one of the most powerful parts of Rust: wrapping unsafe code/APIs into safe interfaces without cost. Also, I think saying that the ATS has no unsafe{} sections is misleading: it isn't explicitly marked in the source, but the compiler still cannot check the "ownership" annotations in the imports are correct, or that, say, the preconditions of the functions (which may lead to undefined behaviour when violated) are satisfied. In other words, all of that code is implicitly surrounded in an `unsafe` block. A Rust API designed for people to use will also not have unsafe code, e.g. https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#safe-abstractions https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhe... (The linearity is essentially handled by destructors: the common case is the clean-up is just that, clean-up, and so destructors work well. It is definitely more annoying to 100%-type-check APIs that have more interesting clean-up/closing procedures but these are rarer.)