5 ms·

Since nobody else mentioned it, it's worth pointing out that what e.g. JS calls an array is Vec in Rust and can be as long as you want, with no ergonomic differ

by jhugo 4y ago

Since nobody else mentioned it, it's worth pointing out that what e.g. JS calls an array is Vec in Rust and can be as long as you want, with no ergonomic difference regardless of the length. Array in Rust specifically refers to an array whose length is known at compile time, i.e. a bunch of values concatenated on the stack, and that's what the limitations applied to. The quoted statement pissed me off a bit (I otherwise enjoyed the article) because it seems intended to mislead. The author should have known the colloquial meaning of "array", and "no ability to deal with" is factually incorrect.

xobs 4y ago
This is still a problem with the latest version of Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3da1b87b04c15d28ee71b1fc53dfb477 https://play.rust-lang.org/?version=stable&mode=debug&editio... If you set the array size to 32, then it works. You can get around this by using a macro, instead of `Default`, or implementing Default yourself, but it's still a limitation where you can't use an array of more than 32 elements.
- steveklabnik 4y ago
  IIRC this is a problem specific to Default, see here: https://github.com/rust-lang/rust/issues/61415#issuecomment-671081515 https://github.com/rust-lang/rust/issues/61415#issuecomment-... And here: https://github.com/rust-lang/rust/pull/62435 https://github.com/rust-lang/rust/pull/62435
- bacon_waffle 4y ago
  > You can get around this by using a macro, instead of `Default`, or implementing Default yourself For folks who aren't familiar with Rust, implementing Default yourself looks something like: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bbfc93b17a0657e83e760d0cf20e519b https://play.rust-lang.org/?version=stable&mode=debug&editio...
dhosek 4y ago
But see other comments—it wasn’t an array limitation but rather a trait limitation.
- jhugo 4y ago
  Yes, I know, but the trait limitation only applies to arrays, not to Vec. Many people coming from other languages would reach for Vec first when they want an "array". I believe that misunderstanding the meaning of "array" is why GP was surprised that Rust couldn't (ergonomically) handle more than 32 elements in an "array".
  - dhosek 4y ago
    Perhaps. But in writing an OS, sometimes you genuinely do want the guarantees of an array. You especially would want to avoid the overhead that might come when the Vec gets resized.
    - jhugo 4y ago
      Yes, and if you don't need dynamic size you can use an array (of any size). The lack of trait implementations is generally a minor inconvenience in the scale of the various inconveniences of writing an OS. It doesn't stop you doing anything.
  - bunnie 4y ago
    For the first year we did not have Vec because we were no-std + stable so we literally had to use arrays and could not reach out for heap allocated Vecs. Things got much better after we got std and could use Vec, as you note, but there are still a few locations where we have no choice but to use arrays (ie some crypto APIs that are too risky to redesign, the boot loader, and micro kernel itself which is still no-std come to mind immediately).
    - bacon_waffle 4y ago
      > we did not have Vec because we were no-std + stable so we literally had to use arrays It's true that Vec isn't available in a no-std context, but I don't think it follows that arrays are the only other option - see heapless for one example: https://github.com/japaric/heapless https://github.com/japaric/heapless I also agree with some of the ancestors: the post seems to say that the Rust language couldn't handle arrays with more than 32 elements, and (as someone who's written a fair bit of no-std Rust, before const generic) that doesn't seem right. At first, it did seem awkward to me as well that some macros weren't defined for >32 element arrays, but in practice I haven't found it to be a significant limitation. Was there a particular scenario where it wasn't feasible to wrap a >32 element array in your own type and implement Default on it?

by jhugo 4y ago

xobs 4y ago

This is still a problem with the latest version of Rust: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3da1b87b04c15d28ee71b1fc53dfb477 https://play.rust-lang.org/?version=stable&mode=debug&editio... If you set the array size to 32, then it works. You can get around this by using a macro, instead of `Default`, or implementing Default yourself, but it's still a limitation where you can't use an array of more than 32 elements.

steveklabnik 4y ago
IIRC this is a problem specific to Default, see here: https://github.com/rust-lang/rust/issues/61415#issuecomment-671081515 https://github.com/rust-lang/rust/issues/61415#issuecomment-... And here: https://github.com/rust-lang/rust/pull/62435 https://github.com/rust-lang/rust/pull/62435
bacon_waffle 4y ago
> You can get around this by using a macro, instead of `Default`, or implementing Default yourself For folks who aren't familiar with Rust, implementing Default yourself looks something like: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bbfc93b17a0657e83e760d0cf20e519b https://play.rust-lang.org/?version=stable&mode=debug&editio...

dhosek 4y ago

But see other comments—it wasn’t an array limitation but rather a trait limitation.

jhugo 4y ago
Yes, I know, but the trait limitation only applies to arrays, not to Vec. Many people coming from other languages would reach for Vec first when they want an "array". I believe that misunderstanding the meaning of "array" is why GP was surprised that Rust couldn't (ergonomically) handle more than 32 elements in an "array".
- dhosek 4y ago
  Perhaps. But in writing an OS, sometimes you genuinely do want the guarantees of an array. You especially would want to avoid the overhead that might come when the Vec gets resized.
  - jhugo 4y ago
    Yes, and if you don't need dynamic size you can use an array (of any size). The lack of trait implementations is generally a minor inconvenience in the scale of the various inconveniences of writing an OS. It doesn't stop you doing anything.
- bunnie 4y ago
  For the first year we did not have Vec because we were no-std + stable so we literally had to use arrays and could not reach out for heap allocated Vecs. Things got much better after we got std and could use Vec, as you note, but there are still a few locations where we have no choice but to use arrays (ie some crypto APIs that are too risky to redesign, the boot loader, and micro kernel itself which is still no-std come to mind immediately).
  - bacon_waffle 4y ago
    > we did not have Vec because we were no-std + stable so we literally had to use arrays It's true that Vec isn't available in a no-std context, but I don't think it follows that arrays are the only other option - see heapless for one example: https://github.com/japaric/heapless https://github.com/japaric/heapless I also agree with some of the ancestors: the post seems to say that the Rust language couldn't handle arrays with more than 32 elements, and (as someone who's written a fair bit of no-std Rust, before const generic) that doesn't seem right. At first, it did seem awkward to me as well that some macros weren't defined for >32 element arrays, but in practice I haven't found it to be a significant limitation. Was there a particular scenario where it wasn't feasible to wrap a >32 element array in your own type and implement Default on it?