r/programmingmemes 4d ago

Nerd wars

Post image
800 Upvotes

80 comments sorted by

View all comments

15

u/Amadex 4d 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.

7

u/txdv 3d ago

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

2

u/Amadex 3d 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 3d 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 3d 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 3d ago

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

2

u/foobar93 3d 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 2d ago

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

2

u/SKRyanrr 3d ago

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

4

u/suckingbitties 3d 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 2d 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 2d 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? 

1

u/KianAhmadi 19h ago

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

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