5 years is optimistic. More likely 10-20 years at least. Established languages have a lot of inertia and it takes a very long time for that to change.

@shape_warrior_t I think faster delivery is also a consequence of a good DX, managing dependencies and building with cargo is probably less cumbersome than installing specific toolchain and fighting makefiles and CMake.

On the phoronix forums there are people seething about Rust nonstop. Rust in the linux kernel is their favorite enemy and they will have very strong opinions about it without ever having written rust nor a line of code in the kernel.

Rust won't 100% replace C++ code in old code bases but I'm convinced that in 5-10 years the amount of new C++ code will fall behind Rust code.

This change will be available in Rust Nightly tomorrow, and should ship as part of Rust 1.93.0 in January.

Neat!

I already do #1, and I push for #3 (specifically Python or TS) where I can at work, but there's this weird obsession with bash that people have at work despite all these scripts not running on Windows natively (outside WSL). Currently I do #2, but I often end up just stuck in bash the whole time because it's needed for things as simple as building our code. I want to try out Fish as an alternative for those situations.

Idk if that'll make you happy. The different POSIXy shells have so many subtle differences and footguns that I personally feel best

• using nushell as a daily driver, as it's sane and makes sense and errors out when it should
• using bash when forced to interact with things that are written in bash (I don't know anything written in fish or ZSH)
• using Python or Rust or so for scripts living in projects that are written in that language

I can't be bothered to look up the weird arcane sigils that make bash not shit itself when e.g. using arrays as command args or so, so I will author only the most pedestrian bash scripts where pipes are already a bit much.

Yeah I normally use Nushell as well. It was the one cross-platform shell I really liked.

I'll still use it. I just need to find something a bit closer to bash for when I need to use bash commands to do something, or where working in an environment where others use bash. Nushell has some pretty major syntax differences like && not being used to "chain" commands.

I'm using nushell, which is also written in Rust.

It has the added advantage of error handling that actually makes sense!

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 like this solution more too, what about something like?

{
    spawn(async move {
        do_something_else_with(
            ^{ self.some_a.clone() },
            ^{ self.some_a.clone() },
            ^{ self.some_a.clone() },
        )
    });
}

{
    let (a, b, c) = (self.some_a.clone(), self.some_a.clone(), self.some_a.clone());
    
    spawn(async move {
        do_something_else_with(a, b, c)
    });
}

'super1: {
    'super2: {
        spawn(async move {
            do_something_else_with(
                ^super1: { self.some_a.clone() },
                ^super1: { self.some_a.clone() },
                ^super1: { self.some_a.clone() },
            )
        });
    }
}

'super1: {
    let (a, b, c) = (self.some_a.clone(), self.some_a.clone(), self.some_a.clone());

    'super2: {
        spawn(async move {
            do_something_else_with(a, b, c)
        });
    }
}

'super1: {
    'super2: {
        spawn(async move {
            do_something_else_with(
                ^^{ self.some_a.clone() },
                ^^{ self.some_a.clone() },
                ^^{ self.some_a.clone() },
            )
        });
    }
}

'super1: {
    let (a, b, c) = (self.some_a.clone(), self.some_a.clone(), self.some_a.clone());

    'super2: {
        spawn(async move {
            do_something_else_with(a, b, c)
        });
    }
}

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

I was under the impression that the compiler already optimizes out a lot of clones where the clone is primarily used to satisfy the borrow checker. Is that not the case?

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:

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:

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.

Heh, 1911.

Not going to lie, at first I forgot that Fish was ported to Rust and was confused why this was posted here.

I need to give Fish another try now that I'm on Linux. It's a great shell, but I couldn't really use it on Windows.

I take it.

Yep exactly!

Oh ok, so if Lemmy implimented MCP you'd be able to ask Loki "hey what's the main themes people are discussing in !news@lemmy.world at the moment?" and the MCP is what gives Loki enough smarts to know which Lemmy API calls to make to get the posts?

Model Context Protocol. It's basically APIs designed specifically for AIs to use to extend their capabilities. Think of it like, instead of building tools for models to call yourself, the creators of your favorite services make the tools for you and expose them as APIs. All you have to do it point the model at their API to use it.

What is MCP?

I have been using it by default with cargo since just before 0.4, I think, and had zero problems.

The situation may have been different If I tried to use it with some non-Rust projects that need special support for some feature(s).

That's wild

😏

The plan is to eventually make it incremental, however that isn't yet implemented. It is however already pretty fast even without incremental linking.

Not stable yet, either:

The following is working with the caveat that there may be bugs:

It's not actually incremental yet.

I revolve very much around copyleft and its ideology. Free software formed my entire career, just as it did for the founders of Slint. From my point of view slint is GPL and offers some other license options for users that do not want GPL for whatever reason.

Forking slint is just as easy as forking any other GPL licensed project: Take all off slints code under GPL and you are done. Yes, you can not relicense that fork to a more permissive license without replacing all the code that you did not write... but that is exactly the same as with any other GPL project you fork. Any use of Slint under GPL is exactly as using any other GPL project, with the same obligations and protections to all parties involved.

I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from. Is it "just" because there is a company backing it? Or because that company is selling their product in addition to oing it under GPL? That is fine for the GNU project from all I understand. Or is it because of contributions happen under MIT terms? But that does not effect the end users that the GPL is protecting in any way.