5 ms·

That was my first impression as well. So much of Rust’s language and standard library enforces correctness, that gaps start to feel way more visible. “as” is a

That was my first impression as well. So much of Rust’s language and standard library enforces correctness, that gaps start to feel way more visible. “as” is a good example. Floats are pretty much the only reason PartialEq exists, so why can’t we have a guaranteed-not-NaN-nor-inf type in std and use that everywhere? Why not make wrapping integers a panic even in release mode? Why not have proper dependent types (e.g. to remove bound checks), and proper linear types (to enforce that object destructors always run)? It’s easy to forget that Rust is not an ideal language, but rather a very pragmatic one, and sometimes correctness loses in favour of some other goals.

bombela 2y ago
I have been following rust very closely since 2013. As Rust is both evolving and spreading wide, we; the programmers, users of Rust; are also leveling up in how we approach correctness and design with it. Maybe the next evolution will be something like Haskell but fast like Rust is fast like C without the pain of C++. But it takes a while for the world to catch up, and for everybody to explore and find ways to work with or around the abstractions that helps with correctness. It's a bit like the evolution from a pointer to some malloc memory, then the shared/unique pointer of C++, to the fully safe box/(a)rc of Rust. It might be obvious today how much more efficient it is programming with those abstractions. I see some similarities with functional programming that still seems so niche. Even though the enlighteneds swears by it. And now we actually seem to be slowly merging the best parts of functional and imperative together somehow. So maybe we are actually evolving programming as a species. And Rust happens to be one of the best scaffold at this point in history. Thank you for reading my essay.
- pjmlp 2y ago
  There is hardly any evolution from pointer to malloc, C is one of the few systems languages, including those that predated it, where one needs math to allocate heap memory. I do agree that the evolution is most likely a language that combines automatic resource management with affine/linear/effects/dependent/proofs. Or AIs improve to the point to render all existing programming languages a thing from the past, replaced by regular natural languages and regular math.
  - bombela 2y ago
    Sorry, my wording was not great. You got it right. I was saying that the evolution started with (a pointer from) malloc, then uniqueptr, then box.
hansvm 2y ago
> guaranteed-not-NaN-nor-inf Nor negative zero
adgjlsfhk1 2y ago
The other option would be to change how floating point works. IEEE specifies operations, not names, so it would be totally valid to have <= on floats be a total order (using integer cpu instructions), and make a function called IEEEAreIdiotsWhoThinkThisIsFloatingPointLessThan which is the partial order that sucks.
- wongarsu 2y ago
  For purposes of sorting, Rust does offer a non-IEEE order as f64::total_cmp. You can easily build a wrapper type that uses that for all comparisons, or use a crate that does it for you https://doc.rust-lang.org/std/primitive.f64.html#method.total_cmp https://doc.rust-lang.org/std/primitive.f64.html#method.tota...
  - zozbot234 2y ago
    total_cmp is precisely IEEE's separately specified total order for floats. It's just that the more common operators do something different, and that's perhaps better for most uses where NaN are inherently unexpected and generally indicate that some kind of error condition has occurred.
- deleted 2y ago
  [deleted]
thayne 2y ago
There is some movement towards deprecating "as", and lints that will recommend using alternatives when possible, but there are a couple of cases, such as intentional truncation, where there isn't a stable alternative yet.
int_19h 2y ago
Some of these don't strike me as particularly pragmatic. E.g. are overflow checks really that expensive, given that it's a well-known footgun that is often exploitable? Sure, you don't want, say, 10% overhead in your number-crunching codec or whatever, but surely it's better to have those cases opt in for better perf as needed, as opposed to a default behavior that silently produces invalid results?
- mustache_kimono 2y ago
  > Some of these don't strike me as particularly pragmatic. E.g. are overflow checks really that expensive Did you read the article? Rust includes overflow checks in debug builds, and then about a dozen methods (checked_mul, checked_add, etc.) which explicitly provide for checks in release builds. Pragmatism, for me, is this help when you need it approach. TBF Rust forces certain choices on one in other instances, like SipHash as the default Hasher for HashMap. But again opting out, like opting in, isn't hard.
  - bobbylarrybobby 2y ago
    I'd prefer for Rust to opt for correctness/bug-freeness over performance, even in release builds. If you are doing number crunching you should have to opt out of these checks.
    - mustache_kimono 2y ago
      > I'd prefer for Rust to opt for correctness/bug-freeness over performance, even in release builds. If you are doing number crunching you should have to opt out of these checks. You can turn those checks on, in release mode, of course: https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks https://doc.rust-lang.org/rustc/codegen-options/index.html#o... But I think the behavior on overflow is to "panic!()" (terminate immediately)? So -- I guess from my POV I wouldn't in release mode. I just think that tradeoff isn't generally worth it, but again, you can turn that behavior on.
      - 2y ago
FreezyLemon 2y ago
Regarding the not-NAN float type, there was actually a proposal for it which was shot down: https://github.com/rust-lang/libs-team/issues/238 https://github.com/rust-lang/libs-team/issues/238. I don't remember every argument in there but it seemed that there are good reasons not to add it unlike a NonZero integer type which seems to have no real downsides.

bombela 2y ago

I have been following rust very closely since 2013. As Rust is both evolving and spreading wide, we; the programmers, users of Rust; are also leveling up in how we approach correctness and design with it. Maybe the next evolution will be something like Haskell but fast like Rust is fast like C without the pain of C++. But it takes a while for the world to catch up, and for everybody to explore and find ways to work with or around the abstractions that helps with correctness. It's a bit like the evolution from a pointer to some malloc memory, then the shared/unique pointer of C++, to the fully safe box/(a)rc of Rust. It might be obvious today how much more efficient it is programming with those abstractions. I see some similarities with functional programming that still seems so niche. Even though the enlighteneds swears by it. And now we actually seem to be slowly merging the best parts of functional and imperative together somehow. So maybe we are actually evolving programming as a species. And Rust happens to be one of the best scaffold at this point in history. Thank you for reading my essay.

pjmlp 2y ago
There is hardly any evolution from pointer to malloc, C is one of the few systems languages, including those that predated it, where one needs math to allocate heap memory. I do agree that the evolution is most likely a language that combines automatic resource management with affine/linear/effects/dependent/proofs. Or AIs improve to the point to render all existing programming languages a thing from the past, replaced by regular natural languages and regular math.
- bombela 2y ago
  Sorry, my wording was not great. You got it right. I was saying that the evolution started with (a pointer from) malloc, then uniqueptr, then box.

hansvm 2y ago

> guaranteed-not-NaN-nor-inf Nor negative zero

adgjlsfhk1 2y ago

The other option would be to change how floating point works. IEEE specifies operations, not names, so it would be totally valid to have <= on floats be a total order (using integer cpu instructions), and make a function called IEEEAreIdiotsWhoThinkThisIsFloatingPointLessThan which is the partial order that sucks.

wongarsu 2y ago
For purposes of sorting, Rust does offer a non-IEEE order as f64::total_cmp. You can easily build a wrapper type that uses that for all comparisons, or use a crate that does it for you https://doc.rust-lang.org/std/primitive.f64.html#method.total_cmp https://doc.rust-lang.org/std/primitive.f64.html#method.tota...
- zozbot234 2y ago
  total_cmp is precisely IEEE's separately specified total order for floats. It's just that the more common operators do something different, and that's perhaps better for most uses where NaN are inherently unexpected and generally indicate that some kind of error condition has occurred.
deleted 2y ago
[deleted]

thayne 2y ago

There is some movement towards deprecating "as", and lints that will recommend using alternatives when possible, but there are a couple of cases, such as intentional truncation, where there isn't a stable alternative yet.

int_19h 2y ago

Some of these don't strike me as particularly pragmatic. E.g. are overflow checks really that expensive, given that it's a well-known footgun that is often exploitable? Sure, you don't want, say, 10% overhead in your number-crunching codec or whatever, but surely it's better to have those cases opt in for better perf as needed, as opposed to a default behavior that silently produces invalid results?

mustache_kimono 2y ago
> Some of these don't strike me as particularly pragmatic. E.g. are overflow checks really that expensive Did you read the article? Rust includes overflow checks in debug builds, and then about a dozen methods (checked_mul, checked_add, etc.) which explicitly provide for checks in release builds. Pragmatism, for me, is this help when you need it approach. TBF Rust forces certain choices on one in other instances, like SipHash as the default Hasher for HashMap. But again opting out, like opting in, isn't hard.
- bobbylarrybobby 2y ago
  I'd prefer for Rust to opt for correctness/bug-freeness over performance, even in release builds. If you are doing number crunching you should have to opt out of these checks.
  - mustache_kimono 2y ago
    > I'd prefer for Rust to opt for correctness/bug-freeness over performance, even in release builds. If you are doing number crunching you should have to opt out of these checks. You can turn those checks on, in release mode, of course: https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks https://doc.rust-lang.org/rustc/codegen-options/index.html#o... But I think the behavior on overflow is to "panic!()" (terminate immediately)? So -- I guess from my POV I wouldn't in release mode. I just think that tradeoff isn't generally worth it, but again, you can turn that behavior on.
    - 2y ago

FreezyLemon 2y ago

Regarding the not-NAN float type, there was actually a proposal for it which was shot down: https://github.com/rust-lang/libs-team/issues/238 https://github.com/rust-lang/libs-team/issues/238. I don't remember every argument in there but it seemed that there are good reasons not to add it unlike a NonZero integer type which seems to have no real downsides.