I think you’re making some poorly-researched assumptions.

In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print

Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.

If your goal is small binaries, it’s possible to get them with Rust, too: https://github.com/johnthagen/min-sized-rust

There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.

It’s actually just English with Greek letters, just as the user above writes in English but uses the þ (thorn) character.

Πρεσυμαβλυ, ἰτ ἀλρεαδυ ὐσεδ ΣΙΜΔ, ἀνδ θατ’ς ὁ θε ἐξιστινγ ΓΝΥ ὐτιλιτυ βεατ ῾Ρυστ βυ ἀ φακτορ ὀφ 17ξ.

Harder than C?

Looks like it wasn’t even a bug, just a missed opportunity to use SIMD.

Oh, I thought by “already” you meant right now. I would expect that you can use any Wayland-compatible compositor once their Wayland support is complete, yeah.

Not sure about Steam.

No; Wayland is also a protocol, and Niri relies on that protocol, so Niri doesn’t bypass the need for Wayland support.

“Heartbreaking: the worst person you know just made a great point”

deleted by creator

Right, but their endorsement is still likely to do more harm than good in terms of public perception of the law, I think.

I understand having severe philosophical disagreements with the Rust project, with the majority of Rust users, or with the uutils project specifically. What I don’t understand is this part:

If you go to the website of the Rust programming language nowadays, one of the first things you’ll notice is that their primary communication platform is Discord. Yes, you read it right - their primary communication platform is Discord, a proprietary spyware program that is owned by a Chinese investment company and has backdoors to various other national intelligence agencies too.

Rust did have an official Discord, years ago, before switching to Zulip (alongside other official communal hubs, most prominently the Discourse forums that the author complains about next). But this was written in March and specifically says “nowadays”, and I cannot find any mention of Discord on the Rust website.

If you drive a car, have you read the entire owner’s manual for every car you’ve owned? If you’re a homeowner, how about your hvac system? What about your system shell? Your compiler(s)?

At some point you need your tools to be intuitive enough that you don’t need to read an entire manual in order to do your work.

Oh, you just mean he believes that’s the future, not that he agrees with it or thinks it’s a good thing.

Do you mean the “this is where we’re headed” comment? That’s not agreeing with the direction.

For what it’s worth, I agree with you about branches, and there are various ongoing discussions about how to make working with branches more convenient. I use an experimental feature called “advance branches” that makes it mostly fit my workflows, and the other benefits of jj are sufficient that I haven’t switched back to git.

I create log files of runs, temporary helper scripts, build output, etc. in my working copy all the time.

The solution to this is to just have a more aggressive .gitignore. But also, note that the “working copy commit” isn’t generally something you want to push or keep; think of it more like a combination of the git staging index and an automatic stash.

Maybe? But also, maybe not? ChromeOS is not just for “people who are already interested in Linux.” It’s true that only techies are likely to care about ChromeOS vs some hypothetical non-Google OS/distro, but the vendors are techies, so if a vendor wanted to sell a Chromebook-like product without involving Google, they’d presumably be interested in an OS/distro like the one the article is talking about.

But if something like this existed, consumer vendors such as Dell might pre-install it.

Apparently the JS name was selected and announced in partnership with Sun from the very beginning, and Sun had the copyright over both Java and JapaScript up until the acquisition by Oracle. I had no idea, but that makes perfect sense.

Oracle? Oracle owns Java, not JavaScript.

Edit: mea culpa! Sun owned both!