The language wouldn’t have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don’t.

They also don’t pose potential future awkwardness if/when variant types become a thing.

A language feature is not needed because macros exist.

I would even argue that perhaps the most important role macros play is blocking adding endless language features 😉

To add to the other answers. Usually, the easiest way to answer such questions is to click on source. Then in this case, you would immediately see this comment:

// SAFETY: A `Vec` always has a non-null pointer.

Remember that this has no runtime cost and is fully type-safe.

For the sake of maximal accuracy, enum size overhead can become relevant sometimes. But a work-around exists (boxing the huge variant), and with or without boxing, the performance would still beat whatever other languages have to offer.

Otherwise, good post (I would have to say that since it mostly rehashes points I made in previous comments 😉).

Who is even the target audience of this post? Beginners (which included all of us once) ask for all sorts of things. But these features didn’t happen in Rust for a reason.

Named parameters are not needed in the age of LSP hints, where this exists as an editor feature (including (neo)vim).

But if you really want named parameters AND optionals/defaults, rust always allowed the args struct pattern:

struct Args<'a> {
  a: &'a str,
  b: u64,
  c: Option<u64>,
}

impl<'a> Default for Args<'a> {
  fn default() -> Self {
    Self {
       a: "hi", // default
       b: 3, // default
       c: None, // optional default
    }
  }
}

takes_args(Args{a: "not hi", ..Args::default()})

The builder pattern is more about valid initialization, but does interact with the arg struct pattern when you have non-default (forced) arguments, although even then, you can not use it by having:

struct Args<'a> {
  forced_arg1: &'a str,
  forced_arg2: u8,
  defaults: DefaultArgs, // implements Default
}

So mentioning the builder pattern is out of place.

Overloading is not used because we have traits (and the sound subset of specialization for when that’s needed).

So all in all, those “features” didn’t make it to Rust not because of the backlog, or for simplicity’s sake, but because idiomatic Rust (and even modern tooling in general, a la LSP) have alternatives that give you what you want and more.

Everything mentioned above should be known by anyone who knew Rust for more than a month.

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.