Skip Navigation

Posts
65
Comments
607
Joined
3 yr. ago

  • Eh rust still has issues in some domains, e.g., when cyclic data is appropriate

    This might be but then again I've been writing Rust for several years and have yet to actually run into this problem. The borrow checker definitely places certain restrictions on what kind of stuff you can do (for good reasons!). Once you know how it works, your brain starts writing the code in advance to fit how the borrow checker likes it and it becomes second nature and a total non issue.

    Of course this is part of the reason Rust has a bit of a learning curve, which is fair. But any good sophisticated tool meant for professionals requires proper training and knowledge.

  • Eh, as funny as this is, I can't agree that programming peaked with Java. In fact, much of this is just a rant about JavaScript, not about much else.

    VSCode can easily do cross-file renames if you write Rust. Rust is kind of peak programming if you ask me, and it's modern and still new. I don't feel programming has peaked yet tbh.

  • Deleted

    Permanently Deleted

    Jump
  • I mean this isn't realistic at all.

  • Deleted

    Permanently Deleted

    Jump
  • Don't disagree, but you won't get rid of cars entirely and they'll still be a major part of transportation. I'm just saying they should at least be safer.

  • Deleted

    Permanently Deleted

    Jump
  • We need self driving cars to get these crazies away from steering wheels.

  • Never meet your heroes. Speaking from very literal experience regarding Stallman.

  • 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:

     rust
        
    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:

     rust
        
    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.

  • This kinda erodes cultural differences between different communities though. Different communities may have very different approaches on how to talk about a post. I feel like this approach just leads to monoculturism.

  • Finally someone who gets it. This "problem" is in fact a total non-issue. Different groups talk about the same thing all the time. This is good, not bad.

  • the conversations should be combined

    Disagree. As OP points out, there is value in separating the discussions as well.

  • 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.