141–150 of 338 posts
Earlier quoted context omitted.
> `a+b` will have the same value as `b+a` No, as IEEE754 doesn't even guarantee that `a + b` == `a + b`. You always need to compare the absolute difference of two values against an ε. So a == b |a - b| But for sensible comparison of floats, the addition is commutative.
> No, as IEEE754 doesn't even guarantee that `a + b` == `a + b` What? I'm pretty sure that is plain incorrect. Can you back that claim up with references?
The author is not excited about "No hidden control flow", but as a code reader it's really nice. It means that the only context you need in order to understand the control flow of a given line of code is that line itself. You don't need to check for overloaded operators, exceptions, virtual functions, etc. It's this property of Zig that I think makes "read the stdlib source" actually a viable strategy for learning ho…
Hi, I'm Loris from the ZSF. I think this is a fair post overall given what it is: a log of what it was like for one specific person to use Zig for AoC for the first time. I'll spend some words on some of the things mentioned and then add some more useful advice for forrestthewoods at the end. From my perspective the complaints mostly were about now knowing things which had varying degrees of discoverability. The firs…
> The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`. I don't know if ZSF can guide this or if we can incept it into Andy's head, but if there were any coordinate…
To be less dramatic: I do intend to wildly break formatted printing at some point.
Point taken though. Perhaps it deserves its own seat in the roadmap.
Earlier quoted context omitted.
If you're going to compare that way (and I contend you shouldn't) at least normalize by programmer hours, or take into account growth.
Why? This doesn't make sense to me, for a few reasons reasons: 1) I'm looking for the best, not the best by programmer hours or growth. Zig has accomplished a lot and I'm impressed by the work of people on it. But it's still a strictly worse option than many others. I think it's poised to be great in the future, but right now it's not good enough. 2) Organizations always become less effective as they grow, Zig being…
You seem to be ignoring that the thread you are replying stems from people challenging this statement:
“Zig is 6 years old. Rust had much better documentation at this stage of development.”
Earlier quoted context omitted.
Interesting. I had the impression Zig proponents were praising it because it wasn't as low-level as Rust.
Quite the opposite. The very broad-brush overview is that zig aims to replace C and rust aims to replace C++... but among other issues with that analogy, that can't happen unless zig and rust have a dead-simple integration story.
In Rust communities, it's often pitched as alternates to both, but closer to C.
I suppose it's all relative, but the comparison of rust to c++ seems external
Would there by any interest in an imperative language with a basic Standard ML type system? Personally, while I find the imperative paradigm more intuitive than the functional paradigm, I believe functional type systems are simpler and more "right" than imperative ones are (which have been taken over by OOP). There are multi-paradigm languages, but these have large numbers of features, and complicated type systems, a…
Earlier quoted context omitted.
What is a case where floating-point addition is more complicated than a string concatenation? Are you referring to some obscure architecture?
One example would be an architecture on which hardware floating point is not implemented, and has to be emulated in software. This isn't uncommon in embedded, many ARM Cortex-M cores are like this AFAIK.
Integer division or multiplication of long (64bits) can also force the compiler to inline a bit more code or even to call a function on older architecture, hardware division was not a given on ARM before ARMv6 I think, so for example on the Gameboy Advance or even the Nintendo DSi you had to be careful with division etc.
But again, this will only slow down your code if you're not careful, not generating memory leaks silently in the background.
Earlier quoted context omitted.
> It's not. It could be any unsigned type of smaller size than usize. I think it refers to Rust's ability to "indirectly" infer a type by it's later usage which can be somewhere entirely else in the function (for instance when it's used as return value), while Zig has a more direct type inference (but IMHO Rust's approach definitely isn't "obviously better", because sometimes one needs to read and understand the enti…
For the record, I find Rust's ability to change the type of the variable _after_ it was declared to be absolutely bonkers for my ability to understand what is going on in the code. I understand what it is doing, but the fact that changing the return type of a method will change what previous code will compile to is something that I find extremely non obvious and surprising. Inferring what the type is from the current…
I like zig, but agree with many of the points here. A couple of thoughts below, > Zig reference documentation badly needs examples. Can't figure out how to use std.fmt.parseInt. While yes, Zig documentation badly needs examples, I'm not sure this particular criticism is justified. I would have thought that the usage of parseInt, was fairly obvious from the type-signature: parseInt(comptime T: type, buf: []const u8, r…