My somewhat hot take is that design patterns and SOLID are just tools created to overcome the shortcomings of bad OOP languages.

When I use Rust, I don’t really think about design patterns or SOLID or anything like that. Sure, Rust has certain idiomatic patterns that are common in the ecosystem. But most of these patterns are very Rust-specific and come down to syntax rather than semantics. For instance the builder pattern, which is tbh also another tool to overcome one of Rust’s shortcomings (inability to create big structs easily and flexibly).

I think you’re completely correct that these things are dogma (or “circlejerking” if you prefer that term). Just be flexible and open minded in how you approach problems and try to go for the simplest solution that works. KISS and YAGNI are honestly much better principles to go by than SOLID or OOP design patterns.

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.

With Linux, I can change just about everything. If I want a real-time kernel, I can switch. If I want a different desktop environment, change. If I want more control from my keyboard, Linux has my back.

As much as I agree with the sentiment of the article, this is a terrible reason and more likely to scare people away from Linux rather than get them to install it.

If you know what a “real-time kernel” is, you’re probably already using Linux and you are a highly technically literate user. Any “normal person” user is going to look at that and think “Oh, I guess I need to understand technobabble in order to use Linux”. Normal users care about easy, preset defaults, not customization.

Once again, Linux adoption is kneecapped by its own users, who forget what normal people really care about.

If I eventually decide I want to split my one file script into two files will I be able to?

I honestly would say that’s when it goes from a script to a proper project, and you should treat it like that with a Cargo.toml and everything. I think this is a case where it would push you towards better practices and I don’t think it should support multiple files like that.

I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing.

References are just pointers, they don’t have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic.

How do I now actually get a &Arc? Without implicitly cloning?

& is such a fundamental part of the syntax, I really don’t think it’s meaning should be muddled.

The title makes it sound like writing Rust for git will be mandatory

Did you read the post? The author suggests trying out other version control systems too.

May well be. I’ve just ordered a gateron switch tester. They apparently lube their switches for you, so maybe their switches are quieter/smoother 🤞

Yea my big problem is also that I need way more storage than what I have on my phone.

I’ve never personally had these issues. Sent large files without problem and never had discovery issues.

I’d love to use this but I just mostly don’t use multiple devices at the same time, so I don’t see how the sync would ever happen.