Failing to Learn Zig via Advent of Code • Hacker News Board

Re: Failing to Learn Zig via Advent of Code

#81

Post by ffhhj » Mon, Jan 17, 2022, 2:33 PM UTC

pyjarrett wrote: post #53

ffhhj wrote: post #18

> 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…

How is this different from Rosetta Code? ( https://rosettacode.org/wiki/Rosetta_Code )

> How is this different from Rosetta Code?

Yeah in some way they are the same kind of reference. I already knew about Rosetta Code, explored their snippets and found them valuable as a learning tool by curiosity. But The Quick Snippet Reference presents examples to do the smallest tasks that we would need when programming. The tree of these minimal operations is shared between languages, so it's easier to compare, or find how to do something in a new language that you already use in another.

Re: Failing to Learn Zig via Advent of Code

#82

Post by Zababa » Mon, Jan 17, 2022, 2:35 PM UTC

brabel wrote: post #14

Nice 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…

(a * (1 - t)) + (b * t) would be my favorite way to express this in a programming context, I don't really see the point of your proposition over prefix or stack:

    (+ (* a (- 1 t)) (* b t))

    1 t - a * b t * +

Re: Failing to Learn Zig via Advent of Code

#83

Post by thom » Mon, Jan 17, 2022, 2:36 PM UTC

edflsafoiewq wrote: post #72

thom wrote: post #57

Earlier quoted context omitted.

On the premise that someone might write LISP for a living, I'm saying it can help clarify a multistep mathematical expression. It's incredibly tedious to relitigate people's feelings about brackets over and over again.

I think it actually obscures the important facts about the expression by breaking up the structure which is displayed by the usual infix notation 1. It is a linear combination of a and b: there are two symmetric terms, a scaled copy of a and a scaled copy of b 2. The factors are functions of t alone which goes between 0 and 1 as t does This isn't litigating about brackets, the traditional prefix notation also display…

I was really only interested in the similarity between the threaded form and the proposal with all the commas (since they mentioned LISP) but I wish I'd had an aneurysm and died before sending the comment tbh.

Re: Failing to Learn Zig via Advent of Code

#84

Post by gameswithgo » Mon, Jan 17, 2022, 2:38 PM UTC

eterm wrote: post #38

> [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?

when you don’t have in editor compiler errors and are trying to learn instant feedback can be nice

Re: Failing to Learn Zig via Advent of Code

#85

Post by the_duke » Mon, Jan 17, 2022, 2:39 PM UTC

skywal_l wrote: post #6

Yes, error messages in zig needs improving but that's not surprising. Rust error messages where pretty terrible back in the day. I found zig language reference pretty good[0]. It is simple, lot of example. I would find 80% on there and had to google the rest. And as another commenter said, looking at zig source code is actually not a bad idea. The std lib is pretty clear and with comments. My biggest beef with zig is…

A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes.

The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors.

It'll be interesting to see how this plays out as the ecosystem grows.

Re: Failing to Learn Zig via Advent of Code

#86

Post by tialaramex » Mon, Jan 17, 2022, 2:40 PM UTC

stephc_int13 wrote: post #60

I 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…

I also would prefer not to have + as concatenate, and Linus feels strongly enough about it (and has enough influence) that Rust for the Linux kernel does not have Add and AddAssign overloaded on string types, among many concessions.

However I think in general purpose programming we lost that battle when Java special-cased the operator. There's no overloading in Java, you can't have + do the Right Thing™ in Java for your 3D vector class, but it does concatenate strings because people had begun to expect that.

Also, while I'm in this topic, the author argues they don't want anybody overloading either of the member access operators (which is something Python kinda-sorta supports) but notice that Rust effectively does this all the time and nobody freaks out because it feels completely natural.

Your Box isn't a Thing, so, why can you call Thing methods on it? Because it is transparently passing those into the underlying Thing by implementing the relevant overload features from core::ops and all of Rust's smart pointers work the same way.

misfortunate::Double shows that this gives very strange behaviour if somebody uses it inappropriately, a Double is actually two Things inside, but when you change it, you're changing one of them, while any immutable references are to the other one... an eerie experience.

Re: Failing to Learn Zig via Advent of Code

#87

Post by delphLonepaw » Mon, Jan 17, 2022, 2:40 PM UTC

rootlocus wrote: post #68

delphLonepaw wrote: post #42

Earlier quoted context omitted.

Read the language reference, use ziglings, use ziglearn.org, use zls (don't trust it too much tho, but it will help a bit) and vscode or any text editor that supports jumping to the source, and of course, RTFS

Read The Fabulous Sources?

That's a way of reading it

Re: Failing to Learn Zig via Advent of Code

#88

Post by stathibus » Mon, Jan 17, 2022, 2:43 PM UTC

iTokio wrote: post #26

NeutralForest wrote: post #22

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…

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language. It helps you to see what are the idioms, what does optimized production code look like. Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

Reading the c++ stdlib source code is never a good idea.

Re: Failing to Learn Zig via Advent of Code

#89

Post by Zababa » Mon, Jan 17, 2022, 2:44 PM UTC

dnautics wrote: post #76

Zababa wrote: post #74

Earlier quoted context omitted.

> comparing by time spent is an unfair comparison Yes, and language competition is unfair. As a user, I don't care that Zig is more "cost/time effective" than Rust or Java, I care about the end result. The end result, right now, is a worse documentation than lots of other languages. That doesn't mean that the people behind Zig are bad or anything like that. That just means that when choosing between X and Zig, Zig's…

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 small would have an "unfair" advantage since they're still small.

3) Normalizing by programmer hours would lead you to a language that took a few hours to be developped, but is not good at all. This doesn't make sense.

I feel like you're evaluating Zig as if it was a company on which to invest. In that case, Zig is a good pick. It's small but already at a good point, and probably will have a good growth. But if you're looking for a supplier right now, I wouldn't bet on them. It's still small, young, and depend on a few people.

Re: Failing to Learn Zig via Advent of Code

#90

Post by snek_case » Mon, Jan 17, 2022, 2:52 PM UTC

llimllib wrote: post #62

SiVal wrote: post #29

Earlier quoted context omitted.

If there are fundamental philosophies in a programming language (and there usually are), tutorials ought to begin with lots of tiny example programs that exemplify those fundamentals. They should continue with examples of gradually increasing complexity, but ALWAYS using those same fundamentals in various combinations to show how those fundamentals are intended to work together in all sorts of ways. If the tutorials…

My understanding of the Zig's team's opinion is that Zig is not currently at a place where they want to solidify the design by doing such things as writing extensive tutorials documenting how to write it - tutorials that will need to be updated every time they make breaking changes, which they explicitly still want to do. A lot of this seems to be a mismatch between people's expectations of zig's stability and the re…

The way you handle that is by adding all your tutorials to the test of tests for the compiler. Then, whenever a breaking change happens, you have to update the tutorials for the tests to pass, which isn't difficult since you're probably only talking about minor, incremental changes.