Cloudef

It mainly comes down how the std is designed. Zig has many good building blocks like allocators, and how every function that allocates something takes one. This allows you to reuse the same code for different kind of situations.

Hash maps in zig std are another great example, where you can use adapter to completely change how the data is stored and accessed while keeping the same API [1]. For example to have map with limited memory bound that automatically truncates itself, in rust you need to either write completely new data structure for this or rely on someone's crate again (indexmap).

Errors in zig compose also better, in rust I find error handling really annoying. Anyhow makes it better for application development but you shouldn't use it if writing libraries.

When writing zig I always feel like I can reuse pieces of existing code by combining the building blocks at hand (including freestanding targets!). While in rust I always feel like you need go for the fully tailored solution with its own gotchas, which is ironic considering how many crates there are and how many crates projects depend on vs. typical zig projects that often don't depend on lots of stuff.

1: https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-sa...

I think zig generally composes better than rust. With rust you pretty much have to start over if you want reusable / composable code, that is not use the default std. Rust has small crates for every little thing because it doesn't compose well, as well to improve compile times. libc in the default std also is major L.

Vulkan runs everywhere (apart from Apple ecosystem and browser), DirectX accepts SPIR-V nowadays.

Right, of course SPIR-V is a IR format for the drivers and not the final GPU machine code. I don't think WGSL is a bad language by any means, but I still find it odd that the spec doesn't allow loading SPIR-V to cut out the extra transformation steps, and potential bugs or bad transformations in the WGSL implementation.

So apple's making graphics apis worse this time around :)

I don't understand why WebGPU does not accept pre-compiled shaders. Every WebGPU implementation supports loading SPIR-V, but the spec just doesn't have it.

GPU compute? That said you can play x86 games using something like box64/box86

The curvature makes the world seem big and gives quite beautiful scenic view when you are on the rooftop of a building in the town.

VDSO

io_uring doesn't really have equivalent[1], it can't batch multiple UDP diagrams, best it can do is batch multiple sendmsgs and recvmsgs. GSO/GRO is the way to go. sendmmsg/recvmmsg are indeed very old, and some kernel devs wish they could sunset them :)

1: https://github.com/axboe/liburing/discussions/1346

Interesting I was not aware of GSO/GRO equivalent on Windows and MacOS, though unfortunate that they seem buggy.

Remasters generally are worse than originals. There are rare exceptions, but usually you get either mixed bag, or outright worse experience than original. Ditto for remakes.

There is no AGI. LLMs are very expensive text auto-completion engines.

I think valve uses user namespaces if available nowadays. This also checks that devs arent accidentally relying on libs outside of the runtime. (Aside from mesa and libc of course)

Until mesa fixes its dependance on libc, we will continue to need games to be dynamically linked and nothing will change.

(Not saying mesa should be statically linked, but that we should be able to load and use it without libc)

Yeah, its frightingly common CI not doing static analysis checks on C/C++ code. The compiler defaults being really bad doesn't help either. The nice thing about zig is that it defaults to "safe" behaviour, and even if you use it as C/C++ compiler it has saner defaults and compiles with ubsan.

You can guide compiler to check printf style format strings using __attribute__((format)) btw, also checks you are not using a variable as a format string

To be honest, the generated machine code / assembly is often more readable than the actual c++ code in c++ stdlibs. So I can sympathize with the "This printf is more readable than that libfmt stuff." comment :)

Im not sure if its a still issue, but there used to be a period when installing xcode through appstore was impossible as it was either reaally slow or never finished. There was even awesome review by someone making joke story about it in zombie apocalypse like setting, wish i could still find it.

Zig can compile into C, but it's not portable C

Sure and I'm excited for it (especially stackless), but I'd be wary of marketing something that doesn't actually exist yet.

> modern online gaming with microtransactions

I don't think anyone should develop such games either

> On the other hand, this doesn't sound to me like an upside. Of course it's fine and well if it's easy to do this. But hopefully you'd prefer not to have to... ?

Why wouldn't you? You can often make your code simpler and more performant by using certain allocation strategy rather than relying on global allocator. Malloc/Free style strategy is also very error prone with complex hierarchical data structures where for example arena allocation can tie the whole lifetime to a single deallocation.

> Would appreciate some explanation of the theory here. Though it does occur to me that the languages I can easily think of with "coloured" async also don't exactly statically link everything all the ti

Async is moot point, it does not exist in zig right now, it used to but it was removed. There are plans to reintroduce it back, but using async as any sort of benefit for zig is not being honest.

For me its simply better C, and the stdlib is pretty well designed overall

Its probably meant to try mitigate damage in case bad actor gets remote access to your phone or you have malware.

Trying to read the text produced by this font makes my brain hurt

Afaik theres some language hints nowadays but its kinda hack

Indeed, one pain point of unicode is CJK unification. https://heistak.github.io/your-code-displays-japanese-wrong/

BOM is awful as it breaks concatenation. In modern world everything should be just assumed to be UTF8 by default.

The reputation is specific to UE5. UE3 used to have such reputation as well. UE5 introduced new systems that are not compatible with traditional systems and these systems especially if used poorly tank the performance. Its not uncommon for UE5 games to run poorly even on the most expensive nvidia GPU and AI upscaling is requirement.

You can also gitignore everything and add files with the -f flag