/Cinny
like racc’mon i am not even asking for a full borrow checker here, this is obviously inraccorrect raccode which cannot possibly be raccorrect. even literal c raccompilers flag this as broken
@charlotte I think zig is very explicit about not being "safe", especially when it comes to references being passed around? And about just being a better way to write C?
@ben @charlotte it's supposed to be lightweight modern alternative / drop-in replacement for C (you can have mixed Zig/C codebases), with a bunch of nice modern stuff C doesn't have like metaprogramming (and comptime), pattern matching, explicit error handling, defers etc, and no ancient cruft like C-style macros.
Not to be compared with Rust which solves an entirely different problem in entirely different space.
/Cinny
@IngaLovinde @ben yet it doesn’t raccatch this bug that even c raccompilers will raccall you out on: https://godbolt.org/z/9EnnKofGT
@charlotte @ben in this simplified case, yes.
Apparently there are plans for zig to start catching this bug eventually, too: https://github.com/ziglang/zig/issues/2646
/Cinny
@IngaLovinde @ben it just seems silly to me if you make an alternative to c to then just introduce the very same issues that c has
@charlotte @ben it's not even stable (still far from v1), and this is not even about the language but about the compiler.
Obviously the compiler written by a few enthusiasts in their free time, when it has not even reached stable, cannot be better than C _compilers_ (on which thousands (?) of person-years were spent) in every single aspect from the start, there are bound to be areas in which it works worse.
(Not that C compilers are perfect in solving this specific problem, because apparently it's mathematically unsolvable unless you go full rust and introduce lifetimes and force developers to explicitly annotate them where they cannot be implicitly derived.)
/Cinny
@unbalanced @IngaLovinde @ben what use cases are supported by c and zig that aren’t by, say, rust?
they can both be used in essentially the same places (although c has more targets than either zig or rust right now), and it seems the biggest thing that is unsupported in rust that is supported in zig and c are variable-sized stack allocations and variable-length arrays which are less use cases and more code design decisions.
zig might be a better language if you need to do lots of c interop, i will not deny that
@charlotte @ben @unbalanced the way I see it, zig might be better for low-level code, because:
1. That's where rust guarantees (and borrow checker) break down and you'd have to write unsafe rust most of the time anyway. And for unsafe code, zig is much nicer with its `defer` keyword for example.
2. That's where the default (and only, until recently) rust behavior of allocating from heap and panicking/crashing on failure can be unacceptable. Or working with external heap in general.
3. Also, C interop.
Plus in some areas zig is way superior to rust (the entire comptime thing for example, vs macros in rust)
/Cinny
/Cinny
@unbalanced @IngaLovinde @ben nowadays for plugins i’d instead use some sort of rpc system, even if it’s just a stream of json objects passed via stdio. it’s still fast but also much more flexible since you can write it in any language you want
/Cinny
@unbalanced @IngaLovinde @ben (it also gets you things for free that are at best non-portable like hot code reloading. failing that you can also create a traditional c-style plugin api using the c ffi functionality)
@charlotte @ben @unbalanced for interop, the main selling point of zig as I understand is that technically you can just take your C codebase and gradually migrate parts of it to Zig.
With Rust that would be a huge, maybe even intractable, pain in the ass.
/Cinny
@unbalanced @IngaLovinde @ben yeah i ended up just forking an open source library for that purpose (for the rpc thing)