Comment by kllrnohj
16 hours ago
> that will let me iterate at the speed of JS or Python with performance of C or Rust.
Didn't Go already do that?
> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement
Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...
Rust is significantly different.
Go is for the cases where GC works for you (many, many cases).
Zig is for when you need control over the allocator (also many such cases).
> Didn't Go already do that?
no. GC pauses turn any serious systems work into hell.
> Yes, and it will still only be useful [...]
this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui
> no. GC pauses turn any serious systems work into hell.
did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter
> this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui
Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?
> They were comparing
that was me comparing, please kindly read usernames next time :)
> why not just choose a language that doesn't compromise itself for those ideals in the first place?
I might want to wrap a timing-sensitive machinery into some nice UI. Rust has Tauri for that, sure, but now we are bringing npm and have zero chances of having GPU-accelerated UI without a crap-ton of fuckery which would be easier in Zig. another path for resolving that same issue is Compose Desktop + Project Panama, but then you are dealing with data marshalling, FFI boundary, and manual resource management in an environment that does not expect this.
so, here is a genius idea: why not have everything in one language? C++ already does that, much like C, but Zig does that so much better, and incremental compilation time is one of the more practical and immediate developer UX benefits it provides. Rust? good luck having shared mutable state there.
Because they like and are excited about Zig.
Go is a terribly verbose language.