BB_C @ BB_C @programming.dev

Posts

10

Comments

365

Joined

2 yr. ago

Some shallow observations without really getting into the code:

misc

• Was hosting labeler/ResNet50_nsfw_model.pth in the repository really necessary?
  (I like my --filter=tree:0 clones to be maximally fast and small.)
• Why not declare all dependencies in the workspace?
• How old is the code (for real)?

rsky-crypto

• anyhow in library code.
• Not liking that multibase dependency much either. I know that base64 at least got re-written since that crate's last update (Nov 6, 2020).

rsky-feedgen

• serde_cbor is long dead (I was a user myself).
• I'm not even sure why serde_cbor and serde_ipld_dagcbor are dependencies anyway.
• We moved from lazy_static to once_cell a long time ago. And your use is available in std on stable Rust today.

rsky-firehose

• Here, all three CBOR dependencies are actually used.
• CBOR (the format) used in $CURRENT_YEAR is meh anyway. But I guess that comes from IPLD.

rsky-identity

• anyhow in library code.

rsky-pds

• That's quite the dependency list! Too long for me to take a closer look.
• How many *base* dependencies does one need? All of them of course!

rsky-syntax

lazy_static and anyhow again.

That's all from a code organization and ecosystem PoV. Otherwise, things look normal and not fancy (which is good).

Unfortunately, I don't have the time to look beyond that at this moment.

Your LLM of choice needs better training.

I haven't used either (yet). But as someone who wants to move away from JSON as a configuration format, ron doesn't, for me, offer much of a value proposition. And it's too tied to serde IMHO.

I also like KDL's optional type annotations (yes, I'm crazy that way.).

all the equivalent functionality and how to translate existing concepts over from one language to the other.

Antithetical would be the word to describe this, I think. Although I've seen such titled content.

• Why do you think this is a debugger issue?
• May I suggest you try to learn how to use the rust toolchain directly first?
• The error message looks informative to me. What part of this line did you not get?

      
   either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present 
  
    

I think you're tying yourself too close to VSCode. Reading this Cargo guide is a minimal requirement. And you should learn how to use cargo (the command), at least for basic operations. This is not hard. If anything, it's much simpler than those bloated and opaque editor/IDE setups.

🤣

I don't know, and I don't want to get personal. But that's usually a sign of someone who doesn't even code (at non-trivial levels at least), and thinks programming languages are like sport clubs, developers are like players contracted to play for one and only one club, and every person in the internet gantry need to, for some reason, pick one club (and one club only) to be a fanboy of. Some people even center their whole personality around such fanboyism, and maybe even venture into fanaticism.

So each X vs Y language discussion in the mind of such a person is a pre-game or a pre-season discussion, where the game or season is an imaginary competition such people fully concoct in their minds, a competition that X or Y will eventually and decidedly "win".

Maybe that was an exaggeration on my part. Some junior developers probably fall into these traps too, although one might expect, or maybe hope, that their view wouldn't be that detached from reality.

I'm hoping to finally finish and send out a delayed new release for one of my older and mature CLI tools this weekend. It's written in C btw 😄

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.

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.

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.