51–60 of 338 posts
> [Compiling] takes about ~3 seconds minimum which is frustratingly slow I feel old, I know that any time is an opportunity to get distracted but 3 seconds doesn't strike me as a long compile time. Or is that a typo for 30, which would make more sense, which is definitely long enough to be a frustration?
I use zig anyway.
I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…
I prefer to look up the source code either way, examples and the documentation can only get you so far.
> Rust is trying to be a better C++ > Zig is trying to be a better C I recently started learning Rust by adding snippets to The Quick Snippet Reference [0]. Without any previous knowledge of the language I knew there had to exist a data type for dynamic arrays. After several Stack Overflow searches I found it: Vec. It was very interesting to compare to Python's Array. Getting to understand the drain() method was a re…
> [Compiling] takes about ~3 seconds minimum which is frustratingly slow I feel old, I know that any time is an opportunity to get distracted but 3 seconds doesn't strike me as a long compile time. Or is that a typo for 30, which would make more sense, which is definitely long enough to be a frustration?
$ time zig build-exe ./a.zig -O ReleaseSmall
real 0m1.728s
user 0m1.544s
sys 0m0.292s
$ time zig run a.zig -- input.txt
min 337 342641
min 470 93006301
real 0m1.138s
user 0m0.789s
sys 0m0.270s
[1]: https://github.com/llimllib/personal_code/blob/master/misc/a...
Earlier quoted context omitted.
If zig supports + for floating point addition, then it is already fine with ‘+’ being non commutative. The rest of the argument can also be applied to functions. What does product(a, b) do?
Aside from `NaN`, how is floating point addition non-commutative? It's not associative, but `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| > Rust is trying to be a better C++ > Zig is trying to be a better C I recently started learning Rust by adding snippets to The Quick Snippet Reference [0]. Without any previous knowledge of the language I knew there had to exist a data type for dynamic arrays. After several Stack Overflow searches I found it: Vec. It was very interesting to compare to Python's Array. Getting to understand the drain() method was a re…
Should I cope with this? If so, do so. This is likely if you're a library and unlikely in some application software, especially AoC. Don't ask me to try calling fooA() and then call fooB() if it fails, just have that code inside fooA() already.
If not, might my caller want to know what went wrong? In a library your users might want to cope, unless you're sure the situation is fatal and all hope is lost, so always return Result and use appropriate Errors for error cases, the ? operator can help you pass on errors from other libraries.
Otherwise panic.
Because Rust's Result doesn't change control flow, you don't need to decide how callers should cope with Errors, only flag that it's their problem not yours. Because Result doesn't have a non-Error result in it if you returned an Error, your caller can't mistakenly carry on anyway, they'll just panic if they try to do that.
Earlier quoted context omitted.
The LISP version can be more readable with (e.g. Clojure’s) threading macros: (-> 1 (- t) (* a) (+ (* t b))) Obviously use more or less whitespace to taste.
I can not read that at all .
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 just always find it a PITA that Rust can't do global type inference and that I have to type most of the types for myself.
I don't understand people recommending reading the source code to learn. Source codes can be really daunting because there are so many things going on. There can also be "tricks" using advanced language features, which defeats the purpose if you're trying to learn as a first timer. Also, "read the source" is, at least to me, an admission that there is no valid documentation 90% of the time. Reading the source of a to…
It's important to consider that for zig at this stage , "not having valid documentation" is expected. At some point not having valid docs will become considered to be unacceptable. Forcing people to read the code puts pressure on the code to be clean. Not writing docs against an unstable API is a strategy to make it freer for the authors to change the API, possibly in sweeping breaking ways (for example allocgate).
Zig is 6 years old. Rust had much better documentation at this stage of development.
To be fair though: Rust also had corporate backing and a larger fan base contributing to the book and std docs.
"I also think it's partially wrong. No one in the history of the world has ever been confused or upset by a + b calling a function."
It depends. If this is simple math on vectors I think it can be OK but it should probably be a built-in feature of the language as this is common, solved and we all implement it the same way (for short vectors at least)
But the + operator has been abused in the past, especially with strings concatenation and I think this is a huge liability. Such an innocent looking operator, the simplest of all operations, leading to a function call, a memory allocation and thus a very real potential memory leak, all of that hidden from the eyes...
In my opinion, clarity should have priority over anything else. If an operation is computationally complex (especially with side effects) it should be at least hinted to the reader by a function call.