Thank you for your detailed reply.

Focusing on x86_64 (and linux), can you expand on what’s missing to reach ABI parity?

And somewhat relatedly, are you leaning towards publishing an std component built with the backend or not?

I’ve been watching the number of failing UI tests shrinking fast with excitement.

Would you expect the backend to be fully ready by the end of the year? Or are there big/complicated blockers that remain, or LLVM-isms that make full or nearly full parity impossible?

Relatedly, cranelift cg early struggles had to do, in part, with intrinsics support. I remember talk of somehow solving the problem systemically and not having to implement all of them in the backends directly? Where did things end up regarding that, and how does this backend deal with this problem?

And finally, using evcxr with :timing enabled, and switching between backends with :codegen_backend, I notice that gcc is the slowest when it comes to compile time. Is that because more IR is given to gcc to generate from, or is gcc/libgccjit itself slower now?

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.

It was a backhanded complement based on that fact, my friend.

At least use slop in the README so we can complain.

Yes and no.

And you clearly missed the enums part.

most types are not thread-safe.

Safe rust is thread-safe in the sense that you can’t have runtime thread unsafely. If we are going to ignore the role of compile-time errors, then literally nothing is safe.

Also, what is “most”? Can you source that claim?

great article!

Is it?

I didn’t read past the first sentence:

The Arc type is Rust’s thread-safe smart pointer

This is horrible in my view. All types that implement Deref and/or DerefMut can be called smart pointers, and everything is “thread-safe” in safe Rust.

If I had to call something “Rust’s thread-safe smart pointer”, it would be the actual references &T/&mut T where T: Send + Sync.

Digression: All the traits involved like the 4 mentioned above point to the C++ centric concept of smart pointer not mapping cleanly to Rust semantics imho. But that’s a long lost battle.

Let’s see what the official Arc docs say:

A thread-safe reference-counting pointer.

Will you look at that! An actually accurate short description that is already available.

While not widespread, there is already a small myth out there that paints Rust as if it’s Swift-like, a ref-counting centric language.

You can custom serialize (timestamp, tz) or timestamp, offset or (timestamp, tz, offset), no?

Ironically, that was a part of a back-and-forth I had with burntsushi (jiff dev) right here on lemmy.

It’s called a spam re-post.

Change your name to Err::<!,!>(return).unwrap()

Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.

Coming from C not C++, I actually didn’t like chrono at first, but grew to be okay with it, and it gets the job done.

Fastrand is not cryptographically secure

That’s not relevant when it’s a question of interface.

fastrand has a single Rng struct that drives everything else. Was the option to replace the implementation details of this struct explored? No idea.

Ctrl-F fastrand (0 results)

I had to stop reading very early. Sorry, but if you’re going to do this topic, at least acknowledge the other very popular randomness crate, and argue why it wasn’t good enough for what you wanted.

The test suite passes, so it’s 100% memory safe according to zig guidelines and standards.

This is the way.

Actually, I didn’t notice your use of clone() which is even worse.

Here is what I had in mind. One can put the T: Default bound on the wrappers themselves to simplify, or add potentially expensive transformations for non-Default types.