Is "as" an uneccesary footgun?
When fitting larger types into smaller ones? Yes.
Pitfalls of Safe Rust
11–20 of 145 posts
Re: Pitfalls of Safe Rust
#12Golang might be better for writing robust software, if that is the goal. Robust services that don't go down.
Hell, just go full erlang at that point and you get loads of services for "free".
Re: Pitfalls of Safe Rust
#13Golang might be better for writing robust software, if that is the goal. Robust services that don't go down.
And why is that? I already don’t agree, but I’d love to hear your take.
Re: Pitfalls of Safe Rust
#14Title is slightly misleading but the content is good. It's the "Safe Rust" in the title that's weird to me. These apply to Rust altogether, you don't avoid them by writing unsafe Rust code. They also aren't unique to Rust. A less baity title might be "Rust pitfalls: Runtime correctness beyond memory safety."
It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…
If english had static checks this kind of runtime pedantry would be unnecessary. Sometimes it's nice to devote part of your brain to productivity rather than checking coherence.
Re: Pitfalls of Safe Rust
#15Is "as" an uneccesary footgun?
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.…
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.
Re: Pitfalls of Safe Rust
#16Golang might be better for writing robust software, if that is the goal. Robust services that don't go down.
And why is that? I already don’t agree, but I’d love to hear your take.
Mentioning golang is a rust article comment section is just bait. People just live comparing the two even though it's somewhat boring comparison
Re: Pitfalls of Safe Rust
#17Is "as" an uneccesary footgun?
Compared to C/C++ "as" feels so much safe
r. Now that Rust and we the programmers have evolved with it, I too feel that "as" for narrowing conversion is a small foot gun.
Re: Pitfalls of Safe Rust
#18Some of this advice is wrongheaded. Consider array indexing: usually, an out of bounds access indicates a logic error and should fail fast to abort the problem so it doesn't go further off the rails. Encouraging people to use try-things everywhere just encourage them to paper over logic bugs and leads to less reliable software in the end. Every generation has to learn this lesson anew through pain.
I think what you are saying is that there must be an informed decision betwen crashing the program vs returning an error. Instead of returning an error for everything that happens to be a logic error at a given level of abstraction.
Re: Pitfalls of Safe Rust
#19Is "as" an uneccesary footgun?
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.…
> guaranteed-not-NaN-nor-inf
Nor negative zero
Re: Pitfalls of Safe Rust
#20[flagged]