[leecommamichael]

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

[aystatic]

> Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool?

What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.

[mort96]

It's not hallucination, it's a basic extrapolation. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" is the same statement as "using Zig resulted in Bun having an extremely high amount of crashes/memory bugs". It is then natural to ask whether their position is "using Zig results in an extremely high amount of crashes/bugs" in general.

[aystatic]

That's a hell of a lot more than "basic extrapolation." You're misrepresenting the original claim to fight against one that's trivially easy to dispute. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" (which unlike Rust, doesn't prevent you from writing them) is a completely different statement than your "using Zig results in an extremely high amount of crashes/bugs." Implying that such a generalization was even on the table is insulting.

Yes, obviously you can write high-quality software in Zig. But does Zig categorically reject the kind of bugs Bun was suffering from? Rust does.

[mort96]

The point is that the "extremely high amount of crashes/bugs" is maybe not the fault of Zig after all, as was implied.

[fastball]

How software behaves is very obviously downstream of the tools (in this case programming language) used to build it.

[mort96]

"Downstream of" is doing a lot of work in that sentence. Language has an effect on, but in no way determines, the reliability of software written in it.

[skybrian]

It's generalizing from Bun (which might be especially tricky code) to other software that might not have the similar issues. There are lots of different kinds of software.

[afdbcreid]

Even assuming that's a correct interpretation, does "using C/C++ results in having an extremely high amount of crashes/memory bugs" not true?

[mort96]

No, that's provably false by a fairly simple existence proof. If it was true that using C results in an "extremely high amount of crashes/memory bugs", we would expect to not find any substantial pieces of software written in C without an "extremely high amount of crashes/memory bugs". Now where exactly you draw that line is necessarily going to be somewhat arbitrary, but by any definition, I think we can all agree that SQLite does not fit that description. Yet SQLite is written in C. Therefore, we conclude that the statement must be false. QED.

Now C does have some aspects which make it more prone to crashes and memory bugs. The less strong statement of "using C results in a higher propensity for crashes/memory bugs than Rust" is absolutely true, I would argue. And both C++ and Rust inherit some (but not all, and not the same) of the aspects which make C prone to memory bugs. (So does Go, I would argue, but less than C++ and Zig.)

[mort96]

Bah waking up today to notice a typo, after the edit window. "And both C++ and Rust inherit some ... aspects" was of course meant to be "And both C++ and Zig inherit some ... aspects".

[charcircuit]

>I think we can all agree that SQLite does not fit that description

One of the reasons WebSQL died was due to how many memory bug related vulnerabilities SQLite had.

[leecommamichael]

You know, I try to ask questions rather than making assertions in order to better my chances at provoking useful thought and conversation.

[pjmlp]

It is basically Modula-2 / Object Pascal with C like syntax.

While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.

C++ already prevents many of those scenarios, at least for those folks that don't use it as a plain Better C, and actually make use of the standard library in hardned mode. When not, naturally is as bad as C.

Also to note that the tools that Zig offers to prevent that, are also available in C and C++, but people have to actually use them, e.g. I was using Purify back in 2000's.

Then there is the whole point that Zig is not yet 1.0, and who knows what will still change until then.

[anthk]

You would like the T3X language as an exercise to port stuff from Free Pascal too it. In a near future I plan to port two libre text adventures with it, Beyond the Titanic and Supernova. If it fits under T3X, it might run in 'high end' CP/M systems out there.

https://t3x.org/t3x/0/index.html

https://t3x.org/t3x/0/t3xref.html

Beyond these Curses simple games, there's a 6502 assembler and disassembler among a Kim-1 simulator, Micro Common Lisps and whatnot.

[pjmlp]

Have to look into it, thanks.

[anthk]

Nice. A tip: there are 'modules' where are just helpers (strings, io) over main functions.

Kinda like write vs printf in C, but easier to grasp. The cheatsheet will help you a lot.

Another thing: setting up the compiler might be cumbersome, I might post a guide soon. I am not the author but making it compile well on some arches can be odd (openbsd/amd64) vs native code (fbsd, 32 bit linux)... nothing complex once you set it up once.

My T3XDIR in the makefile and bin/ scripts it's set to $HOME/t3x0/lib and the bn PATH being set to $HOME/T3XDIR/bin in both Unix env vars and the scripts. It's a 10 minute setup, but after than you will just run

        tx0 -c -s file 

        

(file actually being file.t) and get a binary. Cross compiling for DOS or CP/M involve simlar flags. And it's cool as hell, as I translated Ladder into Spanish for some Spanish OpenBSD pubnix... and the same port will work in DOS too.

On Titanic/Supernova, well, it was a former TP game ported to FPC, is not very complex, and tons of stuff could map 1:1 to t3x. The game might be too big for CP/M but for DOS it would be ideal (even by using the T3X 'big' libraries).

The bundled cheatsheet (make will generate a cheatsheet.pdf file if you have groff) might help you. For instance, gotoxy can be written in T3X as con.move(x,y). You need to import the console library as:

         use console: con;

Also, the WYOP book from the samepge comes with a good chunk of examples to play with in a ZIP file.

Have fun.

[anthk]

Eh, I made a typo. The PATH for tcvm and tx0 should be $HOME/t3x0/bin.

[baranul]

> Then there is the whole point that Zig is not yet 1.0, and who knows what will still change until then.

Seems like their luck finally ran out. For the longest time, they were getting all kinds of passes, as if a post 1.0 language, that others don't get. 10 years is quite a long time not to hit 1.0 or still be into beta breaking changes. Though I think that (the luck) was significantly aided by their perpetual and odd HN boosting.

> While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.

While Zig was a bit safer and more modern C alternative, safety was arguably not so much their selling point. Plenty of other C alternative languages are equally or more safe. Dlang and Vlang, both now having optional GCs and ownership, are examples.

[pjmlp]

Yeah, pity that D somehow lost its adoption opportunity.

Now you can get most of it via C# AOT or Swift, with much better ecosystem.

Still, it is part of the official GCC and LLVM frontends, so there is that.

[leecommamichael]

Thank you for actually making the effort to respond to the curiosity in my question.

[thayne]

It is much harder to write quality stuff in c/c++ that doesn't have memory bugs (use after free, out of bounds access, use of unitialized memory, double free, memory races, etc.). I wouldn't say it isn't feasible to build high quality software in those languages, but even the highest quality software written in those languages has these types of bugs. Zig is better than c, and maybe a little bit better than c++, especially with respect to spatial memory bugs, but it doesn't provide the same garantees as rust.

[ozgrakkurt]

I use clang, LLM, zig compiler, brave, firefox, kde, linux, steam, PC games, neovim, ghostty and more software written in c/c++/zig, and I can't remember the last time I had a crash issue with memory issues.

KDE also includes many other programs inside it like music player, document reader etc. that I never had any issues with.

[dinkumthinkum]

Based on what? I am not familiar with this language called called "c/c++" but if you are writing Modern C++, you shouldn't be creating problems like "double free." It's really not that hard to avoid at all. This reminds me of how all the people carried on as if they were making the kernel so much safer not realizing they needed to use unsafe rust. I think so many people call themselves programmers now but so few know very much about computing beyond whatever the latest fad web framework is up to.

[pjmlp]

This kind of argument is why security folks look down on C and C++ developers.

Because instead of discussing serious matters, they missed English grammar class on the use of / and then get up in arms about the use of "and, or".

Additionally, even code bases from companies that seat at WG21, lack the use of the so called Modern C++, without any language feature or header files inherited from C.

Better C with some niceties keeps being the prevalent approach, unfortunately.

C strings, C arrays, pointer math, printf family, C style casts, macros instead of templates, no STL, and if not hardned ...

[thayne]

Sure if you restrict yourself to a subset of c++ that avoids the more unsafe features, you can avoid some of those problems, but not all of them. And IME, a lot of c++ in the wild still uses those unsafe features, especially when interfacing with c libraries. And even if you always use smart pointers and make sure you always initialize your variables there are still plenty of ways you can get undefined behavior in c++.

> This reminds me of how all the people carried on as if they were making the kernel so much safer not realizing they needed to use unsafe rust.

Those are not contradictory. Confining unsafe code to a few unsafe blocks makes it easier to identify areas that need closer scrutiny. Just because there are unsafe blocks doesn't mean that using rust in the kernel isn't making it safer.

[dminik]

The answer is that C (and by extension Zig, C++) code goes through a hardening process. New code in these languages tends to be unsafe. But bugs and vulnerabilities get squashed over time. Bun gets updated fast and so has a lot of new unsafe code.

[Barrin92]

it's feasible to write good software but anything on the scale of millions of lines of code will have memory and pointer issues. I've worked in large C++ code bases with people much more experienced and skilled than I was and every single one of them would tell you that at that scale, no matter how economic and simple you program you will produce memory bugs, the smartest person in the world makes errors holding that much stuff in their head.

They're difficult to find, difficult to reason about in big software and you'll always create some. Languages that rule that out are a huge improvement in terms of correctness.

[margorczynski]

This is correct but people with too big of an ego or affected too much by Dunning-Kruger) will try to say otherwise even when presented with ample evidence. Instead of a valid response you'll get "skill issue" from people that produce segfaulting code on a regular basis.

[jph00]

The statement “there exists a project where zig led to an extremely high amount of crashes/memory bugs” does not imply “all zig projects have an extremely high amount of crashes/memory bugs”.

This is a classic logic problem - eg “there is an orange cat” doesn’t imply “all cats are orange”.

[dnautics]

> Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool?

plenty of other companies/entities making high quality software in zig? tigerbeetle, zig itself for example.

Bun's entire history has been a kind of haphazard move as fast as you can story, so...

[afavour]

> There is a lot of quality stuff made with C/C++

There’s a lot of leaky crap written in those languages too. One of the core promises of Rust is that the compiler will catch memory issues other languages won’t experience until runtime. If Zig doesn’t offer something similar it’ll make Rust very compelling.

[kllrnohj]

Zig is a love letter to C. It does not do much of anything to address memory management. Doesn't even have any concept of ownership like C++ does (ergo, no equivalent of unique_ptr / shared_ptr). All you get over C is the addition of defer, and even that isn't really that different if you're using GCC or Clang and thus have __attribute__((cleanup)).

[ChrisTrenkamp]

This is a hot take, but programming languages haven't progressed since the 90's. We've been conditioned to believe that if you want to be a serious programmer, you have to either use C++-style RAII (which includes Rust), or garbage collection, and there's no in-between, and C programmers are dinosaurs who can be ignored.

Arena allocators are a great way to automatically manage memory allocations. You malloc a whole bunch of memory and release it all with a single free, which makes it much easier to reason about your program's memory safety.

Casey Muratori has a good video talking about this. https://www.youtube.com/watch?v=xt1KNDmOYqA

And about Zig, you have an Arena Allocator out of the box: https://zig.guide/standard-library/allocators/ . And it's not just limited to that, you have debug allocators that detects memory leaks and gives you stack traces where they occurred.

This isn't to say that Zig is great at everything. I think Rust is great for things like kernels, high-frequency trading systems, and authentication servers where memory safety and performance is paramount. But for things like video games, memory leaks and buffer overflows aren't that big of a deal, and Zig's "Good Enough" approach is great for those types of applications.

[kllrnohj]

Arena allocators are not some grand new concept. They're already commonly used in C++ in the places it makes sense to use them. Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.

Video games are large and have lots of state and lots of threads. Zig's lack of ownership here with fully manual memory management is overall a poor fit.

[nvlled]

I disagree with a lot of what you said, but I don't feel authorative enough to say you're wrong.

> Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.

Arena allocators are not niche optimizations, or not something picked first for optimization. Contrary to what you said, arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner). If the scope is local and well-defined, a regular allocator or even a fixed buffer would do just fine.

> Zig's lack of ownership

Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom. When you use languages with manual memory management, it's expected that you are capable of designing sensible programs in such a way that ownership and lifetimes are tractable and are part of the program design, rather than something to workaround to please the compiler.

[kllrnohj]

> Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom.

Right, it's exactly like C, and we kinda all know how that worked out in practice already...

Hence why I called Zig a "love letter to C". If all you want is C with a dash of zest, that's Zig. If you want a modern language that has learned from the many hard lessons the industry has dealt with over the years... well, Zig ain't it. Which is a perfectly fine thing for Zig to be, it doesn't have to be a good general purpose language. We have plenty of those already from Rust to Go to Java/C#/Kotlin to etc...

> arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner).

Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do. Especially if you later go add on something like an retry-with-backoff or asynchronous metrics/tracing or caching or whatever. Then suddenly you're either fighting use-after-frees or doing deep-copying of data.

[__loam]

Zig does in fact do some stuff to address memory management like making allocations more explicit using allocators and shipping with arenas.

[kllrnohj]

C also has only explicit memory allocators...

[dnautics]

rust does not promise leak safety.

[josephg]

True. But rust does make it a lot harder to leak memory by accident. Rust variables are automatically freed when they go out of scope. Ownership semantics mean the compiler knows when to free almost everything.

[ethin]

> But rust does make it a lot harder to leak memory by accident. Rust variables are automatically freed when they go out of scope.

RAII has entered the chat.