It’s quite simple. Just remove the permalink field! If you are calculating it then no need to store it in the struct.

This is inefficient. It should be the other way around. Remove base_url and rel_permalink, and store permalink and the rel_permalink offset.

That way, you can get a zero cost &str for any of the three.

This is neither news*, nor majorly relevant. Having rustc_codegen_gcc as a rustup component is going to be way more relevant, and is much closer to delivery, just to give an example.

* The post itself (not the content of it) appearing on the official blog was sort of pleasantly surprising (brought tears to my eyes, i tell ya). Hopefully that was a result of maturity, rather than external pressure.

unrecoverable errors in the form of panic

ahem

Is this going to be re-posted every month?

Anyway, I’ve come to know since then that the proposal was not a part of a damage control campaign, but rather a single person’s attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn’t, and there isn’t.

The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical mushrooms guidelines and real specified and implemented profiles.

The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.

So not only there was no concrete strike back, it wasn’t even the empire that did it.

systemd

Interesting. So they did it two years ago for the lols… i mean for the u8"😀"s*…which wasn’t even really needed as one of the PR comments pointed out.

* Yes, the mission creep is so bad the shit show that is systemd has emoticons.

Multi-threading support

Who stopped using pthreads/windows threads for this?

Unicode support

Those who care use icu anyway.

memccpy()

First of all, 😄.
Secondly, it’s a library feature, not a language one.
Thirdly, it existed forever in POSIX.
And lastly, good bait 😄.

whats so bad about Various syntax changes improve compatibility with C++

It’s bad because compiler implementations keep adding warnings and enabling them by default about completely valid usage that got “deprecated” or “removed” in “future versions of C” I will never use or give a fuck about. So my CI runs which all minimally have -Wall -Werror can fail with a compiler upgrade for absolutely irrelevant stuff to me. If it wasn’t for that, I wouldn’t even know about these changes’ existence, because I have zero interest in them.

Those who like C++ should use C++ anyway. They can use the C+classes style if they like (spoiler alert: they already do).

I can understand. But why would you not use newer C versions, if there is no compatibility with older version “required”?

Because C doesn’t exist in a vacuum, and Rust exists. Other choices exist too for those who don’t like Rust.

My C projects are mature and have been in production for a long time. They are mostly maintenance only, with new minor features added not so often, and only after careful consideration.

^{Still interested in knowing what relevant projects will be using C23.}

That’s good and all, but we all explicitly pass -std=gnu99 (or -std=c99 if you don’t care about MSYS2 compat) in our build scripts buddy 😉

Okay, maybe not all all. But you get the idea.

Are there any relevant projects who use the increasingly C+±infested newer versions of the language?

Correct link without /edit/: https://github.com/Nutomic/ibis/releases/0.1.2

Good thing there is no long list of signatories in this one. I had to double-check the open letter when it came out to make sure no one fake-included me there.

Hope the nu crowd are winning their arguments hard… in their own echo chambers. Because no one else is going to even feel their presence outside of them.

With hyper-threading and preemption in mind, maybe it’s concurrency all the way down 😎 . But we should definitely keep this on the down low. Don’t want the pesky masses getting a whiff of this.

The only time I took a gander on their repo, I saw the main guy asking ChatGPT how to implement something, and pointing the main dev at the answer.

Also, the pay-per-PR approach, while commendable on the surface, has a very high potential of unwanted behavior sneaking in, intentionally or otherwise, especially when combined with such blasé approach to coding and review.

This is perhaps a case where Rust’s superiority lead to questionable net gains. In the sense that if it wasn’t for Rust, such an approach would probably never have produced a product that appears, for all intents and purposes, to be perfectly functional, performant, and stable (presumably, I never used it). Rust allowed here, despite the “hard language” stereotype, a Lego model of development to work. But is that at the end of the day a good thing? That’s an open and nuanced question.

But hey, it’s all open source. If (the collective) you don’t like it, fork it and fix it, or pay for the audit, or use something else. Don’t expect anyone to shed a tear for your alleged quandary, or become a soldier in your witch hunt.

🤣

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.

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 😉

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.

Rebinding with and without mut is a known and encouraged pattern in rust. Leaving things as mut longer than necessary is not.

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.

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.

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.