You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.
Any stats/source? Not that I think it's false
> and the ugly parts look uglier (unsafe) which encourages refactoring.
Looks like Bun owes that to itself to some extent, not solely because of the language
https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
119 open, 885 closed
https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
10 open, 46 closed
Around 2500 issues with segmentation fault.
https://github.com/denoland/deno/issues?q=is%3Aissue%20%22Se...
With the total number of issues being 16,458 for bun and 14,259 for deno.
> why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things.
Not a hard number obviously but a clear indication those issues exist.
With unlimited tokens make it a lint rule or auto formatter.
This just sounds like they are not good at using Zig. I have been daily driving ghostty on linux for a fairly long time now and I have never seen these kinds of issues. I have also used ghostty on macos for a bit and didn't have any problems there either.
Zig is really good for writing stable and reliable code. There is also a database written in Zig that seems to be fairly successful [0].
I also wrote zig for some time and compiler/toolchain was really pleasant to use. I wrote more segfaults in Rust ffi code than all segfaults I had in Zig in total while I was writing Zig.
Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.
That's odd, because of the visibility of team Bun using the language, one would think they could get whatever help and guidance they asked for. Seems weird for team Bun to complain about crashes, leaks, and bugs if they could have what they are doing wrong explained to them or their issues fixed in a timely manner.
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.
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.
In short, I'm accusing you of doing a motte-and-bailey.
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.)
One of the reasons WebSQL died was due to how many memory bug related vulnerabilities SQLite had.
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.
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.
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.
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.
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
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;
Have fun.
KDE also includes many other programs inside it like music player, document reader etc. that I never had any issues with.
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 ...
> 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.
This is a classic logic problem - eg “there is an orange cat” doesn’t imply “all cats are orange”.
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.
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.
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.
RAII has entered the chat.
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...
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.