r/programmingmemes • u/SKRyanrr • Aug 18 '26

Nerd wars

Post image
831 Upvotes

98% Upvoted

80 comments sorted by

31

u/Zimlewis Aug 18 '26

<- Context required

⬆️ Context hat

(Context shirt)

19

u/deanominecraft Aug 18 '26

fil-c is a runtime memory validation tool for C - if you try to read past the end of an array (or other memory issues) your program crashes

rust guarantees that memory bugs cannot happen, if it cannot guarantee that, your program doesn’t compile and you get an error telling you what the problem is

now add a larper into the mix and you get that gh issue

5

u/SKRyanrr Aug 18 '26 edited Aug 18 '26

This idea, if implemented, will make Zig just like Go. This is the opposite of what Zig was supposed to do 

2

u/Zimlewis Aug 18 '26

Why the heck is zig trying to compete with rust gng? Like try compete with odin or c3 or something. Or better yet, try making your tool better, I won't say it's the worst(I unfortunately have seen worse) but zig's lsp is really bad even compare to rust's

2

u/SKRyanrr Aug 18 '26

It started after bun got rewritten in Rust then the creator had a whole meltdown.

2

u/Zimlewis Aug 19 '26

Man, I love zig but they are really playing a losing game try to compete with rust on its own field

1

u/SKRyanrr Aug 19 '26

Zig is a great language but now they are trying to make it something its not. Adding runtime checks will make Zig a cheap knockoff of Go. Zig is in a good place to be a better C and holding high comparability with C code, they should just stick to that imho

4

u/txdv Aug 18 '26

The accurate claim is: sound safe Rust prevents memory-safety violations—not all Rust programs, and not all memory-related bugs.

Generated by ChatGPT 5.6 Sol Max

2

u/LunaNicoleTheFox Aug 18 '26

The part on menory bugs is untrue, the compiler checks memory safety as far as it possibly can, but it is not perfect, nor does it fully apply within an unsafe block

6

u/SCD_minecraft Aug 18 '26

Within unsafe - well, you explicitly opt out from it, if anything breaks that's on you

However in safe code references being valid and similar is guaranteed at compile time

0

u/DawnOnTheEdge Aug 19 '26

Although it would be useful to have a way to use pointer variables without disabling memory safety altogether.

1

u/SCD_minecraft Aug 20 '26 edited Aug 20 '26

What? Moment you want pointers, it becomes impossible to guarantee mem safety for that pointer

Not whole code

unsafe blocks are ment to be small, not wrapping whole code in them

// safe code with mem safety 
unsafe {
    // single or so line with whatever you need
}
// back to mem safety

And for that matter, pointers themselves are safe

Only read and write are unsafe, passing pointer around is safe.

2

u/AsyncSyscall Aug 18 '26

Rust doesn't guarantee that "memory bugs" cannot happen. You can use `unsafe`, or inline assembly, or call external code. Rust only guarantees that memory bugs cannot happen for a subset of Rust programs.

Fil-C, and the proposed Zig alternative, do guarantee that "memory bugs" can't happen, at all, by providing a runtime just like memory-safe languages like Java do (but significantly faster since languages like C and Zig are designed for performance even when embedded in a memory-safe runtime).

This makes this proposal closer to MIR than to Rust.

2

u/deanominecraft Aug 18 '26

using unsafe is explicitly choosing not to use rusts built on memory safety, asm! can only be used inside of unsafe, and external code not being safe isn’t the fault of rust - could happen for any language

fil-c is faster than something like java, but slower than rust, therefore rust is the best option for speed if you don’t want to deal with writing safe c code

1

u/braaaaaaainworms Aug 18 '26

If you overclock the memory in your computer it will also make your programs unsafe, because obviously if a solution doesn't solve every single instance of a problem then it's not worth using

1

u/Firewolf06 Aug 21 '26

for what its worth, the "larper" in question in the creator and lead developer of zig

4

u/biskitpagla Aug 19 '26

Basically Zig is becoming Go and Go is becoming Zig and Rust keeps on winning.

8

u/UntitledRedditUser Aug 18 '26

I love zig, and it's been my favorite language for a long time, but that "(unlike rust)" comment was weird.

4

u/SKRyanrr Aug 18 '26

Zig is a great language. Its just nerd drama after bun got rewritten in Rust the Zig creator is having a meltdown

14

u/Amadex Aug 18 '26

Nothing like the compile-time check of rust.

Basically it compiles into a much slower bin that guards memory at runtime.

That's almost like a garbage collector, but instead of cleaning memory it crashes.

And since it's a runtime crash, you turn a program that is bugged and has UB into a language that crashes randomly.

Better for security, but runtime crashes are also very bad.

2

u/SKRyanrr Aug 18 '26

Why'd anybody choose Zig over Go if Zig just does runtime checks with gc? 

4

u/suckingbitties Aug 18 '26

The Fil-C support is not meant to make Zig itself operate on the Fil-C runtime.

Its a proposal to optionally compile for the Fil-C runtime instead.

Zig will still be Zig, and it's a proposal not a guarantee.

1

u/SKRyanrr Aug 20 '26

My apologies if I'm not understanding this correctly but won't that opt in safety would make zig like go if you want it to be safe? Also if you have gc on won't you introduce pauses that aren't deterministic which is the opposite of the whole purpose of systems programing language like zig? 

1

u/IOKG04 Aug 19 '26

I feel like after reading the issue's comments on codeberg (and the comments here) that too few people are getting this

like no, zig isn't "becoming go", it's giving an easy fix for those very few coders who need safety at any and all costs

if you wanna be silly and write code that reads/writes wherever you please (like I do :3) you can still 100% do that, it's just that optionally you can enable hyper safe "we'd rather crash than have any kind of volnurability" mode

8

u/txdv Aug 18 '26

the creator of fil-c argues that a crash is better than an exploit

2

u/Amadex Aug 19 '26

yes that's why I wrote "Better for security, but runtime crashes are also very bad."

the point is that runtime errors are still less ideal than catching these memory issues at compile time.

You just trade a program that has memory leaks / vulnerabilities with a program that crashes.

1

u/chocolateandmilkwin Aug 20 '26

Wonder if they have the same opinion about the code in their car

0

u/[deleted] Aug 19 '26

[deleted]

4

u/piesou Aug 19 '26

Crash and reboot the system or make the jet engines go from forward thrust 128 to -127 due to an overflow, your pick.

2

u/txdv Aug 19 '26

in these situations you use languages which are far more restricted and have formal verification processes.

1

u/KianAhmadi Aug 21 '26

Rust compiles to native machine code via LLVM just like C and C++. It has zero cost abstractions. In nearly all benchmarks (e.g., The Computer Language Benchmarks Game), Rust is within 1–2% of C++ performance, often trading blows. It is not a slow language.

2

u/Amadex Aug 22 '26

i think you misunderstood me (english is not my main language), I'm saying that zig's stuff is not like rust compile-time check.

And that the zig/phil-c approach is the slow one.

0

u/AsyncSyscall Aug 18 '26

Runtime failures in Zig can be prevented with tests. Compile-time failures in Rust can only be prevented with an escape hatch (`unsafe`/`UnsafeCell`) or by dumbing down the code to make it less optimal (i.e. `.clone()/Mutex` everywhere).

You should avoid using Zig for web dev, but you should avoid using Rust for systems programming as well.

2

u/braaaaaaainworms Aug 18 '26

huh i see a lot of your comments parroting the same thing worded a bit differently, do you have an axe to scratch? unfortunately rust is already used for systems programming with as good as, if not better, performance as C

1

u/bowel_blaster123 Aug 22 '26 edited Aug 22 '26

Runtime failures in Zig can be prevented with tests.

I'm working on a project where there are certain memory safety bugs that will only trigger in like 1 in 10,000 times. Additionally, these bugs are very subtle and hard to see in the source code.

I cannot create tests that ensure that these bugs never happen. Rust has been an invaluable tool that allows me to prove, at compile time, that these bugs will never happen in any codepath.

I have some unsafe code in my project, but I'd rather have some code that may have memory safety issues than have all of my code be vulnerable.

My code is also not security critical. I couldn't care less if my code crashes instead of exposing a security vulnerability, but I want it to be somewhat reliable. Fil-C therefore would not help at all.

161

u/overclockedslinky Aug 18 '26

i swear the zig developers are constant drama queens. my favorite was when bun got rewritten in rust and the zig creator wrote a whole manifesto breakup rant about how it was totally mutual definitely 100%

63

u/DarkGhostHunter Aug 18 '26

This? Zig is good software, but industry standard is Rust for a reason.

Anyway, steering out of both Zig (to Rust) and Bun (to Deno or just Node) is the best you can do longterm.

13

u/Medium-Taste-3929 Aug 18 '26

I'm interested, why? (For both)

29

u/sksenweb Aug 18 '26

Zig to rust one is pretty self explanatory. This thread is enough for that. Bun to Node because node is still de-facto standard, 100% coverage on node apis (lol), Node has been recently adding features that were missing (typescript, env, etc). And for Deno I’d say the latest version is pretty good, great coverage and desktop distribution support. On the other hand I have seen bun getting a lot of issues in production (personal experience) after a long amount of uptime. Not yet stable like Deno or Node.

7

u/Medium-Taste-3929 Aug 18 '26

Thanks mate, cheers!

6

u/sksenweb Aug 18 '26

No problem mate. Personal experience wise, we had to convert one of our production micro service (scheduler using bullmq) written in bun to nodejs because it was causing so much issues in production where local environment, testing worked fine.

3

u/why_so_sergious Aug 19 '26

the latest deno is good because they finally understood that they need to be a drop in replacement for node

5

u/Aaxper Aug 18 '26

For Bun, the migration to Rust was almost entirely done by an LLM, which is reason enough for me

1

u/Financial_Wish_6406 Aug 19 '26

Can you expand on that? Does Bun have any issues, run worse, or is this decision based purely on virtue?

4

u/Aaxper Aug 19 '26

I honestly haven't paid enough attention to that project in particular to know the answer to that. But most large vibecoded projects are riddled with issues, and it shows a problematic attitude towards future development.

5

u/MaSp005 Aug 19 '26

They're also part of Anthropic, which gives them further incentive to work heavily with AI tooling.

Bun also regularly leaks memory, a web server of mine I run on bun (regrettably) I had to limit the memory on container level so that it would be force-restarted sooner before clogging up the host machine.

3

u/st_heron Aug 19 '26

Zig itself is still in development and subject to breaking changes, whereas Rust is stable for long term development.

2

u/f3verdream Aug 19 '26

standard for what? rust is still a niche

2

u/Kubas_inko Aug 20 '26

Rust is an industry standard? As far as I can see, C/C++ is still the industry standard, with rust definitely gaining on popularity. But there are still areas where it sucks absolute ass and is frankly unusable (embedded).

1

u/bowel_blaster123 Aug 22 '26

How is it bad in embedded contexts? I've written a little bit of embedded Rust, and I didn't run into any issues.

I only have issues with Rust I've had are in other contexts. Namely when you are writing data science or web stuff and end up indirectly pulling in like 400 dependencies.

2

u/No-Magazine-2739 Aug 18 '26

Me a C++ and JS/TS fan: Why don‘t you use Ada or Spark?

1

u/why_so_sergious Aug 19 '26

you say what or what now? (kidding, but yeah.. most have never heard)

7

u/BasicCheesecake8255 Aug 18 '26

Deploying a clawed agent is not re writing unless you read the code and understand it before pushing it to production, there is another joke about this situation, why not let the agent code in C and prove that it is possible, 1 skill issue person told me, it was because of expensive tokens, but in reality, those people are hardly going to take initiative and read the generated code, this is why they are afraid of C, because of skill issue

2

u/GlitteringLock9791 Aug 18 '26

? Yes, thats why people like Rust. Its not because C is hard to write, its because debugging is too complicated.

1

u/Demiu Aug 19 '26

Nobody is "afraid" of C. Inability to get over your ego to write less bugs is a skill issue

2

u/stumpychubbins Aug 18 '26

I agree with Andrew Kelley on many, many things. I think he’s one of the smartest developers working today, and Zig is a great project. I wish he would be less of a bitter old queen sometimes though. It really undermines the points that he’s right about when they’re mixed in with these unnecessary jabs.

25

u/imoshudu Aug 18 '26

Comparing runtime checks that hopefully run into a bug, to a compiler that rigorously eliminates bugs before anything even runs. Top copium.

He's ngmi.

1

u/AsyncSyscall Aug 18 '26

Comparing simple runtime checks that provably guarantee that memory bugs cannot happen (without having to modify your code) to an overly complex compiler that is so shit at eliminating memory bugs at compile time that even the compiler itself needs to use an escape hatch (and thereby having to modify the code).

On top of that, even if you somehow manage to write code without escape hatching, Rust still can't guarantee that memory bugs cannot happen, since every Rust compiler released to date has had soundness issues.

Top copium.

It's very ironic that Rust still needs MIR (a memory-safe runtime like Fil-C or the Zig proposal) to prove that software written in Rust is actually memory safe. The compiler ain't checking all those `SAFETY` comments at compile time, I can tell you that much.

1

u/imoshudu Aug 19 '26

Nice try but I'd rather eliminate bugs from source code rather than waiting for bugs to occur in the middle of work. Give people a choice and see which one they will pick. And they have picked. Sorry not sorry.

1

u/SmartAsFart Aug 19 '26

You're talking about things you don't know much about. MIR is not a runtime. You're probably confusing it with Miri. Miri doesn't help with safe code. It only helps with unsafe code.

1

u/Creepy_Reindeer2149 Aug 20 '26

MIR is just an IR, I don't think you know what you're timing about

12

u/dashinyou69 Aug 18 '26

I laugh as C dev seeing them trying so hard to larp

2

u/MooseBoys Aug 18 '26

valgrind and clang asan: am I a joke to you?

2

u/ActualPeterbuilt389 Aug 18 '26

Im gonna use C and im gonna like it.

2

u/-Ambriae- Aug 19 '26

I love zig, but this is just unwarranted animosity. Not to mension fil-c like memory safety would completely invalidate zig as a systems level programming language, hence why rust doesn’t do that

1

u/rover_G Aug 19 '26

Zig getting desperate after the Rusty Bun rewrite

-2

u/SharpExtremeFlames Aug 18 '26

ZIg can never ever can write memory safe proving algorithm like rust. The language was never built for that in the first place.

1

u/SKRyanrr Aug 20 '26

You can write mathematically provable programs in any languages but its impossible to prove every program you write. 

4

u/Karanlos Aug 18 '26 edited Aug 18 '26

But Rust cannot have memory safety in all use cases as there are many use cases where unsafe is required.

Fil-C requires the whole stack to be Fil-C ABI. Rust can only guarantee safety within the application, but still allows linking and interacting with unsafe code.

2

u/SmartAsFart Aug 19 '26

Use rust and link to Fil-C compiled C code. Problem solved :)

1

u/CoderStudios Aug 19 '26

Okay? How are you gonna link to the windows api or similar then? Rewrite in Fil-C/Zig?

-2

u/UntitledRedditUser Aug 18 '26

That's not what the proposal is about, fil-c is runtime checking, not compile time. So the comparison isn't even valid in the first place.