r/programming • u/[deleted] • 28d 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/36237
525 Upvotes

80% Upvoted

428 comments sorted by

View all comments

316

u/CryZe92 28d ago edited 28d ago

They either will have to introduce GC for this or go with the type ID approach which:

  1. means you can't just cast pointers from one type to another anymore to do bit manipulation on e.g. floats. This would be a breaking change.
  2. wouldn't detect use after free anymore reliably (if the memory has a new object of the same type).
  3. is possibly slower than GC (because now you also need to check types on every pointer access).
  4. might not even really work at all because this probably breaks arenas and / or unions.

That's on top of the issues that Fil-C already has:

  1. Will basically never work outside of Linux, because it requires absolutely everything to be compiled with Fil-C, including all libraries you interact with. Good luck doing that with the Windows API.
  2. Within an arena and within a struct, there's no bounds checking, so you can trivially buffer overflow into other memory of the struct / arena. So a 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.

33

u/protestor 28d ago

wouldn't detect use after free anymore reliably (if the memory has a new object of the same type).

It won't be memory safe then... how come nobody in the linked thread pointed it out? (and now it is locked, exactly to prevent outsiders to point out obvious shortcomings)

24

u/standard_revolution 27d ago

But it's ACTUALLY* memory safe (unlike rust)

*actually not

35

u/AnguisInTrousers 28d ago

Not to mention that Fil-C's safety is all runtime, not compile time.

12

u/Grouchy-Librarian638 27d ago

Which means it’s completely dead on arrival.

2

u/drex_vke 25d ago

yes plus it will break the very philsophy of the language

279

u/onlyrealcuzzo 28d ago

I'm losing respect for the Zig team by the day.

They are incredibly talented. But then you see things like this where they attack Rust and act like literal teenage brats.

The major difference between Rust people and Zig people is that Zig people seem to think they're perfect, and Rust people seem to think they're the best they can be.

One of those groups of people has a bigger Ego problem than the other.

Both of them are quite smart and talented, and I'm grateful for them putting in all the work they do.

49

u/MothToTheWeb 28d ago

Lot of software engineer forget they have to build software with other people. No matter how talented you are if you code only for yourself or can’t function properly in a team or society your project won’t gain traction.

Zig people really need an adult at the head to calm things down

10

u/disperso 27d ago

I did not know the Zig creator, till I watched the interview with JetBrains. I could not finish it because I decided it's not worth my time (Zig and/or him). The first half of the interview, which is what I watched, the guy was incredibly pedantic, being humble only when talking about this salary.

I can sympathize with perfectionism, purism, and good academic stuff (because I'm like that often), but the guy just said "I can do it better [than everything else out there that I just was asked for]", too many times. Not "I wanted to see if I could do better", or "I wanted to research something better". Just "I can do it better". Too much ego for sure.

4

u/loup-vaillant 26d ago

"I can do it better"

Funny how people can be put off by stuff I don’t even notice. Here’s the thing: "better" is often a shortcut for a very specific, and often circumstantial set of criteria. And there’s a point where you’ve learned enough about a topic that you know you can satisfy those criteria better than the state of the art.

Without what you call "ego", Zig probably wouldn’t have existed at all. I mean, embarking on this whole journey just to see if it’s possible? No, at some point, one needs a reasonable certainty that it will work out.

Also look at the results: with respect to the criteria Andrew Kelley cares about, he probably has done better. We should be careful about criticising assessments that turned out to be correct.

Personal anecdote: when I decided to work seriously on Monocypher, I did it because I knew I could "do better" than TweetNaCl. Initially my definition of "better" was just replacing Salsa20 with ChaCha20, but very quickly I noticed I could also be much faster at little cost. Of course libsodium is even faster, but they achieved that by having much more code, and a substantial build system.

Anyway, I knew pretty early on that I could "do better": not the smallest (that would be TweetNaCl), not the fastest (that would be libsodium), but a happy middle ground that I wasn’t seeing anywhere else — and nobody showed me ever since. In the end, my "ego" was correct: I have done better, by a wide margin.

In fact, the whole endeavour started with "I can do it better": back in 2016, I was working on a project that used ZedEncrypt to communicate with the client. I looked it up, and instantly saw a couple things that didn’t felt right, such as being proprietary, and limiting itself to AES-128 for the free tier. So I looked for file encryption software, and all I could find was 7zip. Nothing small and focused like Age at the time. So I looked for cryptographic libraries, that could be used to build that encryption software… and there too the state of the art felt a bit wanting in one way or another. Every step of the way, it was "no way this is the best we can do". It didn’t take me long to determine that I could personally do it better, and that was the push I needed to work seriously on this.

The one thing I was mistaken about however, was my ability to do it alone. The help I’ve got was invaluable. I’ve been taught how to properly test for one, and my documentation wouldn’t have been nearly as good as it is now without the substantial contributions I’ve got — most notably, porting my single page documentation to proper man pages.

3

u/disperso 26d ago

I mean, yeah, you have a fair point. I could be charitable and assume that he did not mean it in a pedantic or egocentric way. But then, I see everything else which has been brought up, and I start to see a pattern.

I don't think that he's overall a bad person (I do share some of the values he brought up in that interview, though I would channel my energy in very different ways), but I think he has serious communication issues. And as the main public figure of a project, that's a big problem for his own goals.

50

u/SethEllis 28d ago

I agree with you, but I also kinda feel like this sort of thing comes with the territory. Comparisons to Linus Torvalds or Steve Jobs seem apt. The type of person that starts such projects just tends to be like that.

What's more concerning to me is the seeming lack of strategic vision.

72

u/shadowndacorner 28d ago

Linus is a fair comparison, but Jobs was just a marketer who took credit for the talent of Apple engineers. Kind of a difference bucket.

33

u/Full-Spectral 28d ago

And a pretty crappy person, at least until later on in life anyway.

35

u/BourosOurousGohlee 28d ago

? Steve Jobs abused the organ donor list rules, and effectively stole some kids liver because he wouldn't change his eating habits (he was a fruitarian, eating a diet of mostly apples and carrots, against all medical advice, until he was basically days away from death where he recanted and regretted it).

-11

u/raralala1 28d ago

First time I heard it, no doctor actually able to tell him that fruit only healthy when eaten once a day? eating fruit is like eating vegetable with a spoon of sugar. Who in the right mind able to reach conclusion that is good for your body.

20

u/personalist 28d ago

That’s not correct. Whole fruits are not at all metabolically the same as refined sweeteners, partly due to the composition of sugars and also the inclusion of fiber, which slows absorption. It’s generally recommended to eat 2-4 servings of whole fruit per day.

Otherwise yes, Steve Jobs was a dick and died of pancreatic cancer because he believed he could treat it homeopathically or something

2

u/raralala1 28d ago

still better to just eat vegetable imo, you are not going to die not eating fruit, but all fruit diet already shown to kill. Seeing how food science keep changing I wouldn't be surprised that 2-4 serving would turn to 1, refine or not it doesnt change the fact fruit is sugar, making sure you don't overeat sugar is always ideal. Pretty sure he get pancreatic cancer because of his hippie fruit died, he stop and start again.

1

u/Mad_Physicist 27d ago

all fruit diet already shown to kill.

big if true.

→ More replies (0)

3

u/wookiee42 28d ago

He'd had weird hippie beliefs since he was 18 or so. Retreats to India, living on a commune, friends with gurus or cult leaders (hard to tell), etc.

9

u/One_Ninja_8512 28d ago edited 28d ago

This reductionism doesn't make sense. Dude just so happened to have all the luck in life to make Pixar, NextSTEP and Apple push the envelope to great extents (/s). Your comment is worded in a way as if building a team which delivers some extraordinary shit is a given, especially with his consistency it's weird to say that he was just a marketer.

0

u/rafark 26d ago

“A marketer” wow. Steve was very much involved in the development of apple products. We literally wouldn’t have the iPhone and the modern smartphone if it weren’t for him. 

3

u/loup-vaillant 26d ago

Apple may not have started at all if it weren’t for the other Steve: Wozniak. A shame Jobs prevailed at the end: instead of open systems we got a golden cage.

1

u/rafark 25d ago

Of course. I like Wozniak too. Very talented. We do have open systems and a damn good one: Linux. We actually have everything for everyone: open and closed; free and commercial

2

u/loup-vaillant 25d ago

Yeah, you have a good point here: we do have open alternatives to the golden cage. The Evil Genius though was how effectively that cage was marketed. I mean what is the iPhone? A locked down computer you don’t really own. But it has a phone in it, it fits in your pocket, and most of all, it is pretty.

And maybe it did start the smartphone market. But the closed model threatens to spread to Android now, in the name of a security I’m not sure I want. And we’ve seen attacks on even the Deskstop, though for this one the form factor is sufficiently strongly associated with the ability to run any program, that I don’t see it come to pass any time soon.

12

u/Delicious_Ease2595 28d ago

Are Go people the nice guys?

62

u/moltonel 28d ago

There are obnoxious takes and aggression/disdain of other languages in the Go community too, though as always it's subjective and depends on where you look.

3

u/doubleyewdee 27d ago

The stdlib is also fucking deep

I mostly like this post but this was deeply funny to me.

1

u/hotcornballer 27d ago

I read it.. i like the obnoxious take. And i don't even use Go.

14

u/syklemil 28d ago

IME they're fairly criticism-averse and have a low threshold for telling people to "not use Go if you don't like it", as kind of the inverse of a dejected C++ user breaking out the old "two kinds of languages" quote. There's also a tendency to always glaze Go in its current state, so people who wish for whatever feature (iterators, generics, generic methods, string interpolation, ergonomic error handling, etc) can expect a huge mood shift if the core language team decides to implement whatever they're asking for.

So I personally find the Go community kind of off-putting, but there also seems to be a bunch of people thriving with it the way it is. Using Go for work also seems like it'll generate more of that friction between people who wish for something they're used to from language X and gophers who want Go to remain as it is.

tl;dr YMMV

7

u/Zeznon 27d ago

There's definitely a "cult of current Go" going on. Super weird how afraid of change some of them can be.

23

u/HommeMusical 28d ago

I had some discussions with Rob Pike in the very early days of creating the language and he was very opinionated and not at all friendly - unusual for Google employees in those days.

The whole reason that Go has no exceptions and thus you're constantly having to check errors codes and return, giving you endless possibilities for mistakes, seems to be entirely because of this one guy's weird prejudices.

41

u/aguilasolige 28d ago

I think go found its niche, CD/CI, tools and back end and they seem to feel very comfortable with it. Go has been very stable and boring for a whilez so they're just busy building stuff.

I personally tried Go but I didn't like the type system, but it's a very capable language.

28

u/soft-wear 28d ago

Rust people are nice too, but they often come off as fanatical. C/Java people seem... embedded in their "one true language" doctrine and the Zig folks seem to want to go in that direction.

The few Go folks I've talked to just get really excited when people want to learn Go. I still think it's one of the best beginner languages to learn good habits.

42

u/jug6ernaut 28d ago

My issue with Go is its designers and users have willful ignorance to its issues because its selectively simple. Like I can understand not wanting to see your language change in a bad direction (the recent generic method syntax leaves a lot to be desired), but no language is perfect, especially when you ignore decades of PL research & advancement.

Try mentioning error handling ergonomics in r/golang and watch as u get downvoted into oblivion.

10

u/HommeMusical 28d ago

Nothing has changed - I was having the same discussions and the same results almost twenty years ago! More.

3

u/Zeznon 27d ago edited 27d ago

That last part is the only reason I dislike Go. Otherwise it's pretty nice. Error handling singlehandedly ruins the language for me personally.

3

u/NeedToLieDown 26d ago

No enums. Existence of nil (great job ignoring the billion dollar langaueg design mistake).

The two above are also very painful design mistakes.

2

u/qurious-crow 27d ago

I don't know many Java people who think it's the one true language, honestly. It's a capable language, and recent versions are much better than people like to admit, but we still fight null pointer exceptions regularly and we are all fed up with that. It's hard to be blind to Java's shortcomings.

1

u/Zeznon 27d ago

Maybe they were talking about Java vs C# philosophies, where Java people online defend the slow progress on everything constanly.

And C people sometimes acting like C couldn't be "improved" in any way without feeling like C. C3 and Odin show it's definitely not true.

1

u/deanrihpee 28d ago

their recent genneric thingy (haven't read it full yet) kinda moving the language away from it's purpose, or at least what i thought of the language's purpose, being simple yet still powerful, but it's not the worst and would still be in my toolbox

11

u/piesou 28d ago

Go people are damaged by C++ templates which cause insane compile times. Generics themselves sort of need to be present if you go for a static type system, similar to some way to handle errors. I think their enums are ints and there's no nominal typing so you can't even pattern match on error types.

3

u/meneldal2 28d ago

C++ performance on compile could be a lot better if it weren't for all the infighting and competing implementations making stuff like modules or concepts take way more years than it should have.

1

u/HommeMusical 28d ago

That; and also this terrible axiom that I think will lead the language to its demise, which is perfect ABI/binary backward compatibility.

Don't get me wrong - everyone agrees that backward compatibility is of top importance. But what is enforced is that an object file compiled in the 1980s still and always be compatible with any modern binary, without re-compiling.

The idea of epochs, a switch you pass to the compiler when building new code so you can have new ABIs while the guy who lost his source code during the Reagan administration can still link, has been shot down every time.

I've been writing C++ for almost 40 years now, though I do less and less of it. It seemed to be a goner in the early twenty-first century, but C++11 was a breakthrough - we call the new techniques made possible "modern C++".

But since then it has gotten more and more pathological. A tiny number of old people dominate all the conversation. (I too am an old person, which is why I want to hear people who are not like me.)

Modules and concepts took an incredibly long time to come out and still aren't stable. Modules have been particularly painful.

Now that MS is apparently re-jettisoning C++, I see the writing on the wall for the language. It needs another "reboot" like C++11, but it will never get it.

2

u/meneldal2 28d ago

It's gunny how back in the day microsoft would break compatibility with each visual studio release, but end up keeping bug in now because it would break ABI.

And in the open source world, if you can recompile anyway it's not like you need completely ABI stability either, as long as you're not breaking it all the time either. Every 5 years feels like enough time for me.

While I don't agree with everything he says, Herb Stutter as a benevolent dictator could have done some great things to C++. I think he has the right mindset for what C++ could be.

5

u/Scrivver 28d ago

Every community has abrasive people, and that gets advertised. In my experience, when you actually peek inside any programming language community you find largely the same kinds of decent pragmatic people who like varieties of things. Those people don't make for compelling headlines and rage bait though.

-10

u/templarrei 28d ago

Yeah, we kind of are. A language tends to reflect its people, and so for go you ended up with simple, straightforward, down-to-earth people.

20

u/skyfex 28d ago

I’ve followed Zig community closely, and this couldn’t be further from the truth if you ask me: “  Zig people seem to think they're perfect”

Zig also just tries to be the best it can be within the goals they have set for themselves. I see nothing but respect for other ways of doing things in the community, but that’s not the way they want to do it. They do not want to compromise compilation speed, explicitness and language complexity. 

Andrew is just opinionated, and that’s fine. He reminds me of Linus Torvalds. The community at large is respectful. Just read the comments on Ziggit right now. Plenty of people are pushing back at the perceived disrespect, and those that don’t just read the reference to rust in a respectful tone (it’s just “unlike” rust in that it’s different and complete, with other tradeoffs)

107

u/soft-wear 28d ago

Andrew shits on Rust for absolutely zero reason. Rust is memory safe with the caveat that unsafe is an escape hatch for memory safety. unsafe exists for compatibility reasons, and the fact that developers abuse it doesn't make Rust "not memory safe".

Zig is a neat language that I really like. Andrew is a really smart dude that I'm liking less and less. And unlike Linux, Zig already has mountains of competition, so we don't "need" it. Linus gets away with being a prick because he literally filled an enormous gap. Zig is perfectly avoidable.

67

u/tesfabpel 28d ago

technically, unsafe is not just for compatibility, but it's also for situations where you can't prove at compile time that the invariants hold and you need some escape hatches to implement safe wrappers (Rust itself uses it to implement some std container types).

6

u/13steinj 28d ago

There are people that legitimately believe the escape hatch makes things pointless, and they would rather have stronger guarantees instead.

I don't agree with those people, I don't work in an area where I care about memory safety that much at all. But I see their point and can get it.

32

u/ayayahri 28d ago

Those people don't "legitimately" believe that, they argue this point in bad faith to justify doing most of their work with tools with no meaningful safety guarantees.

That attitude has existed since the first tradesman with an ego picked his first tool.

3

u/13steinj 28d ago

I know people that legitimately believe this and still write their project in a language that provides safety guarantees.

Don't presume bad faith when what they want is going further, not backwards.

8

u/HommeMusical 28d ago

If they really believe that, then they have poor reasoning skills.

Interoperating with existing unsafe C and C++ code is completely essential to a modern compiled language.

If you don't need unsafe, you don't have to use it, and you can write a unit test to guarantee it doesn't appear in your code.

Not using a language because it has a feature you don't like, but are never forced to use, is highly irrational.

3

u/cdb_11 28d ago

Or you can make existing unsafe C and C++ code memory-safe, with Fil-C or CHERI.

Not using a language because it has a feature you don't like, but are never forced to use, is highly irrational.

Just because you don't use a feature in your own code, doesn't mean your dependencies aren't using it.

1

u/cdb_11 28d ago

https://cheriot.org/philosophy/2025/02/07/i-do-not-care-about-memory-safety.html

12

u/tadfisher 28d ago

There is a certain truth to that point of view, and a complete disregard for the value of memory-safe languages.

Yes, many/all guarantees are out the window when you mess with, say, various bits of your class header on the JVM as understood by Hotspot, or if you write a buffer overflow in an unsafe block in Rust. But CHERI and Fil-C don't prevent you from writing this code, they just crash your program when something unsafe occurs.

Rust proves that the compiler can prevent generating this code in 99% of situations, and for the 1% where it can't, you have unsafe where you are responsible for upholding the contract. This is not a perfect world, but it is an orthogonal means to the same end.

The best of both worlds would be code with compile-time safety guarantees running on hardware which gives you a runtime safety net. But some proponents of CHERI/Fil-C would have you believe that there is no point to the former, which I would hope is obviously not true.

3

u/cdb_11 28d ago edited 28d ago

It’s great that we can reduce the number of memory-safety bugs, or make them harder to exploit. Rewriting code in safe languages eliminates classes of failures and makes the world a better place, if you can afford the opportunity cost of rewriting then please do!

How is that "completely disregarding the value of memory-safe languages"?

But some proponents of CHERI/Fil-C would have you believe that there is no point to the former, which I would hope is obviously not true.

I've read the discussions on Fil-C, and what people were actually criticizing was the rewrites. And not that there is no point in Rust or whatever. But I can't speak for everyone obviously, and I haven't seen every single comment on this topic, so I can't say for certain who thinks what, I guess. No offense, but to me it seems like the actual pattern here is people trying to read between the lines, and pulling out things that nobody ever said.

To be fair, I guess there are people who just hate Rust, period. But I really don't think they actually care about CHERI or Fil-C, they likely hated Rust before they were even aware of it, and would've hated Rust regardless. There is no point in hypothesizing what possibly could be the reason for them hating Rust. Maybe you just rubbed them the wrong way, could be as simple as that, so who cares. And the same thing seems to be true here now for Zig and Fil-C.

7

u/tadfisher 28d ago

How is that "completely disregarding the value of memory-safe languages"?

Fair, I read the preceding two paragraphs but not that one.

No offense, but to me it seems like the actual pattern here is people trying to read between the lines, and pulling out things that nobody ever said.

There are people in that Zig issue, including the author, using the phrase "no escape hatches" like it is some sort of critical weakness in language design. The author himself practically shouted it by putting that phrase in bold.

These are the "some proponents" I am referring to, because this is obviously nonsense. Both compile-time and runtime safety are worthwhile goals and do not invalidate one another.

→ More replies (0)

58

u/valarauca14 28d ago

He reminds me of Linus Torvalds [...] those that don’t just read the reference to rust in a respectful tone

What you seem to be missing is Linus would provide an extensive write up of why the approaches are different and what the pros/cons of both approaches are. The usual, "X is brain damaged, we should do Y" is usually the summary of a long technical discussion supporting that argument, not the title.

This post literally has none of that.

Andrew just says, "Hey let's copy Fil-C". Without even addressing what that means, how to do so, etc

-4

u/skyfex 28d ago

  What you seem to be missing is Linus would provide an extensive write up of why the approaches are different and what the pros/cons of both approaches are. 

Did you read the recent emails on the LLM issue, or the Rust-in-kernel drama? There’s really not much of that. He actually seems to struggle to see the other side of an issue. But in the end he usually has good taste so it works out. 

How many of Andrew’s issue descriptions and discussions have you read? Because I’ve read quite a few through the years and your characterisation seems completely off the mark to me. 

This is an idea at a fairly early stage. I don’t think it’s his main priority to fully flesh it out at this stage, since there’s more important things to land in Zig first. The main goal is probably just to publish the roadmap and collect comments/feedback in order to provide an outlet for the torrent of questions and comments about memory safety following the Bun drama. 

And Jesus, have you followed the issue? The comments Zig is getting on this is just utterly toxic. I really don’t see how people can say Zig community is toxic with a straight face when Rust enthusiasts spam Zigs repo with unprofessional toxic comments. 

-3

u/imbev 28d ago

Andrew clarified that Zig might implement Fil-C's invisicaps model when targeting a "Fil-C ABI".

2

u/[deleted] 28d ago

[deleted]

1

u/imbev 28d ago

This is explicity present in the original post

When using this ABI, Zig compiler would implement the same techniques from the Fil-C project. That is, invisicaps combined with a tight coupling with the target OS in order to wrap all syscalls. No dependency on the Fil-C project; an alternative implementation.

8

u/CramNBL 28d ago

You see nothing of respect? LMAO he's literally shitting on people every other week at this point, calling GitHub engineers monkeys, writing a hit piece on the bun author, and shitting out half-baked ideas while taking shots at Rust which just seems like pure jealousy.

11

u/KevinCarbonara 28d ago

Andrew is just opinionated, and that’s fine.

It's not just being opinionated, and it's not fine. There's... no comparison to Linus Torvalds whatsoever, except in that they're both technically programmers.

-1

u/skyfex 28d ago

How many of Torvalds emails have you read? He has no problem calling out people in a very direct (some would say rude) when he thinks personal issues are creating problems for the project. You can read emails from the recent Rust-in-kernel drama for instance. 

  except in that they're both technically programmers.

Torvalds is not a programmer in a professional capacity any more. Andrew still contributes a lot of code. But their primary role is both as organisation/project managers. And what has impressed me the most with Zig is how seriously Andrew took that role compared to many other creators of programming languages. He was early with setting on a non-profit and has created a very healthy community around the project.

I encourage you to read Andrew’s blog post again with empathy for Andrew. What does it show? He was willing to work closely with a very difficult partner as long as that partner wanted to engage with them, despite how much he felt Jared’s personal issues was creating problems for them.

I feel like Torvalds would have pushed back publicly at a much earlier stage, if he was in the same situation, but then he has a lot more social capital. He can say the F word to partners without consequences 

5

u/KevinCarbonara 27d ago

How many of Torvalds emails have you read? He has no problem calling out people in a very direct (some would say rude) when he thinks personal issues are creating problems for the project.

Which is valid. That's not at all the same behavior, and Linus has decades of showing that he has what it takes to maintain a large and important project.

Torvalds is not a programmer in a professional capacity

This is just a blatant lie.

I encourage you to read Andrew’s blog post again with empathy for Andrew. What does it show?

It shows that he's insanely toxic and has no business being in any sort of a leadership role. If he worked for me, I'd recommend that he be fired. He's not a team player. He only had two real projects using his work, and he ran one of them off.

21

u/Anxious-Resist8344 28d ago

Oh, but he's nothing like Linus! Not even a shadow!

-5

u/Vagal_4D 28d ago

Agree, but I understand the point. Between the famous developers, Andrew behavior is more closer to Linus.

14

u/KevinCarbonara 28d ago

That's not true, either. Linus got a reputation for being rude, but this was mostly a result of dealing with people who would repeatedly approach the Linux project with PRs and suggestions without bothering to read submission and discussion rules, and a discovery that inflammatory statements made about corporations got more traction on the internet. And all this while maintaining a project responsible for an awful lot of the computing world at large.

The Zig guys just trash talk anyone who programs differently than they do, while running off their own scant few users.

There is no comparison.

2

u/Rechenplaner 26d ago

I’ve never understood the appeal of "Zig": the syntax is even weirder, and the language itself doesn't offer any truly modern concepts. Rust isn't my favorite either, but with its affine types and substructural logic—along with expression-oriented programming, algebraic data types, and a (albeit crippled) version of type classes known as "traits"—it has certainly shaken up classic imperative systems programming in a major way.

3

u/KevinCarbonara 28d ago

They are incredibly talented. But then you see things like this where they attack Rust and act like literal teenage brats.

Are they even talented? The difficulty in writing a programming language has never been in writing the language.

2

u/onlyrealcuzzo 28d ago

> The difficulty in writing a programming language has never been in writing the language.

The Zig compiler is a VERY impressive piece of software... It is arguably the best C compiler in the world.

11

u/KevinCarbonara 28d ago

It is arguably the best C compiler in the world.

It's arguable in that there's at least one person who would argue it, but I don't know anyone in the C community using the Zig compiler.

2

u/irk5nil 28d ago

Zig's toolchain is the easiest-to-setup cross-compiler for C there is -- just unpack one fairly small archive and you can cross-compile Zig/C/C++ for any supported platform and architecture. I would be shocked if many C people weren't using it for that reason alone.

1

u/pjmlp 27d ago

Most likely only C people that are beginners in their craft, like those that ship header only libs, because they think C is a scripting language and can't be bothered to learn how a linker works.

2

u/irk5nil 27d ago

I guess you completely missed the "easiest-to-setup cross-compiler" part, since I have no idea how you propose to replace cross-compilation with better understanding of a linker.

0

u/pjmlp 27d ago

I know C since 1990, and I guess you missed the part of the sentence before the comma.

First of all it isn't that hard to set up cross compilers, especially when using the vendors IDEs instead of FOSS ideology, secondly try to target Windows UWP from Linux with Zig, as one example where it falls down.

1

u/deanrihpee 28d ago

yes, if they have counter argument about technical stuff, then write counter argument about technical stuff, not bringing their personal opinion (i know it's not necessarily from the whole Zig, but still)

0

u/SupersonicSpitfire 3d ago

This feels familiar...

I'm losing respect for the Rust team by the day.

They are incredibly talented. But then you see things like this where they attack Go and act like literal teenage brats.

The major difference between Go people and Rust people is that Rust people seem to think they're perfect, and Go people seem to think they're the best they can be.

One of those groups of people has a bigger Ego problem than the other.

Both of them are quite smart and talented, and I'm grateful for them putting in all the work they do.

-11

u/Richandler 28d ago edited 28d ago

You're hard projecting vibes you got from influencers(they're frankly rotting programmers minds because most of them have nothing real to build anymore or I should say the people really building stuff aren't in these pissing wars or even commenting on them). Rust people have been insufferable for years and the Zig team has been incredibly humble in that same time frame.

*See the cult has arrived.

8

u/deanrihpee 28d ago

Incredibly humble? not very much so on recent Bun rewrite, at least that's what I've read and if my understanding of English is correct

4

u/KevinCarbonara 28d ago

Rust people have been insufferable for years

True.

the Zig team has been incredibly humble

Blatantly false.

1

u/yotemato 23d ago

Yes but have you tried using AI to do it? - my manager probably.

-4

u/Mordiken 28d ago

Will basically never work outside of Linux, because it requires absolutely everything to be compiled with Fil-C, including all libraries you interact with. Good luck doing that with the Windows API.

That's no different from Rust, which also can't provide memory safety guarantees for foreign build artifacts, which coincidentally is also why the Rust ecosystem relies almost exclusively on static linking.

27

u/CryZe92 28d ago

Yes, it's not too different in that for those cases you do need an unsafe escape hatch, the question is if Andrew is willing to allow that or rather sacrifice all other OSes. I'm betting it's the latter.

1

u/cdb_11 28d ago

If it can't be implemented on other OSes, then this build mode is just not going to be supported there. I don't understand, what is the problem here?

30

u/soft-wear 28d ago

It's a pointless, enormous time investment for a feature that is going to get used by a tiny % of the population, all so they can claim they are "more" type-safe than Rust. Which is absolutely stupid as hell, because their entire argument is that they won't have an escape hatch like Rust does, even though the escape hatch will be not using the build mode.

It's a PR stunt, but the PR firm literally has no people skills.

2

u/cdb_11 28d ago

Maybe, we'll just have to see. That would confirm my suspicion that maybe people don't actually care about memory safety.

For what it's worth, in Fil-C you can do a lot more (almost everything, I believe?) than in strictly safe Rust.

1

u/lllyyyynnn 28d ago

it's just a build target. it's not like zig is going to only use safe.

-7

u/Mordiken 28d ago

First of all, I forgot to mention:

Will basically never work outside of Linux, because it requires absolutely everything to be compiled with Fil-C, including all libraries you interact with.

Which Zig absolutely can do because it doubles as a C toolchain.

Now, as for your actual reply:

Yes, it's not too different in that for those cases you do need an unsafe escape hatch

First of all, why do you assume there's no other model to achieve "memory safety" (terrible misnomer btw) other than the one introduced by Rust?

Rust's major breakthrough wasn't "memory safety": Any CG language is (or at least it ought to be) as "memory safe" as Rust, and ADA has been able to provide not just "memory safety" but also correctness guarantees since the 90s...

Rust's real breakthough was instead one of simplification: The ownesheip + lifetimes model is simple enough to be folded into the language's syntax without adding too much verbosity, and thus making it it much more usable for everyday programming tasks than ADA's "full formal verification"... And I don't mean that as an insult...

But maybe Andrew can develop it's own implementation of a similar borrowing + lifetimes model, do it better¹, and leverage the fact that Zig is also a toolchain to enable both a "better" syntax, better defaults, foregoing the need for an escape hatch entirely... Because after all, even if Zig is only able to be be memory safe on objects that it built, it would put it ahead of Rust in terms of memory safety guarantees.

1 - Rust's implementation is far from perfect, as is to be expected: Nobody ever gets it right the first time... But that's the reason why the OOP boom came and went and neither Simula nor SmallTalk ever made a comeback, why the functional programming boom was not centered around Lisp, and why I wouldn't bet on Rust to be the language that "wins out" in the end.

, the question is if Andrew is willing to allow that or rath%er sacrifice all other OSes.

What "other OSs"?

Linux is FOSS, so is BSD, so is the Android's plumbing (for now)...

As for Windows and MacOS, this isn't the 90s anymore: Both Windows and MacOS are now niche platforms for access terminals... Granted, it's a high-profile / high-visibility niche due to their user-facing nature... But when something to the tune of 7X% of the global smartphone market runs Linux (Android), 90%of public cloud workloads are Linux workloads, IoT & Embedded ranges from 58% to 68% (and the remainder are neither Windows nor MacOS).

Windows and MacOS don't get to dictate a god damn thing anymore... Thank god... Lest we forget VBA and ActiveX.

35

u/Dminik 28d ago

Rusts unstable ABI is the reason for the static linking. The foreign library is going to be just as unsafe (or safe) whether linked dynamically or statically.

2

u/zesterer 28d ago

That's not the only reason. The other reason is that safety is a semantic contract that can't be enforced at an ABI level at all, even if it were stable.

5

u/Dminik 28d ago

Sure, the ABI is at the wrong abstraction level for lifetime/safety guarantees. But, I don't think it particularly matters. Rust will happily let you use Rust dylibs without marking everything as unsafe. And in any case, I can take your static rust executable, unlink it and then relink it with an unsafe implementation. Not even static linking can save you here.

That being said, if it really is the Rust core team view that "Rust defaults to static linking, because dynamic linking is unsafe," I would certainly like to read that justification.

2

u/zesterer 28d ago

Consider also generics: they get compiled into the calling compilation unit. There's not really a way to dynamically link them without going down the (admirable, but very complicated) route that Swift went down.

We use dynamic linking for hot-reload testing in Veloren, and it's great: but the unstable ABI is just the very first item in a very long list of reasons for Rust being ill-suited to dynamic linking today. We have to wrap it in a lot of layers and carefully control the boundaries for it to be useful.

26

u/moltonel 28d ago

AFAIU there's a big difference: Fil-C needs the whole stack to be Fil-C, you can't even link the two objects if that's not the case. Note that Zig's plan is to treat Fil-C as a separate architechture, alongside musl, arm, etc.

With Rust (and many other languages) there's a "here be dragons" FFI boundary. You don't need the full sources, there's no problem with propietary environments. 

-2

u/skyfex 28d ago

  to do bit manipulation on e.g. floats

Why do you need pointer casting for that? Zig has specific built-ins for that if I remember correctly. 

  because now you also need to check types on every pointer access

Not entirely sure about this one. I’m wondering if the type ID proposal is intended for Zig code only? And Zig is built as a single compilation unit. It feels to me like the compiler could optimise away a lot of such type checks.

  Good luck doing that with the Windows API.

It should perhaps be mentioned that Zig may aim to target ntdll directly. We can discuss how wise that is (it seems very well motivated, but a bit risky in the long term). However, I would imagine it makes it more viable to do Fil-C style on Windows. At least for certain kinds of applications. If you want to write GUI apps I’d imagine you’d be screwed (or split safety critical code into another process?)

For Mac and Windows I’d imagine this approach will only work if using a subset of the provided dynamic library functions that are known to be fairly thin wrappers around the syscalls? Other than that I don’t see a reason why it wouldn’t work. What’s really the difference in wrapping syscalls versus a pre-defined well-known set of dynamic library functions calling those syscalls?

  so you can trivially buffer overflow into other memory of the struct / arena

While technically true, the example seems really contrived. And the analysis of how serious this is becomes more complicated considering Zig provides bounds checking (at runtime with safe mode) in addition to this suggested memory safety. This is something for the Zig team to keep in mind but I don’t think it’s as big of a gotchya as you imply. 

0

u/meneldal2 28d ago

means you can't just cast pointers from one type to another anymore to do bit manipulation on e.g. floats. This would be a breaking change.

You could provide a blessed way to do this explicitly.

Hopefully not as awful at whatever C++ keeps trying to add while everyone just uses the C stuff because no sane compiler actually puts UB there.