Comment by pizlonator
2 days ago
The problem with this post is the extent to which it shows that its author has an unhealthy obsession with me personally. It’s weird but also oddly flattering.
I don’t dislike Rust, and when I point out that Rust is not fully memory safe, it’s because I find the details here super interesting. It’s interesting that Rust deliberately chooses to have an unsafe subset. It’s interesting how that leaks out to the rest of the language. It’s interesting because us language designers ought to be thinking about how this could be avoided. It’s a hard problem! And that makes it fun!
If you do read what I say on twitter, you’ll find praise for Rust, many concessions about Rust being faster than Fil-C, as well as a wide range of other opinions. When I point out Rust’s unsafety, I’m just citing facts. It’s interesting how doing that really seems to upset some folks.
Pointing out a limitation in a technology does not imply dislike, and it’s best not to take it personally.
I don't have an obsession with you. I haven't read the entirety of your social media presence, but almost every time I see a discussion about Rust on Twitter, especially involving Fil-C, I see your criticism of Rust, without much nuance. To be honest, seeing your replies emphasizing Rust's memory unsafety under pretty much every tweet I've seen about the subject felt like an obsession with Rust, to me.
The problem I have with the framing I've seen countless times from you on social media is that I have never seen any nuance on what Rust's memory safety model achieves. You say you state facts, but stating facts without context can still be dishonest. Claims like "both C and Rust are memory unsafe languages" or "both C and Rust allow introducing memory safety vulnerabilities" are factually correct, but pretty much useless in practice.
I'm sorry for misinterpreting the "dislike" part. In retrospect I shouldn't have even brought like or dislike into it cause it was not the main point anyway. The main point was framing that I've seen on Twitter, not only from you, that in my opinion is quite one-sided.
I removed the dislike part from the post now.
Before I started talking about Fil-C, discussions about Rust’s memory safety lacked nuance: folks claimed that if you just compiled your code in Rust then it would be memory safe.
I have added the nuance. Folks now understand that there are limits to Rust’s memory safety.
What have you added to the conversation? Nothing.
>What have you added to the conversation? Nothing.
This doesn't strike me as particularly constructive discourse
> I don’t dislike Rust
As someone who really enjoys seeing all of the different programming languages and their approaches to different problems, it’s becoming obnoxious to hear the constant battles among people who think programming languages need to become part of your identity. The endless battles of superiority and tit-for-tat responses feel petty and distracting.
It’s refreshing to get back to people who just want to try different things and experiment without making everything into a battle where each side scores points against the other.
We did that to ourselves, picking languages like football memberships assigned at birth, with religious fights on the playground.
Not only languages, editors, OS, hardware platform,...
Because when it comes to apply for a job, the HR drones don't understand that one can manage to program in more than one language, use more than a specific OS, and so forth.
It was to be those specific bullet points, and by the way at least during the last five years exactly before applying to the position.
There are also the trivia questions during the interview about obscure language features.
So this naturally spills into one's identity, going back to the primitive mind of the days humans lived in small groups and it was us versus them across all tribes.
Which for those of us that are generalists, is a big pain in some body part.
Memory safety can be defined in more than one way, so it’s super worthwhile to figure out how to define it and what meets the definition and what doesn’t.
We should do more of that as a community. It’s important stuff. Ima do my part so you’ll likely see me poke at how Fil-C does a thing that Rust doesn’t do. If you read my arguments unemotionally, I think you’ll get a deeper appreciation for Fil-C, Rust, and memory safe language design generally.
What we shouldn’t do is reduce the discussion to claiming in a blog post that so-and-so “doesn’t like” such-and-such.
I think Fil-C is awesome and I very much like the style in which you present your work as well. (Hope I'm not being too emotional here!)
FWIW, I can see where TFA is coming from and I had the urge to write something "in defense of Rust" after listening to / reading some of your recent comments. I think your sister comment about the limits to Rust memory safety being real as much as the limits to Fil-C's performance and practicality is spot on, but the feeling (those emotions again) one gets from much of your commentary is that you downplay the latter quite a bit.
I think the real argument for Fil-C is that you aren't going to "rewrite in Rust" but you can often realistically recompile in Fil-C and pay the performance penalty; the fact that that Rust rewrite could also end up less safe is I think should be argued mainly from the AI angle where the only practical way is an LLM based rewrite but that would have a load of unsafe - way more than a "proper" rewrite - to be practical and the recent $100K Bun rewrite is a testament to that.
(I would love nothing more than for Fil-C to become as widely used as it practically can, since no other approach does nearly as much to secure C / C++ code and a lot of said code is out there; and security aside, it could prevent a lot of data corruption that most major C++ programs gift to their users.)
> I don’t dislike Rust
I do. Not for any technical reason, but because the Rust evangelists seem ready to burn me at the stake if i don't agree that memory safety is the one true god and Rust is it's prophet.
They hurt the language adoption more than they help it.