91–100 of 429 posts
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 should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.
Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also directly include c headers directly in zig code, so this gives you a pathway to modernizing C Code incrementally.
I don't know Zig, but aren't we missing a return here? 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. } }
Also shouldn't the input argument a be named items instead? From what I can see items is an invalid variable as is.
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.
It's usually not the disk space that's the bottleneck, but rather, the CPU instruction cache. On modern Intel and AMD CPUs, the jump from L1 -> L2 alone can triple the latency of a memory fetch. For a "hello world" application, that doesn't really mater, but for, say, an OS kernel, it becomes really important to keep as much of your hot-path code in i-cache as possible.
By the way, I wouldn't be surprised if Rust 2.0 will feature a typechecker that guarantees that everything fits in the L1 cache.
// Arrays may contain a sentinel value at the end, here array.len == 4 and array[4] == 0. const array = [_:0]u8 {1, 2, 3, 4}; Small typo. Len should be 5, I believe.
It's really 4. It doesn't count the sentinel, just the elements. `@sizeOf([4:0]u8)` is 5 though.
Earlier quoted context omitted.
D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. 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…
What about something like R's custom infix operators? R has %*% for matrix multiplication (and a few other built-in ones), but you can define your own %op%. It lets users know that potentially "here be dragons".
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.
It's usually not the disk space that's the bottleneck, but rather, the CPU instruction cache. On modern Intel and AMD CPUs, the jump from L1 -> L2 alone can triple the latency of a memory fetch. For a "hello world" application, that doesn't really mater, but for, say, an OS kernel, it becomes really important to keep as much of your hot-path code in i-cache as possible.
Earlier quoted context omitted.
There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying. But most everyone else likes this, so it stays in. There are no real right answers here. Adding a switch for it…
Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.
We simply have to have a very high bar for new features.
why should I use Zig coming from Python/Go ?
Realistically, you probably shouldn't. Zig seems to be positioning itself as a systems-level language—more of an alternative to C/C++/Rust than to Python/Go. If you're building low-level, high-performance software, it might be interesting to you; otherwise, I don't see a practical benefit.
I wouldn't put those two languages in the same class. Go has about the performance of Java/C# with about the memory usage of C++. It's much closer in performance and resource efficiency to those languages than it is from a scripting language like Python.
Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.
Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…