Regarding the rust-glancer announcement itself, I hope the author is aware that lspmux (formerly ra-multiplex) exists, and zram. If lspmux didn't exist, then yes, editor restarts would have been annoying, but that has been a solved problem for a few years already.

Also, I'm not sure hitting SSD storage too much is good strategy in general, but maybe that's an overstated concern.

Otherwise, yes, RA could do better in memory consumption and some other aspects. And yes, the LSP protocol itself is not ideal.

In any case, introducing new ideas and approaches is always good, especially when there is no "fragmentation" concerns, which I think is the case here.

If I understand you correctly, same as above with minimal modifications.

Not sure what you're asking. If it's about sorting without moving values of big structs around, maybe something like this?

It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.

I easily could have been

If you're using good projects that have Cargo.lock checked in (should be about everyone nowadays), an do the right thing using --locked with cargo install, then not really, It wouldn't have been easy.

Unless both an upstream (auto-)merging a bot PR updating to the malicious version (bad), and you installing that upstream (spectacularly unlucky), happened to coincide within that 86 minutes the malicious crate was up (39 minutes if advisory-db was hit at any step), which is almost impossible, but more importantly, fully traceable and investigable at the ecosystem level. And if we are talking released versions only, then the upstream would have had to cut a release and publish it also within that window.

But yes, this is a historic first, a malicious publishing of a real crate with real dependants.

Edit: I checked all arrayref dependants, and no crate published within the compromised window. No crate explicitly depends on >=0.3.10 (forcing the malicious version). And no crate published after the incident (potentially indicating fixing an earlier mistake) except for a couple of no-name blockchain crates that don't even have source repos.

Examples ARE usage documentation.

What value is this blog supposed to be adding exactly?
The fact that top-level and API descriptive explanations are important?
The fact that some projects don't have complete documentation?
To whom exactly would this be considered new information?

A reminder that the Servo project has resumed active development since the start of 2023, and is making good progress every month.

If you're looking for a serious in-progress effort to create a new open, safe, performant, independent, and fully-featured web engine, that's the one you should be keeping an eye on.

It won't be easy trying to catch up to continuously evolving and changing web standards, but that's the only effort with a chance.

Not sure if you're talking about the language, or the core/alloc/std libraries, or both/something in-between?

Can you provide specific examples, an which specific languages are you comparing against?

What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian

[closes tab]

What serious Linux users buy GPUs based on raw gaming performance on release week?

I personally buy based on open-source driver support. And this includes long-term active support, AND developer approachability.

My current GPU is an AMD/Radeon one because of that. But I'm reconsidering my position when my next hardware upgrade comes.

I reported an AMD GPU driver issue to mesa once. It was tested, confirmed, and patched by a competent AMD developer within a few days. Now you have easily reproducible issues like this not even going past the testing phase after many months. And there are similar issues across all model generations.

If I were to upgrade my workstation next year, I would probably go with an AMD CPU and an Intel GPU, which is the exact opposite of my current setup 🙃. One should never rely on outdated perceptions.

You should be thankful it's not 18446744073709551615 days to go.

An actually serious project that is not at the "joke" stage. Zero LLM use too:
https://nihav.org/

For audio at least, people should be aware of:
https://github.com/pdeljanov/Symphonia

Hate to break it to you, but you're not really learning.

Yesterday I was browsing /r/programming

:tabclose

fn foo(＆big, ＆chungus)

is out,

async fn foo(＆BIG_GLOBAL_STATIC_REF_OR_SIMILAR_HORROR, sendable_chungus.clone())

is in.

Or maybe you know

fn foo(＆big, ＆chungus)

is out

async fn foo(big, chungus) -> (big, chungus)

is in

Or

async fn foo(big, chungus) {
  // ...
  tx.send((big, chungus)).await?;
  // ...
}

is in

Moving (movable/sendable) data is not limited by number or direction, you know. And that second one even makes use of them great Hoare channels! And gives us control on how long we hold on to data before sending it back (modified or not). But I digress. Let's go back to the important talking point that Hoare was right!

Is everyone genuinely liking this!

This is, IMHO, not a good style.

Isn't something like this much clearer?

// Add `as_cstr()` to `NixPath` trait first

let some_or_null_cstr = |v| v.map(NixPath::as_cstr)
  .unwrap_or(Ok(std::ptr::null()));

// `Option::or_null_cstr()` for `OptionᐸTᐳ`
// where `T:  NixPath` would make this even better
let source_cstr = some_or_null_cstr(＆source)?;
let target_cstr = target.as_cstr()?;
let fs_type_cstr = some_or_null_cstr(＆fs_type)?;
let data_cstr = some_or_null_cstr(＆data)?;
let res = unsafe { .. };

Edit: using alternative chars to circumvent broken Lemmy sanitization.

As a user of both libcurl (haven't followed it's development for years though) and hyper, I'd say either commit to making hyper the default at some point and make that a priority, or drop it altogether. And since there is no intention/plan to do the former, then latter does indeed follow logically.

While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.).

:tabclose

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.

I hate that I'm linking to Reddit, but I'm just reminded of this.

Some of us knew where all the obsession with dependencies' compile times will lead, and triggered the alarm sirens, if half-jerkingly, years ago.

Compile times, and more specifically, dependencies compile times, is and has always been the most overblown problem in Rust. We would have some sort of sccache public repositories or something similar by now if it was that big of a problem.

And yes, I'm aware proc-macro crates in particular present unique challenges in that field. But that shouldn't change the general stance towards the supposed "problem". And it should certainly not trigger such an obsession that would lead to such a horrible "solution" like this serde one.

Languages: Just Rust!

You got my attention.

fn app(cx: Scope) -> Element {
    let mut count = use_state(cx, || 0);

    render!(
        rect {
            height: "20%",
            width: "100%",
            background: "rgb(233, 196, 106)",
            padding: "12",
            color: "rgb(20, 33, 61)",
            label { 
                font_size: "20", 
                "Number is: {count}"
            }
        }
        rect {
            height: "80%",
            width: "100%",
            background: "rgb(168, 218, 220)",
            color: "black",
            padding: "12",
            onclick: move |_| count += 1,
            label { "Click to increase!" }
        }
    )
}

Oh, it's stringly-typed Rust.
Yeah, no thanks.