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
Posts
12
Comments
457
Joined
3 yr. ago

  • I hope that someone in the 40 comments i don't have time to read right now has pointed out that the premise of OP is flawed for the simple reason that Rust hit v1.0 in 2015, while Zig is still nowhere near that milestone in 2024.

    So we are not even talking about the same "future" period from the start.

    So, no need to get to the second false premise in OP, which is limiting a "future" period to one successful dominating language only. Nor is there a need to go beyond these premises and discuss actual language details/features.

  • Not only that. We don't just "inject" raw strings with the syn/quote duality. Stringified or not, the token tree will be parse-checked into the expected syn type before being used in generated code.

    So the distinction is both wrong and irrelevant. This is what I meant by wrong on multiple levels/layers 😉

  • In Rust, you provide a string — that is injected to be invoked internally. In C++, we’d just provide a callable.

    This is because Rust’s attribute grammar can’t support a callable here.

    I don't do C++ as a life choice, and thus not 100% sure what the author means here. But I have the feeling that he is wrong, on multiple levels even 😉

  • I just looked at the code, and it's actually a neat idea implementation wise, and I see now how it helped you.

    But I'm still of the opinion that its a purpose mismatch.

  • Last week I basically duplicated the serialization code to provide better debug output…

    Why was duplication needed, instead of implementing Debug using serialized output?

    And why would one want to rename stuff...etc in Debug anyway? It's for debugging?

    This looks like purpose mismatch to me.

  • Also:

    A short post on how variable names can leak out of macros

    I don't think you understood the blog OP!

  • Maybe a good idea for a post. But the amount of reaches required makes this icky.

    • Pretending people write:
        rust
          
      let Ok(x) = read_input() else { return Err(Error) };
      
      
        
      instead of
        rust
          
       let x = read_input().map_err(|_| ...)?;
      
        
    • Pretending people write:
        rust
          
       const x: &str = "...";
      
      
        
      instead of
        rust
          
       const X: &str = "...";
      
        
    • Pretending there exist people who have such knowledge of rust macros hygiene, ident namespaces, etc, but somehow don't know about how macro code expands (the "shock" about the compile error).

    Maybe there is a reason after all why almost no one (maybe no one, period) was ever in that situation.

  • you’re not supposed to immediately reach for macros

    correct

    for small things you don’t quite like about the language.

    incorrect

    Excessive macro use makes it impossible for others (including your future self) to read your code

    N/A. the macro above is trivial.

    impossible for others to read your code and there’s often good reasons why it’s designed like it is.

    fiction

  • There is a general mechanism in Rust that allows language users to add their own sugar. It's called macros 😉

      rust
        
    macro_rules! keep {
        (let $id:ident = $expr:expr => $($tt:tt)+) => {
            let $id = $expr;
            let $id = $id$($tt)+;
        }
    }
    
    fn main() {
        keep!{ let path = std::env::current_dir().unwrap() => .as_path() };
        println!("{path:?}");
    }
    
    
      

    You can remove let from the macro's fragment specifier and invocation.

  • mastering_rust

    Maybe wait until you're actually good at it.

  • Rebinding with and without mut is a known and encouraged pattern in rust. Leaving things as mut longer than necessary is not.

  • Bringing vimperator/pentadactyl back! That would be the dream.

    Anyway, last time I tested it (~3 weeks ago), servo was not very usable still with the few websites I tried. Hopefully it gets, at least partway, there in a few months.

  • Neither.

    • make new() give you a fully valid and usable struct value.
    • or use a builder (you can call it something else like Partial/Incomplete/whatever) struct so you can't accidentally do anything without a fully initialized value.

    Maybe you should also use substructs that hold some of the info.

  • If you're not into tiling, install openbox and a panel of your choosing. You will quickly find that you don't need a DE at all.

  • The maintenance is too high.

    acquired knowledge spotted

  • I will let you on a little secret.

    The best "support" you can get is support from upstreams directly (I'm involved in both sides of that equation). But upstreams will often only "support" you when you 1. run the latest stable version 2. the upstream source code wasn't patched willy-nilly by the packager (your distro).

    So the best desktop linux experience comes with using rolling distro that gives you such packages, with Arch being the most prominent example.

    The acquired knowledge that argues stability and tells you otherwise is a meme.

  • a better solution would be to add a method called something like ulock that does a combined lock and unwrap.

    That's exactly what's done above using an extension trait! You can mutex_val.ulock() with it!

    Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”.

    That's why you're told (clippy does that i think) to use expect instead, so you can signal "whatever string" you want to signal precisely.

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