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.

C++ has proven (at great expense) that documenting footguns is not sufficient. At all. You have to make them impossible.

As long as it's documented well, I don't think it should matter. If it doesn't do the thing you expect, don't use it. I'm assuming there's almost a 1:1 association between devs who will use Duration::from_days() wrong and devs who would make their own constants and use them wrong, so the least harmful approach is to make them available and document them clearly.

But yeah, this topic has been beaten to death and I'm mostly whining about a bit of typing, which is now substantially less with Duration::from_hours() being stabilized. I'm happy they stabilized minutes and hours, and I'm hoping they stabilize days at some point.

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 😅

That sounds like an irrelevant problem though. A duration is explicitly not concerned with daylight savings at all, I've always thought of it as the amount of actual time (i.e. from a monotonic clock) that has elapsed between two absolute times. So a time diff between noon on daylight savings change day and the day prior would either be 23 or 25 hours, not exactly equal to Duration::from_days(1). There's no time zone or even year context for Duration::from_days(1), so it should always be defined as a naïve calculation involving fixed definitions for hours per day and seconds per hour.

Years are a bit more controversial, to the point where 365 days and 365.24 days are both acceptable in different contexts, and that latter value could change in the very long term (millions of years). But I think up to days, most can agree that the value assumes exactly 24 hours and is completely separate from the idea of wall clocks changing based on local law.

Now, if we want to support "logical" time math, add that to the date/time methods likelogical_add(Duration) that adds/subtracts daylight savings hours and leap seconds as needed so if you add a multiple of 24 hours, you'll get the same wall clock time just on a different day. Maybe chrono does that, IDK, but it would be nice to have day resolution supported at the stdlib level for simple cases where I'm looking for day chunks. It's not a big deal, and Duration::from_hours(24) is plenty readable.

This, and similar posts discussing the same subject, seem to fail to realize that you can trivially implement your own back-off strategy using Mutex::try_lock(). This can have significant performance implications in use-cases where absolute low latency is not required.

I rarely see this get mentioned, although I think I did see it once or twice.

A shout out to the spin crate too, which has a lot of options that may interest people explicitly supported/exposed. It also supports no_std which can be immensely useful in some use-cases.

Huh, TIL. Good post!

Leap seconds are already a problem for minutes and hours, which is probably why they weren't added until now.

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.

@BB_C @jwr1 that's awesome. gave me a chuckle. gotta love rust (i use a lot of rust)

You see, rust platform support can't be bad when even meme platforms can get to tier 1.

Those const context additions are neat.

I actually wanted that just the other day. I actually wanted days, but at least now I only need Duration::from_hours(24).

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.

The non-strict versions also panic by default, but only in debug mode. So if you were willing to use abs() you should be willing to use strict_abs().

Arguably a bit of a mistake to have the "obvious" function names be surprisingly unsafe, but I guess it's too late to fix that.

They're released on a schedule so they are often quite boring.

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

:) Probably right to be careful, im a bit nuts.

The strict_* set of integer function look interesting though I'm unlikely to use something that panics by design. I'm sure that's useful in programs that panic to indicate problems. Do those exist? I always treat panics as a design failure.

Duration::from_mins() is useful for me since I've been doing Duration::from_secs(minutes * 60) for some things in my projects, which bugged me a bit.

User named 1984 wanting us to talk... hmmm

So much excitement here.. Dont all talk at once.

Sorry for the late reply.

The royalty free license tries to get as close to MIT as we can while limiting the use on embedded…

I think I understand that perspective. But please also understand the other perspective: how a user has the right to see it, when they are not connected to the company.

If you are such a user, then you need open-source software for your daily life. And you use it. At the same time, you see:

• IntelliJ Idea taking its MIT-licensed Rust plugin and deciding that it'll be more profitable for them to close-source it, so you won't have it anymore. And of course nobody forked the plugin. The idea is clear, the company wants you to use Rust Rover.

• Apple's OS, being historically based on 4.4BSD-Lite2 and FreeBSD, and being the second-highest valued company in the world (!), is happily living with all and any of that MIT-licensed code, while BSD itself is stagnating. It's not Apple's fault of course, Apple is not a bad actor here. It's just not very smart or future-proof to spend a lot of time binding yourself to a system that can easily turn into stagnation.

On the other hand, GPL-licensed projects protect themselves very well. When things don't go well, you see successful foks (such as Forjeo, LibreOffice, MariaDB). When things go well, you just see it thriving (such as Linux, most userland software).

We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times,...

To answer this and to conclude, for me personally, it's not about how to write something. It's about what is written. The fact that Slint aims to be good for a for-profit company, does not and will never nullify that MIT contributions are re-licensed as GPL or proprietary. It will come up, and it's fair when it does... as I see it, at least.

We are improving compilation performance through (1) parallel compilation in the compiler front-end, which delivers 20-30% faster builds, and (2) making the Cranelift backend production-ready for development use, offering roughly 20% faster code generation compared to LLVM for debug builds.

👍

I think maybe it's a short term thing. They're trying to expedite getting off wikidot and having a read only copy of their data is the fastest way to do that. I'm assuming the plan would be to then transition to a write enabled implementation as soon as possible. That's my best guess anyway.