Might not be new but it’s not been posted here before :)

Not nearly as readable though

I don’t agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don’t have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.

Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It’s just a nudge, nothing more.

An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.

This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an “LTS” release, then crates could be encouraged to keep their MSRV compatible with that release.

But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on “just any” third-party crate at higher integrity levels.

I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn’t even be that hard (it’s certainly been done in many crates already).

This is the way with modern software engineering, especially in the industry. It comes from the basic fact that:

1. Companies want to get code for free from the internet - someone else already wrote that code, let’s use it for free and have better profit margins!
2. Companies do not want to spend time and effort vetting that free code, as that would make it… well, not free. That would require manpower (perhaps unless you trust AI to do it these days…) and that’s money.

Basically they want to eat their cake and have it too. This applies to all modern package managers for modern languages that make it easy to distribute your own code and consume free online code.

I doubt the industry will ever mature to a point where this will stop, as the tradeoff of getting free code with no work is just too good for most companies, especially the smaller ones.

I think you’re misunderstanding the never type. The never type is not a hack at all. It’s a very natural part of the type system. Just as you have the unit type (), which is the canonical type with only 1 value, you also have the never type, the canonical type with 0 values.

This is extremely useful in generic code. See my other comment in this thread.

This is an unfortunate wart to appease a desire to those that want to be able to write code like they do in legacy languages

What do you mean with this? I can’t really decipher it. What alternative to the never type would you want?

shouldn’t Rust enforce returning from function

This is impossible. How would you enforce that? What prevents a function from panicking, aborting the whole process or just going into an infinite loop? All these things correspond to the never type.

I think you’re misunderstanding what the never type is. It’s not equivalent to None at all. It’s a type that doesn’t have any values. This is useful in situations with generic code where for example an error type can be chosen as the never type. Then you could destructure or unwrap a Result without handling the error, cause the type system guarantees the error never occurs.

I think you should read up on the never type a bit more. It’s a perfectly natural part of the type system. In fact you can make your own very easily: enum Never {}

Can’t wait for the never type to be stable :D

I like the idea of using block labels, but I don’t like the ^ symbol. There’s already precedent for using keywords before blocks, like with async. There’s also already super let in nightly I believe.

I would say depends but generally I would think not? I mean say you clone a string because you move it in one place and also need to borrow it in another place. So you clone to avoid the borrow checker erroring out on that. As far as I know, there will be two different strings created with separate allocations and all (but I could be wrong).

Really not a fan of this approach. Makes the order of operations extremely weird. I would much prefer having super blocks that are explicitly inserted in the above scope. I.e. this:

tokio::task::spawn(async move {
    do_something_else_with(
        super { self.some_a.clone() },
        super { self.some_a.clone() },
        super { self.some_a.clone() },
    )
});

Would desugar to:

tokio::task::spawn({
    let first_block = { self.some_a.clone() };
    let second_block = { self.some_a.clone() };
    let third_block = { self.some_a.clone() };
    async move {
        do_something_else_with(
            first_block,
            second_block,
            third_block,
        )
    }
});

Only problem is if the clone is inside another block… but perhaps you could do super super { ... }? But that sort of gets crazy and makes it very hard to read again.

Why do you say Leptos is more popular? Dioxus has more stars on GitHub.

I want a way to clearly express durations in terms of days

The argument here is that expressing durations in terms of days is a bad idea because “day” does not really convey a very precise duration, as it is not always 24 hours.

Maybe you won’t be confused by Duration::from_days right now, but maybe a junior dev before they get their coffee, or even the senior dev on code review might miss stuff like that.

I mean, it says what it is right there in the second sentence on the page, to be fair:

Welcome back to another Dioxus release! Dioxus (dye • ox • us) is a framework for building cross-platform apps in Rust. We make it easy to ship full-stack web, desktop, and mobile apps with a single codebase.

It’s not like the context was very far away 😅

Personally very intrigued by Dioxus. I posted this thread the other day about frontend and I can’t help but be drawn by the possibility of not having to learn a JS/TS framework and instead go with a Rust framework. But at the same time, Dioxus is still very much behind on the ecosystem side because it doesn’t have access to all the libraries and tools and support and online help that popular JS/TS frameworks do. So I’m sort of conflicted. Being a frontrunner comes at a cost sometimes 😅

Only thing I actually don’t care much about with Dioxus is the fullstack premise. I’m not much for the fullstack idea. I think there is value in separating the backend and frontend. I feel like in principle it should be possible for many frontends to exist for a single backend. I feel the fullstack approach makes the backend and frontend too coupled and it would probably be hard to write a different frontend for the backend.

so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.

Well… that’s your opinion. But other people disagree and say that this could be confusing. But I won’t rehash the whole debate, you can read it here instead: https://github.com/rust-lang/rust/issues/120301

I’m sure it’s already been discussed to death 😅

Duration::from_days was proposed but consensus was not reached as “day” is somewhat complicated as that sometimes can be 23 hours or 25 hours due to daylight savings or 23:59 due to leap seconds shenanigans.

I know, but they used to be more exciting I feel like - but I guess it’s only natural that development speed goes down as more and more low-hanging fruit has already been picked. What remains of the non-boring stuff is probably quite complicated and difficult to stabilize.

TL;DR:

• Use std Mutex if your critical sections are short and you’re not too worried about fairness.
• Use parking_lot Mutex if you experience thread starvation and don’t care about panic poisoning.

Duration::from_mins and Duration::from_hours seems nice. Otherwise kind of a boring release if you ask me.