41–50 of 429 posts
why should I use Zig coming from Python/Go ?
If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency.
"Smallness" seems to be a sought after feature but I'm not sure why.
fn count_nonzero(a: []const i32) i32 {
var count: i32 = 0;
for (items) |value| { // "for" works only on arrays and slices, use >"while" for generic loops.
if (value == 0) {
continue;
}
count += 1; // there is no increment operator, but there are shortcuts for +=, \*=, >>= etc.
}
}Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…
"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.
But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types.
Not allowing the overloading of unary *, &, and dot also help discourage non-arithmetic overloading.
Earlier quoted context omitted.
if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity
> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.
why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.
why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.
I also find it incredibly frustrating when an application I rarely use fails to launch because it wants to force me to download, process and install massive updates for features that I don't even want.
As an engineer, I care about binary size because gigantic binaries tend to require far more time to compile, move around and work with. Gigantic binaries tend to be a reliable signal of slow, toxic, internal processes that chew up positive energy and produce cynicism and frustration in it's place.
It's not about the disk space per se, it's about treating waste as if it's a virtue.
I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…
Could it be that this problem is due to Zig's stance on "no warnings"? It's admirable to try and partition things into strict "correct" and "incorrect" categories. But with only static information it seems like there's always things that seem a little grey.
Earlier quoted context omitted.
if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity
> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.
Earlier quoted context omitted.
if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity
The thing about operator overloading is that it was abused during one of the worst era of C++. And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent o…
you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable