211–220 of 227 posts
Earlier quoted context omitted.
The Rust memory model is deviating from it a little in order to enable some norestrict-based optimizations that aren't really done for C, even though (as you know) LLVM can't really take advantage of them yet.
I imagine that in C if the compiler can prove that two pointers don't alias than it can elide a load?
Earlier quoted context omitted.
`as` is not considered idiomatic in Rust code,. `.into()` for infallible cases and `.try_into()` for fallible cases are preferred in almost all cases (in the case of floats there's still discussion around the correct behavior of `.try_into()` for edge cases). > So I think this is again an example of rust making a decision that hurts program correctness. Could you expand on other examples?
> `as` is not considered idiomatic in Rust code Yes it is. It's used all the time . There's a reason as_conversions defaults to Allow in clippy. Of course, there are lots of situations where `as` is the wrong tool for the job, but I think it's a bit of a stretch to call `as` "not idiomatic". It's perfectly idiomatic in lots of situations. Whether or not it should be idiomatic is a separate question.
The docs, the reference, and the RFCs all regards “as” as a mistake that should not be used, and _many_ features have been introduced over the years to reduce the cases in which “as” is the only alternative.
There are cases in which there is currently no alternative, so people “must” use “as”. This does not imply that it is idiomatic to do so.
This rather niche fixing of unsafe behaviour is excellent: https://blog.rust-lang.org/2020/07/16/Rust-1.45.0.html#fixin... I spent a few years as a scientific programmer and this is exactly the sort of thing that just bites you on the behind in C/C++/Fortran: the undefined behaviour can actually manifest as noise in your output, or just really hard to track down, intermittent problems. A big win to get rid of it.
Agree, a lot of people focus on Rust and memory safety vs C/C++, but the lack (nearly) of undefined behavior is at least as important/helpful.
Earlier quoted context omitted.
>= 1.0 in semantic versioning universally means that it should be "stable enough"
I think you're missing the point of contention. > [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use. API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production. Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far…
If we agree on the definition, then it generally follow that being productive (e.g ergonomic API), optimised (polishing work), not having rough edges, and having implemented the many required features (a server framework actually require a LOT) all those steps are done AFTER the foundational work of pre 1.0 Those after work will probably sometimes break API stability as we are not omniscient and forward compatibility is non trivial hence the needs for production ready frameworks to have had many breaking change releases so more like 3.x than 1.x Hence, it follows that the temporary but general API stability guarantees from a 1.0 are insufficient and general means that is can begin to be used, not that it should be used.
Rocket and any other rust server framework are not production ready as soon as you go beyond trivial use cases.they have dangerous foundational bugs and show stopper missing features. I have built a startup product with actix web (but studied rocket too) and those are dangerous economic bombs.
Earlier quoted context omitted.
I think you're missing the point of contention. > [...] it's not even 1.0 yet. Thus, it isn't stable enough for production use. API stability (i.e. how the API will change in future) is largely unrelated to the question of whether you can trust it to work in production. Maybe for some people API stability is a "must have" for production use, for the sake of minimizing churn when upgrading dependencies, but that's far…
> plenty of libraries with stable APIs that are buggy piles of hacks. E.g. the API: char *gets(char *s); has not changed in probably forty years. Rock stable!
Earlier quoted context omitted.
They are doing it wrong then.
One could argue that if you are relying on magic number schemas to decide if a library is stable enough for your usecase, it is you that is doing it wrong.
> Rust 1.45.0 adds the ability to invoke procedural macros in three new places! Rust 1.45 will be the Rocket Release. It unblocks Rocket running on stable as tracked here https://github.com/SergioBenitez/Rocket/issues/19 This is so excellent, and I love seeing long term, multiyear goals get completed. It isn't just this release, but all the releases in between. The Rust team and community is amazing.
For those out of the loop like me, Rocket is a web framework for Rust that apparently was using a lot of experimental features. https://rocket.rs/ Or maybe it's an explosive weapon crafted with metal pipe and gunpowder. https://rust.fandom.com/wiki/Rocket
Can we please deprecate the "as" operator? Something so lossy and ill-conceived should not be a two-letter operator.
What would you suggest for replacing e.g. `u8 as usize`?
The numeric casts are the easy part of this.
Earlier quoted context omitted.
I actually find that people who aren't that familiar with programming are pretty quick to accept the idea that aliasing xor mutable is an okay rule... not because it's been exhaustively explained, but just because people have no real expectations at all about how things should work when they're starting out. A lot of language rules seem arbitrary at that point. Afterwards, when using other languages, they may even fi…
From someone who is self taught and learned C as a second language, is teaching rust at this stage a great idea? there is a lot of news about rust lately and it very much seems like people are seeing rust as a hammer and the world as nails.
Earlier quoted context omitted.
The Rust memory model is deviating from it a little in order to enable some norestrict-based optimizations that aren't really done for C, even though (as you know) LLVM can't really take advantage of them yet.
I imagine that in C if the compiler can prove that two pointers don't alias than it can elide a load?