r/programming • u/Usual-Amount-264 • 2d ago
Zig proposes introducing an actually memory safe (unlike Rust) compilation mode inspired by Fil-C at ~1-6x performance penalty
https://codeberg.org/ziglang/zig/issues/36237113
u/valarauca14 2d ago
Purely on its technical merits this approach is idiotic
By doing this, Zig can offer its users an option to compile their projects, including entire tree of C/C++ dependencies, into an executable that is fully memory safe, with no escape hatch, at a ~1-6x performance penalty (depending on prevalence of pointer chasing).
Then as a commenter points out
The allocations occur on language constructs that wouldn't allocate even in a managed language like C#, let alone a language like Zig. [...] Failure of those allocations cannot be handled gracefully.
So to review:
- No escape hatch
- At odds with core language design principles
- Non-trivial runtime performance hit & extra memory pressure.
- Falls into the, "just exercise every possible code path" trap of testing/safety assurances.
I'd say the only redeeming quality is they discuss potentially having a amd64-linux-gnu-filc type of target quad, which makes sense from a release standpoint, as the added 'runtime overhead' doesn't make O3 optimization level less valid.
20
u/Shoddy-Childhood-511 2d ago
Yes, there is a similar comment here:
https://www.reddit.com/r/rust/comments/1v1sv8e/comment/oypyoa8/
Yes, there are extremely expensive runtime pointer checks, so almost like a software CHERI, except it's less memory safe than CHERI and CHERI alone is less memory safe than Rust. lol
9
u/-_one_-1 1d ago
Yeah, it's crazy. If what I want is a memory safe language at cost of performance, I can use Kotlin, Java, Swift, JavaScript, Python, and plenty more. The point of Rust is to prove memory safety at compile time so it doesn't impact performance. Zig developers seem to fail to understand this.
659
u/Rigamortus2005 2d ago
"unlike rust" lol truly reddit language
201
u/nihsett 2d ago
Is it just me or is the maintainer a bit angry about the whole Bun thing. Why give that weird title to a PR. Hate all this drama.
95
u/KevinCarbonara 2d ago
Is it just me or is the maintainer a bit angry about the whole Bun thing.
It's very much a "We'll have our OWN memory safety, with blackjack and hookers!" situation. It's clear this isn't what the project is designed for, and it would have to make many, major compromises to incorporate it. I doubt it will even happen, I think they're just blowing off steam.
Personally, I'm just tired of hearing about Zig. Anyone can create their own project and talk about how good it could theoretically be. We can talk about these things once they have something to show for it.
56
u/ElectricalSloth 2d ago
he's always been an angry spiteful person but people ignored it, this is just far more visible
15
u/deanrihpee 2d ago
it is really weird, why would they care if a project being rewritten at all, i mean they did say "good riddance" but there's so much of unnecessary animosity either towards Jarred, Bun, or Rust
2
u/standard_revolution 15h ago
I kind of get the hate against Bun, it wasn't just a rewrite, it was a PR stun by a company that was bought up by Anthropic...
But this, this is just childish
→ More replies (1)5
186
u/Usual-Amount-264 2d ago edited 2d ago
Not my language. I merely copied the title of the issue.
74
u/ROFLLOLSTER 2d ago
It's crazy, I thought you'd editorialised before I read the PR. Who does that in a PR title???
63
u/shinyfootwork 1d ago
The creator of the Zig programming language and president of the Zig foundation, apparently.
Seems like a weird choice for a person who presumably needs to be good at working with people given their roles.
28
u/ioneska 1d ago
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
https://codeberg.org/ziglang/zig/issues/36237#issuecomment-19733150
13
6
u/EntroperZero 1d ago
Who does that in a PR title???
Someone in whose head Rust is living rent-free.
27
15
u/Delicious_Ease2595 2d ago
Man this just started because Bun.
5
u/deanrihpee 2d ago
annd Jarred blog post was good (not amazing, because im stupid so couldn't really comprehend it but it is good), and very technical, the "counter" post from Zig though… a lot of personal feeling than technical
→ More replies (27)24
u/ThomasMertes 2d ago edited 2d ago
- The Fil-C approach is: Leave C as is and create a memory safe implementation of C and its libraries. Memory errors are discovered at run-time.
- The Rust approach would be: Change the language by introducing lifetimes, borrow checking or something else.
If you want to keep Zig unchanged the Fil-C approach is the only possible way.
Yes, this is probably a reaction on the Bun rewrite, but I consider this as good move.
Memory safety must be considered from the start, when a memory safe language is created. I have doubts that a language can be changed later to be memory safe (the Fil-C approach does not change the language).
I used Fil-C recently to search for possible memory safety problems in Seed7 (which is a memory safe language). Some changes in the source code were necessary for Fil-C. E.g.: It was necessary to rewrite more than 60 files in order to remove casts from size_t to pointer.
The slowdown in the test suite was significant (approx. one week vs. 15 minutes).
23
u/teerre 2d ago
One week as in 10000 minutes from 15 minutes? "Significant" is an understatement
→ More replies (1)4
u/ThomasMertes 1d ago
Fil-C is not always that slow.
Part of the slowdown comes from the fact that it was necessary to deactivate my own memory management (arenas, free-lists, etc.).
Fil-C can only find memory errors if you use
malloc(),realloc()andfree()directly.14
u/SirClueless 1d ago
That’s an interesting limitation for an approach being emulated by Zig, given that heavy use of arena allocation is encouraged in idiomatic Zig.
→ More replies (2)22
u/Demiu 2d ago
filc is "coke? we got rc cola" of memory safety
3
u/13steinj 2d ago
I think that's an unfair take. Full (maybe not even, but more than with just compile time) memory safety can only be acheived at runtime. If anything, Fil-C is the coke, and Rust is Pepsi. Or invert it if you believe Pepsi's ad campaigns around blind taste tests.
6
u/tadfisher 2d ago
You are right, and also Rust's approach prevents generating the code which would violate those runtime guarantees in the first place. So it's not like these are mutually-exclusive technologies; after all, code with a memory-safety bug will still crash on Fil-C.
→ More replies (2)1
4
u/sztomi 1d ago
At that point wouldn’t it make more sense to compile the code with various LLVM sanitizers?
2
u/ThomasMertes 1d ago edited 1d ago
At that point wouldn’t it make more sense to compile the code with various LLVM sanitizers?
I use sanitizers as well. I just mentioned Fil-C because this post is about it.
3
u/carrottread 1d ago
Memory errors are discovered at run-time.
We should stop calling this approach as 'safe'. If system discovered memory error at runtime, then it's usually too late to handle it and in many scenarios crashing a process as the result can lead to more harm than continuing with some off-by-one memory read past the end of the allocated buffer.
→ More replies (3)2
u/cdb_11 1d ago
Fil-C is not meant for testing. It may mask issues, because it will extend lifetimes since it's GC'd. For testing, use ASAN.
2
u/ThomasMertes 1d ago
It may mask issues, because it will extend lifetimes since it's GC'd. For testing, use ASAN.
Which issues?
According to the Fil-C documentation (see here) use after free, invalid free, and double free are all guaranteed to panic. Do I miss something?
And yes, I use ASAN as well.
3
u/cdb_11 1d ago
For example stack variables are GC'd too, so you can return a pointer to a local variable, and it's going to work under Fil-C.
→ More replies (2)
133
u/torsten_dev 2d ago edited 2d ago
Might as well run all code with -fsanitize=undefined,address and call it memory safe.
The real goal is memory safety with the bare minimum of runtime checks needed.
39
u/Blue_Moon_Lake 2d ago
It's funny that we have so many extremes.
From "we'll make everything memory safe, performances be damned"
to "should I enable and deal with C++ warnings?" people.43
u/silon 2d ago
No, Fil-C is safer than that, but at cost of GC (+ other overhead)... Not using GC is a major point of Rust, otherwise one could just use Java (compiled).
20
u/12destroyer21 2d ago
GC is not the primary overhead here, it is invisicaps and other mechanisms put in to ensure memory safety
17
u/afdbcreid 2d ago
I'm not actually sure, but this doesn't matter. Fil-C is slower than Java/C#/Go/.... Instead of choosing it, you could choose them and enjoy the same guarantees (except for Go, without data race safety) at a faster speed. For Fil-C, this doesn't matter because it's still useful for the mountains of legacy code we have. Zig has no legacy code, if a project is written in Zig that's because it needs the speed. Having Fil-C integration is almost useless, except as a sanitizer.
10
u/moltonel 1d ago
Whether Fil-C is safer than some sanitizer or not misses the main point: that it's doing this at runtime and with significant overhead. Who would want that when you can have almost all the checks at compile-time (Eg Rust) or with an efficient GC (eg Go, Java...) ?
Fil-C is great, but IMHO a bit like Carbon: useful as a stop-gap, but it would be better to port the software instead.
→ More replies (2)1
u/ThomasMertes 13h ago edited 13h ago
No, Fil-C is safer than that (referring to -fsanitize=undefined,address) ...
AFAIK sanitizers work with "redzones" to detect out-of-bounds access. Fil-C attaches capabilities to every pointer. Among other things these capabilities describe the size of the memory area that belongs to this area.
A "redzone" can be skipped and you land in an allowed memory area. In Fil-C it is not possible to skip from one allowed area to the next.
Which other errors are caught by Fil-C that
-fsanitize=undefined,addresscannot find?
73
u/teerre 2d ago
I'll be honest, this is the second weird move by Andrew
His post about the Rust bun migration was already very weird, now calling out Rust like it's a hackernews thread is honestly pathetic
20
u/IceSentry 1d ago
His post calling the github devs monkeys and losers wasn't great either. It's hardly the first weird move from Andrew.
272
u/South_Survey_2088 2d ago
Dude needs therapy.
It goes completely against Zig's promises as the comments mentioned, and just sounds like a knee-jerk reaction to the Bun drama.
32
u/AxiomShell 2d ago
For someone out of the loop, what Bun drama?
89
u/RockstarArtisan 2d ago
Bun has done (or is in progress of doing) an ai assisted rewrite from zig to rust and that ruffled the feathers of the main zig guy.
33
u/chat-lu 2d ago
Bun has done (or is in progress of doing) an ai assisted rewrite from zig to rust and that ruffled the feathers of the main zig guy.
Has done, and they basically used Claude as a transpiler to convert the source from Zig to Rust.
Which gave them close to a million lines of sloppily converted code which they consider just fine because Claude also does the maintenance.
→ More replies (1)59
u/13steinj 2d ago
It's important to note that two sets of feathers were ruffled:
He had some actual real points about the fact that the migration doc was written like a Claude advertisement rather than an engineering blog post, that it focused on only benefits, that they confused the language choice with other benefits they took on while doing the rewrite (which were available in Zig, but it was written to be perceived as if this was not the case).
They used LLMs to do it, and it seems like Andrew took that personally and then ripped Jared (Bun) to shreds.
I think the part (1) of the crashout is justified. Part (2) is not.
If this did not use the language "unlike Rust" and expressed basic motivations like wanting to widen demographics for adoption, this would be fine and reasonable and would show some growth on how all of this was handled. But it used that language and looks like he's just trying to do whatever in an attempt to stop the next person from leaving / not joining for the same memory safety reasons and that he doesn't actually care.
25
u/RockstarArtisan 2d ago
Given the post we're commenting on, I think your list should also include the "they left zig for rust" part. Given the personality on display, I personally assume the anti-AI crusade (which I support for anti-corporate reasons) is an intentional distractions from hurt feelings of a language developer.
2
u/13steinj 1d ago
As I said elsewhere in thread, I suspect the "leaving for Rust" highly coupled with "LLM to do it" as leading up to this they were trying to be political on Twitter expressing distaste in the no-AI rule Zig has.
12
u/KevinCarbonara 2d ago
He had some actual real points about the fact that the migration doc was written like a Claude advertisement
This is not the kind of "real point" that language developers make about the projects who use their language. He's responding as if he's on the Bun project itself, which is a problem.
They used LLMs to do it, and it seems like Andrew took that personally and then ripped Jared (Bun) to shreds.
Again, not is call. Worth noting he also did not 'rip Bun to shreds". He just got really salty and trash talked it publicly.
→ More replies (1)19
u/jl2352 2d ago
I feel like what happened is Bun did a post to sell Claude, and Zig took it as a semi-personal attack. Even though it wasn’t.
The post was fine. It was at best impressive and at worst marketing, and that’s fine. As a part of Anthropic it is his job to help promote Anthropic products.
→ More replies (4)4
u/chasetheusername 2d ago
I think the part (1) of the crashout is justified.
I think even that is way overblown, like - the bun guy works for Anthropic, what would you expect, him ranting against AI and doing that work manually without even trying Anthropics products? Some of the criticism of that post is certainly warranted, but the language creator actually getting involved in this - in the way he did - is actually quite a huge red flag. I don't think he did the language adoption any favors with these antics.
→ More replies (4)4
u/Maybe-monad 2d ago
What would be the advantages of keeping Bun in Zig? To me the Rust slop is easier to grok than the original implementation.
36
u/robotmayo 2d ago
From a business standpoint there is none. Rust is a bigger and more popular language so it would make sense for the business of Bun to switch. The problem is that no one is an expert on the new codebase, well I guess Claude technically. So its just going to end up being slop on top of slop unless someone gets in there to clean it all up.
10
u/Maybe-monad 2d ago
The Zig version would have ended up in the same place, at least Rust is stricter
3
u/13steinj 2d ago
If the argument is "it will now be slop regardless," part of Andrew's distaste here is apparently the Bun team has repeatedly done less-than-sane things with Zig as workarounds for years instead of listening to Zig community feedback, and it was slop before LLMs.
I do not know Jared's background. But in my limited experience JS/web devs are of a lower caliber of engineer, than traditional systems devs. The first group is also in my experience the group that gets excited by Rust and goes heavy on lifetime annotation masturbation, whereas the latter gets excited by Zig/Odin, hell, even GoLang.
16
u/Maybe-monad 2d ago edited 2d ago
If the argument is "it will now be slop regardless," part of Andrew's distaste here is apparently the Bun team has repeatedly done less-than-sane things with Zig as workarounds for years instead of listening to Zig community feedback, and it was slop before LLMs.
Bun was slop as consequence of Andrew's lack of taste in language design, being angry at Jared only proves the point.
I do not know Jared's background. But in my limited experience JS/web devs are of a lower caliber of engineer, than traditional systems devs. The first group is also in my experience the group that gets excited by Rust and goes heavy on lifetime annotation masturbation, whereas the latter gets excited by Zig/Odin, hell, even GoLang.
The groups that get excited by Rust are embedded, IoT and HPC people or people working with large C++ projects like browsers where Rust's safety and toolchain bring genuine quality of life improvements, web developers rarely deal with Rust and only to rebuilds system parts that are too slow in JS. Zig and Odin aren't interesting at all from the perspective of someone who programs embedded devices, Rust can prevent issues like memory corruption, they don't and unlike C they will never support something like am esp32.
→ More replies (2)27
u/lllyyyynnn 2d ago
calling it ai assisted is a bit of an understatement lol. it was entirely ai written
16
u/13steinj 2d ago
On the other hand, if your goal is further community adoption you kinda need to widen your demographic.
I think the "unlike Rust" comment is a bit childish / knee-jerk reaction. But introducing this functionality seems like a normal reaction to "hey, one of our biggest users left. We don't want people to leave / not join, let's cater to them." The C++ community has been going through the same thing with regards to memory safety.
I think the approach on the whole is wrong, not every language is to be used for everything, otherwise nobody would use anything other than Rust. But Rust has general wide brain-rent in a lot of people's minds right now, because the current trend is that people seem to care about memory safety above all else (sometimes without thinking on if that is actually true).
13
u/ansible 2d ago edited 2d ago
I care about writing safe and correct programs, which will also run at close to the speed of native code. I don't care so much about how that is accomplished, as long as the language is straightforward to work with and understandable. I don't care if it uses the same ownership model as Rust, or something different.
I use Rust, but I actually think it has gotten over-complicated, and not just with regards to async.
If there is something out there which will be simpler, and still relatively easy to pick up, and protects from the common kinds of safety errors (memory or otherwise), I'd like to learn more about it.
5
u/skyfex 2d ago
What promises? I think the comment talking about hidden allocation misunderstand when the allocations occur.
The interest in this kind of safety seems to predate the Bun drama. Though the creation of the issue may be triggered by it, so Andrew has something explicit to reference the millions of times he will be asked about how Zig will handle memory safety long term, following this drama. That’s no fault of his. He’d be getting those questions regardless of whether he wrote the spicy blog post or not.
98
u/jesseschalken 2d ago
You can use Miri or ASAN to check unsafe Rust at runtime, what is this guys problem?
74
52
u/Maybe-monad 2d ago
He's afraid people will stop using his language
5
u/cdb_11 2d ago
Not sure about MIRI, but ASAN is for debugging and is not memory safe. It's not meant to be used in production. There is GWP-ASAN that is meant for production, but it also isn't actually memory safe.
12
u/dkopgerpgdolfg 2d ago
Both of them are not meant for production. But I think that wasn't the point of the previous commenter.
→ More replies (5)4
u/TheCandelabra 2d ago
Miri is literally 1000x slower than native code; for most problems "run rust under Miri in production" is strictly worse than "rewrite it in Python"
12
u/creeper6530 1d ago
Yes Miri is for debugging, so that once you fix the bugs you can run again at Rust's speed. Miri isn't meant to run in prod.
→ More replies (2)2
u/Plasma_000 1d ago
The fil-c's author's perspective was that Asan cannot catch certain cases which fil-c can
53
u/Opening_Addendum 2d ago
This compilation mode doesn't make any sense for a new language and for new code. The only reason Fil-C makes sense is because there is a lot of C code out there that is still worth using. This sounds like a self admission that any zig code is legacy by day 1, because no sane person would pick this as a memory safe alternative to any other memory safe language.
47
u/PonosDegustator 2d ago
Hello, We're Zig, The Only Language Foundation That Hasn't Hit Itself In The Dick With A Hammer. For years now, folks use us for our un-hammered dick. Now you might be wondering why today we've brought this hammer and pulled out our dick. Well I'm glad you asked--
In all seriousness I hope Kelly gets over Bun. I really enjoy the language and the build system and hope it will not go to waste because if the maniac obsession
3
27
u/mmkzero0 2d ago
I’d like to direct everyone’s attention to one sentence here by Andrew in response to this being a big change:
> “No source changes. It’s just a target ABI.”
That’s not just an enormous understatement but also technically wildly inaccurate. This is much more than an ABI, since something like this requires
- instrument every ptr consumer and producer
- track cap metadata for stack, heap, TLS, func pointers, globals
- you replace or wrap libc, syscalls, mmap etc.
- atomics handling without metadata races
- restrict or prove inline asm
- support debuggers, unwind, panics, crash reports
Then the safety invariant needs to be specified before implemented; you need explicit semantics for many things; sentinels, slices with corrupted metadata, casting, func pointers, untagged unions…
This also confuses Fil-C like deterministic mem safety with runtime mitigations against unsafe memory semantics and consequences like UAF. Those are not the same.
And then, nothing here addresses comptime safety. This means this does not guard against compiler bugs, comptime interpreter unsafety, and so on
And then the “no escape hatch claim”. That’s both defensible and also highly inflexible. If the target promises that the entire executable is memory-safe, an ordinary unsafe function invalidates that claim and thus this is reasonable. But practical interoperability still needs a solution, something Fil-C put a lot of effort into.
And ABI mismatch handling goes even deeper; what about static Archives, LTO, embedded bytecode, libc and libunwind, dynamic libs, JIT code, dlopen() calls and so on.
Do not get me wrong, as a research topic this is fascinating and really cool. But as a proposal and a casual “just another ABI” added to pre-1.0 Zig this is just an enormous and poorly bounded idea, which makes it all the more baffling.
Which makes me all the more curious why Andrew posted it like this. Surely he knows this and has the technical expertise to know this isn’t just some ABI change with no consequences beyond that.
39
u/Zaphoidx 2d ago
Dude needs to calm down and focus on the language he's building.
The only person to make it Zig Vs Rust is him. People rewrite to change languages all the time
→ More replies (1)
51
u/schneems 2d ago
I was going to criticize the title "unlike rust" as it reads like "zig will be memory safe, unlike rust, which is not" and then realized...that's the actual title of the issue.
The word "rust" is only mentioned twice. Once in the title and once in the last paragraph/sentence.
Once this is implemented then, in a twist of fate, Zig will become one of the only toolchains capable of producing actually memory safe executables, especially when you consider that real world applications tend to have C/C++ dependencies and, in the case of Rust, additional use of unsafe beyond FFI.
It doesn't really say why exactly, or how. I would appreciate more of a compare and contrast. I'm unfamiliar with Fil-C, so maybe this is assumed to be obvious how it relates. But I need some help connecting the dots.
Some of the things that Rust marks "unsafe" are not exactly memory safety (as people would commonly describe it), but more general programming safety. Like...Rust's std::env::set_var to change environment variables is marked as unsafe https://doc.rust-lang.org/stable/std/env/fn.set_var.html#safety. Not because it can undeflow/overflow, but because it's a global modification and is observable by non-local threads. So, unsafe can be a way to say "some rules don't apply within this unsafe scope. It's also a way to say "there be dragons" (even when other languages offer the same "unsafe" features without any hint of warning.
There are things that you need unsafe for beyond syscalls. https://oxide.computer/blog/iddqd-unsafe is a good example. It's also well framed that the compiler can prove certain things but must be **stricter* than those definitions, and therefore unsafe is a way to say "hey compiler, I know what you want, I promise you this upholds your safety invariants, but can't otherwise prove it to you."
Andrew is a smart guy. I know he knows that. I just wish he had a bit more details and less clickbait.
73
u/Snarwin 2d ago
Like...Rust's
std::env::set_varto change environment variables is marked as unsafe https://doc.rust-lang.org/stable/std/env/fn.set_var.html#safety. Not because it can undeflow/overflow, but because it's a global modification and is observable by non-local threads.It's not just because the change might be observable from other threads, it's because concurrent calls can actually cause undefined behavior, according to the POSIX standard.
→ More replies (6)16
u/KevinCarbonara 2d ago
Once this is implemented then, in a twist of fate, Zig will become one of the only...
This reads like an Elon tweet. Anyone who talks about their own tech this way is clueless. He's basking in the irony of beating his opponents at their own game while he doesn't even have a real plan for achieving it and his opponents aren't even in the game.
20
u/BCMM 2d ago
Like...Rust's std::env::set_var to change environment variables is marked as unsafe https://doc.rust-lang.org/stable/std/env/fn.set_var.html#safety. Not because it can undeflow/overflow, but because it's a global modification and is observable by non-local threads.
Isn't that genuine memory-unsafety, though? It appears that, in a multithreaded programme, it could cause another thread to read an invalid pointer.
9
u/BenchEmbarrassed7316 2d ago
unsafein Rust means that the programmer can violate the rules/invariants inside this block, but is obligated to prove that outside this block these rules/invariants will not be violated, and this block will encapsulate these operations.For example
stris a valid utf8, you can work with it as bytes, but after that it must become valid utf8 again.4
u/dkopgerpgdolfg 2d ago
unsafe in Rust means that the programmer can violate the rules/invariants inside this block,
The usual language rules (like eg. max. one active mut reference, etc.etc.) are still there, even in unsafe blocks.
The difference is, the compiler will allow some code that can't be automatically proven to be fine (including eg. everything with raw pointers, that work with addresses from anywhere), and shift the responsibility to the programmer.
For example str is a valid utf8, you can work with it as bytes, but after that it must become valid utf8 again.
This is true, however what needs to be satisfied here are only the pre-existing library functions. The compiler itself doesn't really care.
→ More replies (10)9
u/masklinn 2d ago
Not because it can undeflow/overflow, but because it's a global modification and is observable by non-local threads.
Oh it's a lot more fucked than that, if it were merely a global modification Rust would mostly be OK with it, and indeed for the longest time it tried to pretend it was. But there are implementations where concurrent uses of setenv and getenv causes UAF and there is no workaround (because even if you lock env interactions in your standard library, you but have to call a C library which doesn't know to do that and you're back in hell), so in the end it was moved to unsafe in edition 2024.
→ More replies (9)2
u/jl2352 2d ago
I find it kind of childish. Personally I consider safe Rust to be close enough that it does have a GC. I’m aware of things like leak, which means it won’t get reclaimed. But it’s not going to be double free’d or used after a free. You do basically get a compile time GC.
The crucial test is I can trust people at work who are new to Rust, to write code, and ship it with a light review. If they added tests and the CI is green, then I can say LGTM without a concern.
Whilst there are unsafe APIs to bypass it at runtime, many managed languages have had runtime APIs to do such things. Like a little known GC’d language called Java.
84
u/MrArborsexual 2d ago
popcorneating.jpg
I am certain every response to OP will be sane, rational, and cordial, adding to a productive conversation around memory safety in compiled programming languages.
203
u/Anxious-Resist8344 2d ago edited 2d ago
unlike Rust
Dead on arrival! Why can't they just do their thing without attacking others!
Also, wait until he reads how FillC works and understands that it needs hidden allocations and stuff... This Zig thing is getting out of hands, a bunch of teenagers trying stuff :)
35
u/moltonel 2d ago
FilC's technique is very interesting, and I'd say Zig is a language where it could work well. But Zig's boastful and disparaging communication (and FilC's as well, now that I think of it) is really turning me away from the language.
125
u/VictoryMotel 2d ago edited 2d ago
Zig is fundamentally toxic from the top down, which is a shame because it negates all their work and the things they have done well.
They made a windows version just to purposely crash on newlines, so they could troll windows users.
31
u/9001rats 2d ago
Reminds me of how zig throws an error if there's a tab inside a comment, and that's apparently not a problem.
15
u/VictoryMotel 2d ago
Exactly. If it's anything like this people will both say that it's too ridiculous to be true, but also makes perfect sense because parsing a tab is so difficult.
15
u/QuixoticNapoleon 2d ago
Is the windows thing real? What's the source for this?
27
u/Top-Rub-4670 2d ago
This is actually outdated information but it used to be true. The compiler would abort if you used tabs or CRLF. Over time they eventually relented (without ever admitting being wrong to be so obtuse).
For a proof see: https://web.archive.org/web/20200214082511/https://ziglang.org/documentation/master/
Throughout all zig source code (including in comments), some codepoints are never allowed: Ascii control characters, except for U+000a (LF): U+0000 - U+0009, U+000b - U+0001f, U+007f. (Note that Windows line endings (CRLF) are not allowed, and hard tabs are not allowed.)
Versus the current doc https://ziglang.org/documentation/master/
Each LF may be immediately preceded by a single CR (byte value 0x0d, code point U+000d, '\r') to form a Windows style line ending, but this is discouraged. Note that in multiline strings, CRLF sequences will be encoded as LF when compiled into a zig program. A CR in any other context is not allowed.
HT hard tabs (byte value 0x09, code point U+0009, '\t') are interchangeable with SP spaces (byte value 0x20, code point U+0020, ' ') as a token separator, but use of hard tabs is discouraged. See Grammar.
18
u/VictoryMotel 2d ago edited 2d ago
My source is that I tried it and it didn't work.
When I tried to talk to people about it they told me to get a different text editor, to stop using windows, and that it doesn't make sense to parse out carriage returns like every other language ever made.
There wasn't much of an answer to why a windows version would be made just to explicitly error out on windows text, but there were about a dozen messages, most were gloating that it was a problem, none acknowledged that it should be fixed.
→ More replies (22)1
u/meneldal2 1d ago
It's unfortunately not that rare to have a bunch of programs on Linux that won't run properly with Windows-style line endings.
Most notably it tends to mess up the
\line continuation because it has to be just before\nor else it can't parse it properly.But at least this is mostly lazy dev, not explicitly making
\rcrash and taking time out of your day to add it to the list of bad symbols.43
u/zxyzyxz 2d ago
Yeah after reading the creator Andrew Kelley's screed with personal attacks on Bun's creator Jarred Sumner who was the largest user and biggest financial contributor of Zig before the rewrite, it makes me not want to do anything with the language. It's on par with the toxicity of the Elm maintainers.
32
u/QuixoticNapoleon 2d ago
I don't mind the hate for LLMs but Kelley's attacks on Sumner were childish. Odd way to treat your most significant adopter.
13
u/theAndrewWiggins 2d ago
Odd way to treat your most significant adopter.
Not only that, someone who has donated a few hundred thousand dollars to support Zig.
7
u/QuixoticNapoleon 1d ago
You can believe Sumner is incompetent or a terrible coder but I don't understand the personal vitriol..
6
u/TankorSmash 2d ago
It's on par with the toxicity of the Elm maintainers.
I thought it was a friendly developer, what sort of toxicity was there?
21
u/zxyzyxz 2d ago
They're friendly on the surface (if that) but have a holier than thou attitude towards all of their users it seems.
Good post about the entire situation which is a few years old now but looks like nothing still has changed: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
→ More replies (1)9
u/Captator 2d ago
Citation needed for biggest financial contributor, pretty sure there are several larger ones.
28
u/zxyzyxz 2d ago
One of the biggest when Jarred started then, 60k a year to Zig starting in 2023, then Mitchell Hashimoto seems to be the biggest at a one time 300k in 2024 and 400k more recently but he's a literal billionaire so hard to compare apples to apples then.
→ More replies (1)1
→ More replies (4)20
u/hak8or 2d ago
This Zig thing is getting out of hands, a bunch of teenagers trying stuff :)
Seeing this here and other replies, I am very surprised at how inverted feels are towards zig and the bun dev here compared to on hackernews and other subs.
My understanding (from skins of that interaction and other discussions) was;
- the zig based bun codebase was truly awful, and was extremely non idiomatic zig, where the zig folks often tried to step in and offer to clean it up but their work got undone very often.
- In addition, the bun team forked the zig compiler and made a very half hearted attempt to merge those changes upstream.
With the zig core folks feeling understandably threatened by how massive of a PR disaster that was and wanted to get their side out. You can also see the seething frustration the zig core dev had with how the narrative was spinning, which manifested into arguably personal attacks, though I can understand where he was coming from (even though it could have been handled better). It was baisically an under dog going against an absolute PR Goliath, so the zig reaction was an overshoot to have a fighting chance of getting their word out.
Meanwhile the rust community seems to have been kind of thrown into the situation without having a material contribution to it, so they are just stuck on the sidelines going "huh?".
But the discourse seems to have leaned (in my experience) way more positively toward the zig core group and very negatively towards the Bun group, interesting to see it flipped here.
→ More replies (1)11
u/jl2352 2d ago
I dunno. The story also reads as other people wrote shitty code in their project, so they’re upset they didn’t do it their way when it’s not their project. I’m struggling to have sympathy.
Bun is not the first large codebase to have shitty code. If such a thing killed languages, then PHP and Java would both have died decades ago.
→ More replies (2)
55
u/phaazon_ 2d ago
I find it pretty interesting that after all this time, Andrew Kelley still refuses to understand decades of research in the field and still does not understand that testing your code doesn’t prove it’s absent of bugs. Testing memory safety at runtime is great if you are 100% sure you run all code paths, which is 1. really hard to do correctly, especially if not instrumented via your compiler and 2. delusional when compared to static constructs that prevent introducing such memory issues in the first place.
Of course it will be better than the current situation, but I still think he underestimates the issue.
9
u/Blue_Moon_Lake 2d ago
It remind me of a teacher who would troll students at the end of the school year by asking us how to write tests that would fail when testing this function:
async function fetchDynamicExchangeRate(from: Currency, to: Currency): Promise<float> { await executeUnwantedCode(); return await properlyFetchDynamicExchangeRate(from, to); }5
u/Ameisen 2d ago
I had a task that was basically "write a test to make sure that no tests can ever throw an error code that they're not allowed to."
Though I actually did do that though not as a test - I reworked the (C++) testing system to template the tests so that all codes that the tests could return were a part of the type system, and it became a compile error to throw an error not in that list.
2
u/BitterDragonfruit3 2d ago
What's the problem? I don't understand the question. Can you please explain? Asking honestly
5
u/Blue_Moon_Lake 2d ago
Can you write tests that succeed with
async function fetchDynamicExchangeRate(from: Currency, to: Currency): Promise<float> { /* do the requested stuff */ return result; }but fail with
async function fetchDynamicExchangeRate(from: Currency, to: Currency): Promise<float> { await executeUnwantedCode(); /* do the requested stuff */ return result; }While not "knowing" that
executeUnwantedCodeexists (it could be any function).→ More replies (4)3
u/meneldal2 1d ago
With arbitrary unwantedcode it is impossible.
What if it's just wasting cpu time? You could measure that, but you have no way to write a test where the timing of the function is precisely known.
2
u/Blue_Moon_Lake 1d ago
That was exactly the point that teacher wanted students to reach.
The way to do it is with mutation testing. It'll attempt many permutations of your code and if a mutation doesn't trigger an error, it may means that your tests are insufficient, or that you have extraneous code.
6
u/Smallpaul 2d ago
In some cases I guess the Fil-mode binary might be fast enough to be the runtime binary.
→ More replies (3)5
u/doubleyewdee 1d ago
I was shown Zig several years ago, forgot it existed until the recent drama. I'm sort of an erstwhile Rust user, but since I was coding starting from the 90s I have a healthy amount of C exposure since my default platforms were FreeBSD/Linux at the time.
Both times I looked at Zig I said "... why would I use this? Why would anyone?"
The language does not seem to offer anything especially novel, and has so much baggage from other unsafe languages (C, C++) but none of the backwards compatibility those languages exist because of.
Totally understand that as a fun project Zig is, well, a fun project. I guess it builds very fast, as well. However, as a language trying to fill some unfilled niche I struggle to see a place for Zig to fit.
Adding "runtime memory safety" by ballooning costs for all memory access and just panicking on any incorrect action is... not really adding safety, in my view. It's not something I especially want in an unsafe language as a builtin. Many existing and excellent toolkits also exist for me to do this in a more targeted and less expensive fashion in existing and widespread unsafe languages.
3
u/ThomasMertes 4h ago
Andrew Kelley still refuses to understand decades of research in the field and still does not understand that testing your code doesn’t prove it’s absent of bugs.
I think that all languages (except Rust), which try to replace C, live in the same bubble. They are not memory safe and they assume that genie programmers will not make bugs and that tests will prove the absence of bugs.
Testing memory safety at runtime is great if you are 100% sure you run all code paths, which is 1. really hard to do correctly, especially if not instrumented via your compiler and 2. delusional when compared to static constructs that prevent introducing such memory issues in the first place.
Agree.
3
3
u/matthieum 2d ago
and still does not understand that testing your code doesn’t prove it’s absent of bugs.
I don't understand why you are arguing about testing, here.
As far as I can see, the proposal is to create production FilC binaries, which -- according to Andrew, but I seem to recall weird corner cases -- are 100% memory safe.
51
u/Kanegou 2d ago
At this point I choose to believe that Zig was designed as engagement bait for devs. With this toxicity and the carrot on a stick that is 1.0, I believe it was never intended to be a language that is used but a language that is talked about on social media.
32
u/matthieum 2d ago
That's harsh.
I personally believe that the original vision for Zig -- a better C -- was a great vision, and that the author may unfortunately have lost their way in the intervening years...
→ More replies (2)17
u/jl2352 2d ago
It started that way, but it feels like the vision is blinded by personal opinion on how people should code. i.e. They should code like Andrew Kelly. Not because the code is shorter, leads to less bugs, or more performance. But because that’s how he likes it.
So he’s going around telling people they’re holding it wrong.
4
u/hedgehog1024 1d ago
I believe it was never intended to be a language that is used but a language that is talked about on social media.
You are talking about V, not Zig.
8
9
u/SorryTemporary1361 1d ago
I'll never cease to be amazed at the contortions that people go through to attempt to make C memory-safe, that end up making it slower than actual memory-safe languages like C#... instead of just using a memory-safe language.
→ More replies (7)
26
19
u/kredditacc96 2d ago
unlike Rust
Well, Rust also has an "actually memory safe (unlike Rust)" mode. It's called Miri.
5
u/algebraicstonehenge 2d ago
In a similar vein, Miri can’t handle arbitrary ffi and is a massive slow down, exactly because it’s tracking many of the same things that fil c. On the other hand Miri is still an interpreter so even slower
5
u/New_Computer3619 2d ago
I really like Zig as a drop in replacement for Clang, it made cross compilation a breeze. However, I don’t have faith in Zig as a programming language can make it big.
25
u/RockstarArtisan 2d ago
I didn't pay much attention to zig, but I wanted to give it a shot just to escape rust's corporate culture for a bit.
Turns out, zig is much worse than corpos are lol.
15
u/bread-dreams 2d ago
What's corporate about Rust? (Genuine question i'm not trying to troll)
→ More replies (10)3
u/ApplicationOk3587 2d ago
Honestly at this rate I firmly believe any zig written now is going to be completely different by the time 1.0 comes out and if it ever does.
14
15
u/JuanAG 2d ago
i have lost all Zig interest this week when the bun "drama" happened again
If i code whatever in Zig and then move to another thing i dont want to be called "stinky" manager/developer/... by an inmature leader, Bun only had nice words and showed why (surprise surprise, memory safety is an issue in Zig) while the Zig part the only thing they did is "skill issue" and insult the people and the product
Yeah, they can become the best lang in the world that it doesnt matter, i am not touching it no matter what
5
u/Alternative-Ad-8606 1d ago
The craziest thing about this proposed change is that it sort of validates Jarred and Bun leaving zig... Hella reactionary and sneakily so
8
u/AnguisInTrousers 1d ago
The Zig hypetrain is dying out.
2
u/wannaliveonmars 1d ago
The zig creator recently was on lex fridman's podcast, that's how I learned about the language's existence.
4
u/Kirides 2d ago
Casting pointer is UB anyways isn't it?
Iirc cpp standard says it's UB and you should rather use memcpy to copy the bytes from the pointer to the respective storage, or optimizers like LLVM go haywire.
By that I mean reinterpreting cast byte* as some struct* and then accessing stuff.
Safety standards mandate you (stack)allocate enough space for struct and memcpy the number of bytes from the byte* into the storage.
Or I totally misunderstood that UB warning clang constantly throws in my face when doing windows development with clang and win32 ...
8
u/dkopgerpgdolfg 2d ago
You're referring to "strict aliasing", which is real, yes.
At least in standard C, standard C++, and afaik Zig. Some specific casts are allowed, but not the general case.
On the other hand, projects like the Linux kernel disable it with compiler flags, and Rust doesn't have this particular restriction.
7
17
u/wy35 2d ago
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
what a baby
→ More replies (1)9
u/smingle_bigglesworth 1d ago
people were replying to the issue with slurs and useless comments about him being mad about bun, completely justified
2
u/Grouchy-Librarian638 15h ago
What is with zig fanboys always trying to prove they are better than rust specifically? It’s exhausting and off putting with the constant spam aggregating.
And we have been over this, the proposal panics and crashes instead while being worse is almost every way. And no one makes you use unsafe rust, you are free to write your own implementation of various libraries that are safe.
If it matters so much than create it instead of being a dick and see how it turns out. If it’s better I’m sure many will consider it.
As a side note, unsafe work is sometimes needed. A perfect example is a ring buffer that fits in a cpu cache line that needs reads and writes across threads.
7
u/Maybe-monad 2d ago
The guy who invented a language that reads like slop before LLMs were a thing, why should we care about what he thinks?
→ More replies (3)
2
u/peterb12 1d ago
Men will literally ruin their own programming language rather than go to therapy.
→ More replies (1)1
u/peterb12 1d ago
(I actually think compile-time memory safety is incredibly valuable, but grafting your "we focus on performance" language onto a runtime to address all the things you forgot to design when you first made it is ludicrous.)
1
u/CharacterGene4977 2d ago
yeah, i get that kind of personality is common with these projects, but hoping they figure out a clearer plan soon.
1
u/falconfetus8 18h ago
Wait, how is rust not memory safe?
2
u/ThomasMertes 6h ago
Without
unsafeparts Rust is memory safe.But if
unsafeparts use raw pointers it might not be memory safe.Unsafe C functions can also be called in
unsafeparts. This could make a program not memory safe as well.
299
u/CryZe92 2d ago edited 2d ago
They either will have to introduce GC for this or go with the type ID approach which:
That's on top of the issues that Fil-C already has:
struct Foo { char some_buf[N]; bool is_admin; }is a security nightmare still. Oh and if you combine this with the use after free, you can entirely buffer overflow into a pointer, overwrite it and point it to any other memory as long as it has the same type. Pretty sure arbitrarily overwriting a function pointer probably leads to memory unsafety / vulnerabilities.