Comments by "" (@pierreollivier1) on "Is 2024 The Year Of Zig ?" video.

@IamPyu-v No it won't, be limited at all LLVM is the backend and will still be accessible and maintained, they just want to also offer their own back-end for faster compilation speed. And because LLVM doesn't handle async well
25
@egorsozonov7425 It is, there are multiple ways of doing that with the @hasDecl for example, and with comptime evaluation, and anytype.
2
@cyberpunkspike I think you missed the part where you can use callconv(.C) after a function and have it use the system's C ABI. I know this works because I have a program where I both use Zig and C, and call functions from both side, so Zig itself on it's own doesn't have indeed a stable ABI (yet) but by using extern or callconv(.C) you can definitely get an FFI that works on both side.
1
@maleldil1 From my own experience, I vastly prefer Zig over C. I've been doing C for years, and it's just not a good language. Zig offers better ergonomics, and tooling, to help us be productive. There are a range of errors that are hard to make in Zig when you have a C background. Zig is ofc still a young language. But it's by far the most promising than any of the new languages I've tested, except for maybe ODIN which is really good but doesn't really align with what I believe a programming language should do. Zig is also far more predictable when it comes to the assembly output. It's easily readable, and cheaply testable. The std is filled with a ton of different DTS for quick prototyping and experimentation. Some solid testing and debugging tools, builtin sanitizer, etc. I love Rust too and I think it's a fantastic language, but I think it's a matter of philosophy. I prefer to have high level of control over my code. I think Rust is amazing at rewriting stuff, but Zig is definitely the one I would choose to replace C.
1
@blarghblargh It's possible to do traits in Zig, you can use comptime and @hasDecl("foo") bultin to see if a struct has a member that is foo, and then implement something by sharing the usingnamespace, it's not as powerful or convenient as Rust, and imo I don't even think that it's really necessary but you can do it. The reason why traits are so important in Rust, is because it's already very hard to implement anything so you build up functionalities, using the trait system which is awesome don't get me wrong, but Zig requires you to be more explicit, which is a win in my book. Plus the benefit of not having traits is that refactoring is much easier compared to Rust. Especially if you are using the builtin unit testing framework.
1
@earx23 This is how you would do it in C for toy projects, it's so easy and so good. const std = @import("std"); const my_c_source_files = [_][] const u8 { "src/main.c", "src/helper.c", "src/error.c", "src/server.c", }; const my_c_flags = [_][] const u8 { "-Wall", "-Wextra", "-Werror", "-fsanitize=memory", "-fsanitize=integer", "-fstrict-overflow", }; pub fn build(b: *std.Build) void { const target = b.standardTargetOptions(.{}); const optimize = b.standardOptimizeOption(.{}); const exe = b.addExecutable(.{ .name = "my_app", .root_source_file = b.path("src/main.zig"), .target = target, .optimize = optimize, .link_libc = true, // you can statically link libc }); // this works like a for each for (my_c_source_files) |file_path| { exe.addCSourceFile(.{ .file = .{ .path = file_path, // you add your path } , .flags = my_c_flags, // your flags }); } Plus on top of that with the zig build system and the ability to interract and talk to C you can use Zig's integrated testing framework to call and test your C code easily. It's so cool. and managing dependencies is not an issue anymore you can just use build.zig.zon to describe where to fetch your dependencies
1
@gideonunger7284 You won't miss it as much once they have the incremental compilation, because than you can basically recompile your code really fast, and make the change you need.
1