Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)B

BB_C

@ BB_C @programming.dev

Posts
10
Comments
375
Joined
2 yr. ago

  • The empire of C++ strikes back with Safe C++ blueprint

    Jump
    • C++ offers no guaranteed memory safety.
    • A fictional safe C++ that would inevitably break backwards compatibility might as well be called Noel++, because it's not the same language anymore.
    • If that proposal ever gets implemented (it won't), neither the promise of guaranteed memory safety will hold up, nor any big C++ project will adopt it. Big projects don't adopt the (rollingly defined) so-called modern C++ already, and that is something that is a part of the language proper, standardized, and available via multiple implementations.

    would you argue that it’s impossible to write a"hello, world" program in C++

    bent as expected

    This proposal is just a part of a damage control campaign. No (supposedly doable) implementation will ever see the light of day. Ping me when this is proven wrong.

  • The empire of C++ strikes back with Safe C++ blueprint

    Jump

  • The only (arguably) baseless claim in that quote is this part:

    it’s theoretically possible to write memory-safe C++

    Maybe try to write more humbly and less fanatically, since you don't seem to be that knowledgable about anything (experienced in other threads too).

    It's "theoretically possible" to write memory-safe assembly if we bend contextual meanings enough.

  • [BLOG] Why Rust mutexes look like they do - Cliffle

    Jump

  • if you're really that bothered..

      rust
        
use std::sync::{Mutex, MutexGuard};

trait ULock<'a> {
    type Guard;
    fn ulock(&'a self) -> Self::Guard;
}

impl<'a, T: 'a> ULock<'a> for Mutex<T> {
    type Guard = MutexGuard<'a, T>;
    fn ulock(&'a self) -> Self::Guard {
      self.lock().unwrap()
    }
}

    or use a wrapper struct, if you really really want the method to be called exactly lock.

  • [BLOG] Why Rust mutexes look like they do - Cliffle

    Jump

  • If lock-ergonomicsⓒ is as relevant to you as indexing, you're doing it wrong.

    I would rather take indexing returning Results than the other way around.

    One can always wrap any code in {||{ //.. }}() and use question marks liberally anyway (I call them stable try blocks 😉).

  • 1.3 million Android-based TV boxes backdoored; researchers still don’t know how

    Jump

  • They don't even run Android TV. They run a modified (normal) Android. This is well known, but the article also mentions it.

  • Changes to impl Trait in Rust 2024

    Jump

  • ..and that's how you drive up metrics.

  • Australia's equivalent climates

    Jump

  • Never set foot in AU.I was under the impression that Tasmania doesn't get that cold.Also, apparently some would rather describe Perth as Mediterranean-SouthAfrican, rather than Mediterranean-Californian 😉

  • Changes to impl Trait in Rust 2024

    Jump

  • Gross!

    Unprofessional.This is why no one takes Rust seriously.

  • Async Rust can be a pleasure to work with (without Send + Sync + 'static)

    Jump

  • but futures only execute when polled.

    The most interesting part here is the polling only has to take place on the scope itself. That was actually what I wanted to check, but got distracted because all spawns are awaited in the scope in moro's README example.

     
        
async fn slp() {
    tokio::time::sleep(std::time::Duration::from_millis(1)).await
}

async fn _main() {
    let result_fut = moro::async_scope!(|scope| {
        dbg!("d1");
        scope.spawn(async { 
            dbg!("f1a");
            slp().await;
            slp().await;
            slp().await;
            dbg!("f1b");
        });
        dbg!("d2"); // 11
        scope.spawn(async {
            dbg!("f2a");
            slp().await;
            slp().await;
            dbg!("f2b");
        });
        dbg!("d3"); // 14
        scope.spawn(async {
            dbg!("f3a");
            slp().await;
            dbg!("f3b");
        });
        dbg!("d4");
        async { dbg!("b1"); } // never executes
    });
    slp().await;
    dbg!("o1");
    let _ = result_fut.await;
}

fn main() {
    let rt = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap();
    rt.block_on(_main())
}

  

     
        
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:26:13] "f3b" = "f3b"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:13:13] "f1b" = "f1b"

    The non-awaited jobs are run concurrently as the moro docs say. But what if we immediately await f2?

     
        
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:13:13] "f1b" = "f1b"
[src/main.rs:26:13] "f3b" = "f3b"

    f1 and f2 are run concurrently, f3 is run after f2 finishes, but doesn't have to wait for f1 to finish, which is maybe obvious, but... (see below).

    So two things here:

    1. Re-using the spawn terminology here irks me for some reason. I don't know what would be better though. Would defer_to_scope() be confusing if the job is awaited in the scope?
    2. Even if assumed obvious, a note about execution order when there is a mix of awaited and non-awaited jobs is worth adding to the documentation IMHO.

  • Async Rust can be a pleasure to work with (without Send + Sync + 'static)

    Jump

  • I skimmed the latter parts of this post since I felt like I read it all before, but I think moro is new to me. I was intrigued to find out how scoped span exactly behaves.

      rust
        
async fn slp() {
    tokio::time::sleep(std::time::Duration::from_millis(1)).await
}

async fn _main() {
    let value = 22;
    let result_fut = moro::async_scope!(|scope| {
        dbg!(); // line 8
        let future1 = scope.spawn(async {
            slp().await;
            dbg!(); // line 11
            let future2 = scope.spawn(async {
                slp().await;
                dbg!(); // line 14
                value // access stack values that outlive scope
            });
            slp().await;
            dbg!(); // line 18

            let v = future2.await * 2;
            v
        });

        slp().await;
        dbg!(); // line 25
        let v = future1.await * 2;
        slp().await;
        dbg!(); // line 28
        v
    });
    slp().await;
    dbg!(); // line 32
    let result = result_fut.await;
    eprintln!("{result}"); // prints 88
}

fn main() {
    // same output with `new_current_thread()` of course
    let rt = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap();
    rt.block_on(_main())
}

    This prints:

     
        
[src/main.rs:32:5]
[src/main.rs:8:9]
[src/main.rs:25:9]
[src/main.rs:11:13]
[src/main.rs:18:13]
[src/main.rs:14:17]
[src/main.rs:28:9]
88

    So scoped spawn doesn't really spawn tasks as one might mistakenly think!

  • Which protocol or open standard do you like or wish was more popular?

    Jump

  • Because non-open ones are not available, even for a price. Unless you buy something bigger than the "standard" itself of course, like a company that is responsible for it or having access to it.

    There is also the process of standardization itself, with committees, working groups, public proposals, ..etc involved.

    Anyway, we can't backtrack on calling ISO standards and their likes "open" on the global level, hence my suggestion to use more precise language (“publicly available and sharable”) when talking about truly open standards.

  • Which protocol or open standard do you like or wish was more popular?

    Jump

  • The term open-standard does not cut it. People should start using "publicly available and sharable" instead (maybe there is a better name for it).

    ISO standards for example are technically "open". But how relevant is that to a curious individual developer when anything you need to implement would require access to multiple "open" standards, each coming with a (monetary) price, with some extra shenanigans [archived] on top.

    IETF standards however are actually truly open, as in publicly available and sharable.

  • A post by Guido van Rossum removed for violating Python community guidelines

    Jump

  • It implies that the value of their policy work is significantly below...

    It's always safe to assume that value to be negative unless proven otherwise actually.

  • One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

    Jump

  • The LARPing levels in moronix comments are higher than usual, but the comedic value is still not lost.

  • Linux desktop market share climbs to 4.45%

    Jump

  • Debug-time enforcement of borrowing rules, and safety in general.

    Jump

  • I think your second link isn’t what you intended?

    You scared me for a moment there. I don't know why you thought that.

    Needless to say, even with the first example, metavar expressions are not strictly needed here, as using a second pattern and recursing expansions would work.

    But I wanted to showcase the power of ${ignore}, as it can be cleaner and/or more powerful in some cases where extra patterns and recursing expansions can get messy and hard to track.

  • Debug-time enforcement of borrowing rules, and safety in general.

    Jump

  • Is this crazy?

    A general repeat macro that works on stable Rust would work too of course.

  • wtf I hate using AI for programming, but today it was useful for Rust

    Jump

  • Debug-time enforcement of borrowing rules, and safety in general.

    Jump

  • First of all, unsafe famously doesn't disable the borrow checker, which is something any Rustacean would know, so your intro is a bit weird in that regard.

    And if you neither like the borrow checker, nor like unsafe rust as is, then why are you forcing yourself to use Rust at all. If you're bored with C++, there are other of languages out there, a couple of which are even primarily developed by game developers, for game developers.

    The fact that you found a pattern that can be alternatively titled "A Generic Method For Introducing Heisenbugs In Rust", and you are somehow excited about it, indicates that you probably should stop this endeavor.

    Generally speaking, I think the Rust community would benefit from making an announcement a long the lines of "If you're a game developer, then we strongly advise you to become a Rustacean outside the field of game development first, before considering doing game development in Rust".