If there is something I have learned over the years and I have confirmed on this thread is that if you dont like a language or the direction is taking the best course of action is to pick another one. Trying to argue with the developers is a unproductive use of your time. Another option is to wait 3-5 years and revisit the project, you will be surprised that in 90% of the cases either the project is dead on the water or the same problems still remain.
Failing to Learn Zig via Advent of Code
131–140 of 338 posts
Re: Failing to Learn Zig via Advent of Code
#132Earlier quoted context omitted.
> My big problem with Zig is that Andrew Kelley is promising a lot of features, but doesn't really deliver much. Have you, like, seen the release notes for 0.9.0? https://ziglang.org/download/0.9.0/release-notes.html > Zig still can't proper handle UTF-8 strings [1] in 2022 There's plenty of discussion on the subject in basically every HN thread about Zig: the stdlib has some utf8 and wtf validation code, ziglyph imp…
Why does something as basic as uppercasing a string or decoding latin1 require a third-party library? I would expect that to be part of stdlib in any language. Also, why does that third-party library come with its own string implementation? What if my dependency X uses zigstr but dependency Y prefers zig-string https://github.com/JakubSzark/zig-string >? Basically all languages designed in the past 30 years have at l…
Those are all valid points. At the moment I believe Zig has decided to leave full unicode support out of std because they don't want language releases dependent on unicode updates.
Re: Failing to Learn Zig via Advent of Code
#133Earlier quoted context omitted.
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`.
> `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?
Re: Failing to Learn Zig via Advent of Code
#134I disagree from this part: "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 th…
> 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... It's not a given that floating-point addition is a simpler operation than string concatenation. If you're serious about what you write, then all operators should be banned.
What is a case where floating-point addition is more complicated than a string concatenation? Are you referring to some obscure architecture?
Re: Failing to Learn Zig via Advent of Code
#135Earlier quoted context omitted.
> 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... It's not a given that floating-point addition is a simpler operation than string concatenation. If you're serious about what you write, then all operators should be banned.
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.
Re: Failing to Learn Zig via Advent of Code
#136The 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 how to use it.
Re: Failing to Learn Zig via Advent of Code
#137Earlier 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…
You can always specify the type.
let foo: T = bar.parse()?;
// or let foo = bar.parse::()?;
baz(foo);
In my experience I've never found this to be surprising behavior, or unclear.
Re: Failing to Learn Zig via Advent of Code
#138Nice to see a "brain dump" as someone who learned many languages and can easily relate with most of the issues the author faced. But I take issue with this: // Obviously good and easy to read return a*(1.0-t) + b*t; // Obviously bad and hard to read return add(mul(a, 1.0 - t), mul(b, t)); Sorry, but the first one is not obviously good, it's just what you're used to (the second one is indeed bad). Here's what I would…
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.
The Lisp version can also be more readable with a macro (like https://github.com/quil-lang/cmu-infix): #I(a*(1.0-t) + b*t). Or something else that would let you write GP's preferred syntax. One of the things that makes Lisp Lisp is that if the parens are over-cumbersome, you have the tools to take them away. See also CL:LOOP.
Re: Failing to Learn Zig via Advent of Code
#139Earlier quoted context omitted.
In most cases I would agree with you, but I think ArrayList is simple enough that backwards compatibility won't be a major concern. It's literally just a wrapper around slices that handles resizing for you, and there's no real reason for that to change. Exposing the slice underneath is a necessary part of its interface.
To someone very familiar with the idea of slices and Zig, it might be obvious and sensible. But to me, unawareness of how slices work means I thought I could easily access garbage data if array capacity >= list length; and accessing the underlying data structure feels unclean and makes me think of hacky code. While the field of ArrayLists is unlikely to see any innovation, it certainly doesn’t make a good first impre…
I think part of it comes down to mindset. If you think of ArrayList as an abstract container, then yes, you're totally correct that having the underlying data structure being exposed is a bit jarring and unexpected.
But I don't think that's the right level of abstraction to come from. ArrayList is just a wrapper around a slice that handles allocation and deallocation for you: the underlying data structure is part of the contract of the type, allowing it to be almost a drop in replacement.
Re: Failing to Learn Zig via Advent of Code
#140I 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…
> This is not a dig at anyone's project or language, but "read the source code" comments always strike me as unhelpful.
I agree, reading the source is a good way to learn more once a person already know the language.
It can be great to help track down a bug, or learn about an obscure corner case in a function, or see more advanced idioms in use, but it's a pretty terrible and unfriendly way to learn a language in the first place.