3 ms·

> I've used Ada extensively in this area, and I just don't see what Rust has to offer that Ada didn't already address. Memory safety guarantees that don't go o

> I've used Ada extensively in this area, and I just don't see what Rust has to offer that Ada didn't already address. Memory safety guarantees that don't go out the window if you ever need to free a dynamic allocation, for starters. Bitfields are an underspecified minefield in C, I don't think it's as clear of a loss as you're making it sound.

ajxs 5y ago
Like I said above, I don't see the relevance in pointing out that the C standard has problems related to bitfields. Rust is supposed to be an improvement upon C. Ada managed to implement a standard for defining structures at the bit level in a portable way back in the 80s. Saying that Rust can't do it now because the C standard doesn't sufficiently specify bitfield semantics isn't a good answer.
- msbarnett 5y ago
  > Saying that Rust can't do it now because the C standard doesn't sufficiently specify bitfield semantics isn't a good answer. I don't think anybody is saying that? Particularly given that Rust is working on precisely that. The argument is merely that not currently having a good bitfield solution is hardly a showstopper for systems development, given that C is already far more popular in that area than Ada despite its deeply deficient version of bitfields which leads to them being banned in a great many codebases.
pyjarrett 5y ago
> Memory safety guarantees that don't go out the window if you ever need to free a dynamic allocation, for starters. Lots of people like to repeat this without understanding all of the other controls that Ada has for access types (pointers). Ada access types (like pointers) are typed so you could make multiple equivalents of `Foo` that can't be mixed and matched. e.g. one version of `Foo` might be for one subsystem and another version of `Foo* for a different subsystem, which would prevent you from giving an allocated object from one system to another. You also can't point an access to any arbitrary location without it being specifically marked with `all`, and there's limitations to how you can use an access that gets passed as a parameter. Due to these factors, how allocations can be used gets constrained and with Ada's support for RAII ("controlled types"), these details usually get hidden internally within types. It's not a specific block section like `unsafe`, but your unsafe memory usage is helped by the type system.

ajxs 5y ago

Like I said above, I don't see the relevance in pointing out that the C standard has problems related to bitfields. Rust is supposed to be an improvement upon C. Ada managed to implement a standard for defining structures at the bit level in a portable way back in the 80s. Saying that Rust can't do it now because the C standard doesn't sufficiently specify bitfield semantics isn't a good answer.

msbarnett 5y ago
> Saying that Rust can't do it now because the C standard doesn't sufficiently specify bitfield semantics isn't a good answer. I don't think anybody is saying that? Particularly given that Rust is working on precisely that. The argument is merely that not currently having a good bitfield solution is hardly a showstopper for systems development, given that C is already far more popular in that area than Ada despite its deeply deficient version of bitfields which leads to them being banned in a great many codebases.

pyjarrett 5y ago

> Memory safety guarantees that don't go out the window if you ever need to free a dynamic allocation, for starters. Lots of people like to repeat this without understanding all of the other controls that Ada has for access types (pointers). Ada access types (like pointers) are typed so you could make multiple equivalents of `Foo` that can't be mixed and matched. e.g. one version of `Foo` might be for one subsystem and another version of `Foo* for a different subsystem, which would prevent you from giving an allocated object from one system to another. You also can't point an access to any arbitrary location without it being specifically marked with `all`, and there's limitations to how you can use an access that gets passed as a parameter. Due to these factors, how allocations can be used gets constrained and with Ada's support for RAII ("controlled types"), these details usually get hidden internally within types. It's not a specific block section like `unsafe`, but your unsafe memory usage is helped by the type system.