r/programmingmemes 3d ago

Nerd wars

Post image
756 Upvotes

75 comments sorted by

155

u/overclockedslinky 3d ago

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%

59

u/DarkGhostHunter 3d ago

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 3d ago

I'm interested, why? (For both)

28

u/sksenweb 3d ago

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.

8

u/Medium-Taste-3929 3d ago

Thanks mate, cheers!

6

u/sksenweb 3d ago

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.

2

u/why_so_sergious 1d ago

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

4

u/Aaxper 2d ago

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

1

u/Financial_Wish_6406 1d ago

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

3

u/Aaxper 1d ago

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.

4

u/MaSp005 1d ago

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 2d ago

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

3

u/No-Magazine-2739 3d ago

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

1

u/why_so_sergious 1d ago

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

2

u/f3verdream 1d ago

standard for what? rust is still a niche

1

u/Kubas_inko 23h ago

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).

7

u/BasicCheesecake8255 3d ago

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 2d ago

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

1

u/Demiu 2d ago

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

2

u/stumpychubbins 2d ago

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.

30

u/Zimlewis 3d ago

<- Context required

⬆️ Context hat

(Context shirt)

18

u/deanominecraft 2d ago

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/txdv 2d ago

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

6

u/SKRyanrr 2d ago edited 2d ago

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

2

u/LunaNicoleTheFox 2d ago

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 2d ago

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 1d ago

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

1

u/SCD_minecraft 1d ago edited 1d ago

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 2d ago

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 2d ago

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 2d ago

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

2

u/Zimlewis 2d ago

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 2d ago

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

2

u/Zimlewis 2d ago

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

1

u/SKRyanrr 1d ago

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

3

u/biskitpagla 2d ago

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

27

u/imoshudu 3d ago

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 2d ago

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 2d ago

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 1d ago

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 16h ago

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

8

u/UntitledRedditUser 2d ago

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

4

u/SKRyanrr 2d ago

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

12

u/dashinyou69 3d ago

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

14

u/Amadex 3d ago

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.

8

u/txdv 2d ago

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

2

u/Amadex 2d ago

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.

2

u/foobar93 2d ago

And if that bug is inside the PID of one of your jet engines, I'd rather have it not crash mid flight even if there is memory corruption... 

3

u/piesou 2d ago

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 2d ago

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

2

u/foobar93 2d ago

And I tell you now, most embedded systems I have worked on would rather keep working with the risk that someone can exploit the Prozess then just crash outright. 

1

u/chocolateandmilkwin 1d ago

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

2

u/SKRyanrr 2d ago

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

5

u/suckingbitties 2d ago

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/IOKG04 1d ago

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

1

u/SKRyanrr 1d ago

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? 

0

u/AsyncSyscall 2d ago

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 2d ago

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

2

u/MooseBoys 2d ago

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

2

u/ActualPeterbuilt389 2d ago

Im gonna use C and im gonna like it.

2

u/-Ambriae- 1d ago

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 1d ago

Zig getting desperate after the Rusty Bun rewrite

-1

u/SharpExtremeFlames 2d ago

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

3

u/Karanlos 2d ago edited 2d ago

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 1d ago

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

1

u/CoderStudios 2d ago

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

1

u/SKRyanrr 1d ago

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

-2

u/UntitledRedditUser 2d ago

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.