What do /g/irls think of Zig?
atleast its not (((rust)))
>>108861514Pretty fun to learn tbdesu
>>108861514Would you the Zig mascot?
>>108861514does it still get flagged by every single antivirus scanner?
>>108861514Still don't know why it exists. Probably another meme esoteric lang.
>>108861514Gotta love unstable shitlangs where basics things like how to do IO change every week and where the few production projects that exist only compile with forked compilers and will require extensive reworks once 1.0 hitsZig is for retards who think Rust is too mainstream and they are "too smart to ever make memory related errors" (they are not)
>>108861514I don't like it. It's shit.
i do not find it to be a substantial improvement of c. i also think that comptime is worse than c++ templates, and is basically just a macro. defer is okay, but not really an improvement over free(). the only serious improvement over c in my opinion is the module system.
>>108862198Rust was the same until 1.5. The borrow checker in rust is so shit that even ardent rust proponent do everything they can to bypass it.>>108863283I don't know how they do comptime because I'm not touching it until 1.0 given instability really is a huge problem in languages. But the forth model essentially does comptime and it is a FAR stronger notion than even lisp macros, let alone C macros or C++ template metaprogramming.The point of defer is that you can write down the free at the point where you do the allocation, which significantly reduces the cognitive load associated with memory management, especially in complex functions with multiple possible exits (multiple exits are typically frowned upon precisely for this kind of reason, but that is in fact a cope for missing defer, essentially, since multiple exits is often the way to write more succinct and easily understood code in the absence of labels, which are also seen as a code smell (for legitimate spaghetti risk reasons)).There are other things that suck with zig. It is more explicit, which means no implicit type conversion as happens in C. While this is overall a desirable property, it leads to far more verbose code for no good reason (bad implementation, not bad idea). It's also slower because it's stuck with the old llvm backend or the new standalone backend.But overall, I think that after 1.0, if they don't fuck with it too much in the meantime, it will be a good replacement for C. The problem with C is the weak type system, required void* casting preventing many classes of optimizations, no good automatic optimization for many classes of common indirection patterns, high cognitive load for "error management" (memory management but also things like bound checks), lack of metaprogramming features, and lack of high-quality higher-level abstractions to efficiently express common patterns (e.g. iterating or destructuring). It definitely needs to be supplanted.
>>108861650at least it's not go*
>>108861514Wherever there's an unsafe block in my Rust code, you'll find Zig instead of unsafe Rust. Zig complements Rust so well that I can only assume those who think they should only choose one or the other and absolute retards who should kill themselves.
>>108864905If you had ever worked in a multi-language system like you describe instead of larping about it, you'd be singing a whole different tune.
>>108861514Buy an ad, Andrew.
>>108865040Shut up and pay attention, faggot. The key is disciplined boundaries: each language owns exactly one layer, data crosses the FFI in one direction as #[repr(C)]/extern struct pairs, and opaque pointers are never dereferenced outside their owner. The shit pussies complain about in polyglot systems comes from undisciplined, bidirectional, callback-heavy glue. If you've actually shipped a multi-language system, you know the hard part isn't mixing languages, it's keeping the boundary small and auditable.
>>108865338Thanks for proving my point. If you hate performance that much, you'd have a better time using pyshit.
>>108865388The only thing you've proven is that you actually don't know what you're taking about, you just think you do. There is no performance cost is done correctly. In fact, there's a huge performance gain compared to using unsafe Rust in the same way.
>>108865531>In fact, there's a huge performance gain compared to using unsafe Rust in the same way.Unsafe Rust can be as fast as any other systems programming language. It basically gives you everything you have in C.
>>108865531Everytime you post, you simply serve to once again reinforce my point. Please, don't stop posting. Laughing my ass off that you don't even see the performance issues in your retarded setup.
>>108861514sex with this creature
>>108861514I've never seen more horrific casting syntax than Zig's. It single-handedly killed my interest in the language and me use Odin instead.
>>108861514meme language only used by indians no purpose using it for any serious project Just use Rust or wait for a new language bootstrapped on on C99 to show up that is easy for agents to write.
>>108861514lol
is zig actually used in anything serious softwarethe only thing anyone used it for was bun but the guy who wrote that outed himself as a retard and it's no longer using zig which calls into question that he used zig at all in the first place
>>108861514better than sepples but rust is better
>>108865969>>108862057based
>Zig
>>108867209Actually haven't seen a jeet use zig, only white people.>>108867238Tigerbeetle I guess.A few other posts pointed out zig's current issues with language syntax and the fact shit changes even at a basic level between versions, so it's not ready for serious use. I think it's a mistake to break it so much all the time because the breakage is often not on the basis of anything meaningful either. Without letting an ecosystem develop, the language could be DOA. We'll see.
>>108867238tigerbeetle, ghostty
>>108867456I do like w/ odin and jai how they are actually being used in a project the main language guy is involved with so they actually daily have to deal with developers who also use it that seems good for development vs just being a disconnected person breaking it at will. I know bun ended up having to fork it which is probably part of why they just switched off it entirely
>>108867533I don't think jai counts for this at all, since it's so closed off and jblow personally decides who's allowed to use it.
>>108867554He has to work with other engineers writing in it on a major project and if there's any breaking change he has to go back and update his entire game, I think it applies.
>>108866769my issue with Odin is that it's yet another LLVM frontend lang. it just seems like Go without a runtime, I'm not sure if it will be adopted widelyRust succeeded at replacing C++, and I think Zig is the only current memelang that has any shot at replacing C
>>108867238>is zig actually used in anything serious softwareThe biggest zig project is it's own stdlib.So take your guess
>>108867569I argue that this isn't the same because of the power balance he has on who can be in his little club or not. Indeed, there's been a lot of drama about it around the people he "worked with" so far.
>>108867718yeah Odin's situation is actually interesting where he isn't actually in charge of the company but his friend is so the engineers who actually use it in a sense have more authority than the creator over the actual project
>>108867606>I'm not sure if it will be adopted widelyI don't think it needs to be. The language is very performant (on par with C), and due to strong C-interop and its approach to vendoring libraries, has a surprisingly strong ecosystem out of the box. The language is developed and perfectly suitable for real production right now. Everything wide adoption would bring it, it already has. The only blemish it has is that is an LLVM lang, and Ginger Bill does regret that. But I consider that more of an idealistic aesthetic issue than any sort of practical problem for the foreseeable future. The language is just too good not to use, tho I also happen to be the exact target demographic of it (DoD C game-engine devs)
>>108865555Link time optimization thoughbeit
>>108868900That's exactly my point. Pointers and call boundaries defeat a lot of possible optimizations across the boundary due to various assumptions that cannot be made. In a single-language environment, a lot of it can be inferred by a sufficiently efficient compiler beyond what is possible in multi-language environments, in which case the exact language pair actually plays a huge role beyond merely what the compiler can do.
>>108861514It hates LLMs so it's basado.
>>108867644That's true for rust as well
