171–180 of 284 posts
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…
It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years. There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics. To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is…
A pretty obvious explanation as to why Odin has more games written in it is that the language is somewhat explicitly marketed towards that use-case, even going as far to have a vendor library collection that includes many popular game dev libraries.
Earlier quoted context omitted.
I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1]. These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies. [0]: https://github.com/tigerb…
I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.
Earlier quoted context omitted.
Yes, inertia. If those projects started today, they would likely choose rust.
Why isn't rustc using Cranelift then?
It's notable that the projects you mentioned mostly don't need to deal with adversarial user input, while the projects I mentioned do. That's one area that Rust shines in.
Earlier quoted context omitted.
It certainly is according to the various CS definitions of type systems. Plenty of OOP architectures can be implemented 1:1 in Rust type system.
> Plenty of OOP architectures can be implemented 1:1 Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.
Earlier quoted context omitted.
Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions. This puts much more work on the compiler development side, but it's a great boon for the ecosystem. To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think.
Rust started in 2006 and reached v1 in 2015, that's 9 years.
Earlier quoted context omitted.
See TamaGo, used to write firmware in Go, being shipped in production.
Not familiar with it, but reading the github page it isn't clear how it deals with GC. Do you happen to know? 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…
Here is the commercial product for which it was designed,
https://reversec.com/usb-armory
A presentation from 2024,
https://www.osfc.io/2024/talks/tamago-bare-metal-go-for-arm-...
Earlier quoted context omitted.
> 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.
Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust. Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.
It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years. There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics. To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is…
> Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year. Not at all, if the team needs 30 more years they should take it. > However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0. Funny you see it as bleak when most of the community sees it as the most excitin…
Yes, I understand that is the opinion in the Zig community. As an outsider, it seems odd to me to pick a language that I constantly need to maintain.
>> However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0.
> Funny you see it as bleak when most of the community sees it as the most excitinh thing in systems programming happening right now.
You misread that one. I was talking about the odds of seeing a 1.0 version of Zig soon.
> I think you comment is in bad faith, all the big zig projects say that the upgrade path is never a main concern, just read HN comments here or on other zig threads, people ask about this a lot and maintains always answer.
Maybe you didn't read what I wrote carefully enough. This is part of the protectiveness from the Zig community that prompted me to write in the first place.
WITHIN the Zig community it is deemed acceptable for Zig upgrades to break code. Consequently it becomes simple survivor bias that people who use Zig for larger projects don't think that this is a major concern BECAUSE IF THEY FELT IT WAS A CONCERN THEY WOULD NOT USE ZIG.
Whether programmers at large feel that this is a problem is an unknown still, since Zig has not yet reached to point of general adoption (when people use Zig because they have to, rather than because they want to).
However, it is INCORRECT to state that just because a language is not yet 1.0 it needs to break older code aggressively without deprecation paths. As an example, Odin removed the old `os` module and replaced it with the new "os2". This break was announced half a year in advance and lots of thought was put into reducing work for developers: https://odin-lang.org/news/moving-towards-a-new-core-os/
In the case of C3, breaking changes only happen once a year with stdlib going through the general process of deprecating functions long before removing them.
I wanted to highlight how these are quite different approaches. For established languages, this is of course even more rigorous, but neither C3 nor Odin are 1.0, and still see this as valuable and their communities then end up expecting it.
So please understand that when you say "it's never a main[sic] concern", this is simple survivor bias.
Earlier quoted context omitted.
> 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.
There are places a language could be a better fit, but which haven't adopted it. E.g. most languages over typescript on the backend, most systems programming languages over Java for games.