131–140 of 284 posts
Earlier quoted context omitted.
> that has resulted in mindshare death as of 2026 I could make a bet that as of 2026 still more C++ projects are being started than Rust + Zig combined. World is much more vast than ShowHN and GitHub would indicate.
Being started? I would take that bet.
Earlier quoted context omitted.
20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
Earlier quoted context omitted.
> The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I don't use zig. My experience has been that caches themselves are sources of bugs (not talking about zig only, but in general). Clearing all relevant caches occasionally is useful when you're experiencing weird bugs.
I don't know why I was downvoted here. One day, I was experiencing weird compilation errors. Clearing the `ccache` C/C++ compiler cache helped get past the problem. Yes, I could have investigated in detail what was the issue and if ccache had a bug but sometimes you don't have the luxury of investigating everything your toolchain throws at you.
It's not even an argument that you're wrong, just that it's not contributing much and people think that other replies should come first.
Earlier quoted context omitted.
> Which is a very niche use case to begin with, isn't it? My specific use case is yes, but there are a ton of microcontrollers running realtime tasks all around us: brakes in cars, washing machine controllers, PID loops to regulate fans in your computer, ... Embedded systems in general are far more common than "normal" computers, and many of them have varying levels of realtime requirements. Don't believe me? Every c…
See TamaGo, used to write firmware in Go, being shipped in production.
Some embedded use cases would be fine with a GC (MicroPython is also a thing after all). Some want deterministic deallocation. Some want no dynamic allocator at all. From what I have seen, far more products are in the latter two categories. While many hobby projects fall into the first two categories. That is of course a broad generalization, but there is some truth to it.
Many products want to avoid allocation entirely either because of the realtime properties, or because they are cost sensitive and it is worth spending a little bit extra dev effort to be able to save an Euro or two and use a cheaper microcontroller where the allocator overhead won't fit (either the code in flash, or just the bookkeeping in RAM).
Earlier quoted context omitted.
I think rust calls them "zero sized types".
No, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.
Rust's core::convert::Infallible is such a type, representing in that case the error type for conversions which have no errors. For example, we can try to convert most numeric types into a 16-bit unsigned type, and obviously most of them can fail because your value was too big or negative or whatever. u16 however obviously never fails, the conversion is a no-op, nevertheless it would be stupid if we can't write generic code to convert it - so of course we can, and if we wrote generic error handling code, that code is dead for the u16 case, we can't fail, the use of empty types here justifies the compiler saying OK, that code is dead, don't emit it. Likewise converting u8 to u16 can't fail - although it's slightly more than a no-op in some sense - and so again the error handling is dead code.
The kernel32 -> Ntdll changes are the most interesting thing to me here. A lot of the rationale is applicable also to the linux userspace APIs, especially errors in return at the kernel-userspace boundary vs GetLastError/errno in kernel32/libc. Of course on linux the "problem" is that libc and the kernel API are intimately intertwined and the former mandates using errno. I wonder how the pattern made its way into win…
In that world, things like global variables are perfectly fine. But then we got first preemptive scheduling and threads, then actual multicore CPUs, so global variables became really dangerous. Thread locals are the escape hatch that carried these patterns into the 21st century, for better or worse.
Earlier quoted context omitted.
I think rust calls them "zero sized types".
No, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.
io.concurrent(foo, .{});
Earlier quoted context omitted.
I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++". For example, high performance servers (voltlane.net), programming languages ( https://github.com/HF-Foundation , https://github.com/lionkor/mcl-rs , and one private one), webservers (beampaint.com) and lots of other domains. Rust is cl…
> found no place in which C++ is a better fit than Rust, and so it's my "new C++". Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.
Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.
Earlier quoted context omitted.
Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it. Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.
actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker https://github.com/ityonemo/clr