randypewick

Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.

Yay a big win for open source!

Now I wonder what other donations were deemed as much as - or more - useful.

My question was genuine: what makes the Zig devs apart from the others, according to the question op?

Arguably, there are important things that Zig devs are doing which are not "Zig dev made" (hence the "giants" I mentioned). NASA 10 rules are now rebranded as "tiger style" and marketed along Zig; Data Oriented Design existed before Zig; LLVM existed before Zig; the authors of gpui, the library that seems to have inspired gooey, apparently did a pretty great job (please correct me if I'm wrong, I don't do graphics, don't use gpui, this is what I understood when gpui came out).

I'm sure Zig devs made pretty great things, too! Does Zig make them apart? Do Zig attracts more capable devs than other languages, maybe? Genuine question!

Well, maybe I'm biased! It just stood out, so I felt it was picking.

Thank you for this info! So they are on the payroll of the ZSF. It's likely just a marketing job then, and not a flame war, or maybe an opportunistic flame war.

Sorry I did not mean this as "this article is just picking on /ranting about Rust here". I don't think the author is! I meant as "if you want to state a general truth, why would you pick a specific language as bad example?".

In general, the article is ok-ish: it makes sense to think about the correctness (whatever that means... correct according to whom?), about the bugs (according to what specs?), the users (according to what use cases?). This is ill-defined and I don't like this framing. But even assuming I like the concept, why would the author say those things about rust specifically? This seems a bit like picking to me. Kind of not very honest, maybe?

I don't know or follow the author, just stumbled on this page because a colleague mentioned it, I don't know if there is a history of anti-rust'er or something, I just found something weird and sus.

I get it, and I think it is legit.

But I'd rather celebrate high quality software than how the software is made.

I appreciate that people put the effort in what they do, but the effort could be spent on other activities that are not "typing".

Why? This was AI-made and inspired to Zed editor GUI toolkit, egui, so it's mostly a derived work.

What's so special about Zig dev that puts them aside from the giants they stand on?

Damn this person's obviously is so bitter towards Rust... I wonder why he's so obsessed with it?

I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?

But there are so many languages, I wonder why picking on Rust specifically.

I think that too many people are conflating their hate for AI, which is a technology, with the sick dynamics pushing it to gain profit. It's consumerism and capitalism to blame, AI is just a technology. As such, we want our leaders to be able to properly use such tech. But our leaders are clearly unable to do so.

Did you (or will you) implement some kind of e2e (fuzzy?) testing comparing the two binaries? Do you have particular plans regarding the release of this (for ex to not break users workflows or things like that)?

The experiment might have turned out well, or the author might have spent enough time to bring it to a place they was comfortable.

Frustration moves mountains, I don't think this rewrite was done lightly.