Comments by "Anony Mousse" (@anon_y_mousse) on "What's Zig got that C, Rust and Go don't have? (with Loris Cro)" video.

It's probably a knowledge gap issue. The people that have been zealots for both Rust and Zig have not bothered to learn as much about what they view as the competition and thus don't know as much about how others implement things. It's especially prevalent here when he mentions not being able to cross compile with C despite GCC existing for nearly every platform and allowing you to build cross compilers from whatever system you're on. Not to mention the fact that LLVM very specifically allows one to generate code for any platform from any platform. The speed of compiling LLVM is completely irrelevant yet he mentions that as though it matters. Generally, you'll compile it once or twice, and then only when you apply updates, if you bother to update, and that's only if you need it for cross compilation and even then there are binary packages available for a lot of platforms.
3
@younesmdarhrialaoui643 It's not an opinion, and I answered your question with no malice, so what's with the attitude?
2
@younesmdarhrialaoui643 No, you've given an example of where their rules differ. C doesn't define that behavior and allows the platform to define it and as it turns out, every major platform defines it the same way. Zig defining the behavior in an annoying way doesn't negate what I said as that would be an area where you're writing unequal code and expecting the same results. It seems like you either wanted an answer that confirmed your incorrect thought where you think Zig is somehow faster than anything else or you just wanted to fight someone.
2
No. All languages at the level they're talking about here will be equal, and even more so if they all use the same backend, LLVM. The only way to see a difference is by changing the algorithms and/or coding patterns that you use. This is why on occasion Rust will be slower in tests than C because the idiomatic way to write Rust can slow the code down. In general, neither Zig nor C will have such an idiomatic stumbling block.
1
@younesmdarhrialaoui643 I have presented no ideas, only the truth. It's factual that if you use LLVM for your backend you're going to get equivalent code generation for the exact same patterns which are possible in most such languages. Zig, Rust and C all allow such interchangeability. Tell me where you think I'm lying.
1
@younesmdarhrialaoui643 Except that you're still wrong. Equivalent code generates the same binary, but if the language defines behavior to be different then it's not equivalent code. Where the behavior is the same, the code generation is the same. To claim that you can't write code that isn't equivalent would be a lie, as would saying different behaviors are equivalent. And basically you're just saying you're argumentative for no reason because you already knew the truth of what I was saying.
1
@younesmdarhrialaoui643 I've realized what your problem is, you don't understand the words I'm using. Okay, let's start from the top and define the terms. In C you have: foo = bar + baz; In C++ you have: foo = bar + baz; Are these two pieces of code equivalent to you?
1
@younesmdarhrialaoui643 Did you decide to give up because you realized that you weren't using the word correctly? Or is it because you realized that you misunderstood how a programming language gets compiled and why LLVM is important to the point of equivalent code?
1
@younesmdarhrialaoui643 Except that they aren't equivalent. The C version is int foo, bar, baz; ...; and is a simple addition of two int's. The C++ version is class Foo; Foo foo, bar, baz; ...; and calls an overloaded operator+ function and doesn't something completely different. So now that we've established that two pieces of code that look identical are not necessarily equivalent, will you finally acknowledge that equivalent code means something different from looking the same and thus admit that equivalent code will generate equivalent binaries?
1
@DeveloperVoices That particular implementation is only 8 lines of actual code, and easy to understand if you already know C++ and C. Of course, the idiomatic way to handle deferrals with C++ is to wrap the handling of a system resource in a class, which is generally better than defer from any language that uses it for many reasons.
1
@taggosaurus I would say it's a lost cause. This is one of the problems I have with most modern languages, they're often designed by zealots. If you have a particular ideology that this feature or that feature can be misused and thus should be eliminated, then you're going to have problems designing a good general purpose language, and any language that wants to claim a specific field should probably be ignored by anyone outside that field because at that point it's just another DSL.
1
@ErikOnNoobTube I'm not sure which part you're being sarcastic about, the for loops or the discarding the language, but for loops are definitely ugly. However, one feature I like about the language is that it allows me to elide unnecessary braces. It's not a unique feature, but given the trend in most modern languages it's a welcome one.
1
@ssmith5048 For a programming language? I would consider that early.
1