Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

311–320 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#311

Post by jolux »

_vvhw wrote: post #266
jolux wrote: post #152

To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…

I think the comparison should be more nuanced and holistic than only memory safety, if it is to be a discussion on security and not theater. For example, to get the conversation started, how do both languages compare in terms of checked integer arithmetic? Do they enable checked arithmetic by default in safe builds with an opt-out for performance, or do they leave default builds unsafe with an opt-in for safety? Anot…

> All 100% memory safety, and yet security is still a thing.

And nobody has ever claimed that memory safety is the only thing that matters with security, but it’s definitely high on the list. Can you imagine how much more of a nightmare NPM would be if JavaScript weren’t memory safe? This is the relevant counterfactual.

> Zig is an order of magnitude safer than C, much closer to Rust actually, and more so in some areas

Hard disagree. It’s definitely safer than C, (in terms of UB) but you can tell it’s not even close to Rust on a number of axes (yet?): https://scattered-thoughts.net/writing/how-safe-is-zig/

As for integer overflows, I don’t think they are nearly as big a security concern in a memory safe language with bounds checking. Feel free to correct me though.

Re: Failing to Learn Zig via Advent of Code

#312

Post by mst »

brandmeyer wrote: post #200
mst wrote: post #170

Earlier quoted context omitted.

The DSL I'm currently hacking around on has ++ for string (and list) concatenation and using a -seperate- operator seems to rather help. (I've yet to conclude if stealing ++ for this rather than preinc/postinc was a terrible mistake, so far in context it hasn't seemed to be but I'm still keeping an eye on the question)

Perl uses ~ for string concatenation. Nothing says that you cannot use both infix "++" for concatenation and unary ++ for increment. "-" is both a unary prefix and binary infix operator, for example.

Perl uses '.' for string concatenation.

Nothing says that I can't do that but in context of deliberately -not- re-using operators for completely different things it would seem rather self-defeating.

Re: Failing to Learn Zig via Advent of Code

#313

Post by mst »

jibalt wrote: post #273
mst wrote: post #169

Earlier quoted context omitted.

I have a feeling that Zig is sufficiently different to most other languages in the space that developing a mental model for the way things are supposed to fit together is something that involves "aha" moments - the sort that are tricky to produce for everybody via a single piece of documentation because the thing that makes it snap together in a particular person's head varies widely between people. Similar to the pr…

When I saw the first line of some Zig code, it was unusual so I thought about it and got an inkling of the idea behind it and its power: const std = @import("std"); When I saw the second line and subsequent similar lines, I realized it was effing brilliant: const os = std.os; std and os here are names bound to types ... and you can have type variables and do compile-time manipulation and construction of types. This i…

Now I want somebody who understands both languages better than I do to write a comparison of how Zig and Nim's respective approaches to imports and comptime work.

Re: Failing to Learn Zig via Advent of Code

#314

Post by bradcray »

pjmlp wrote: post #290
ncmncm wrote: post #286

Earlier quoted context omitted.

I have not heard of a lifetime checker in any other language, except maybe Midori.

So here is a sample, Chapel, HPC language mostly sponsored by Intel and HPC https://chapel-lang.org/ D programming language, https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... Ada/SPARK, https://docs.adacore.com/spark2014-docs/html/ug/en/source/la... Swift, https://github.com/apple/swift/blob/main/docs/OwnershipManif... ParaSail http://www.parasail-lang.org/ Project Verona from Microsoft Research https:/…

> Chapel, HPC language mostly sponsored by Intel and HPC

Minor correction: Intel hasn't traditionally been a sponsor of Chapel (though we'd love to see that change). Chapel was pioneered at Cray Inc. and continues on even stronger at HPE after its acquisition of Cray.

-Brad

Re: Failing to Learn Zig via Advent of Code

#315

Post by mst »

andi999 wrote: post #306
mst wrote: post #175

Earlier quoted context omitted.

When saying it positively I often say UTSL instead (Use The Source, Luke).

Isnt the problem with that approach you have a model of the implementation (and not of the 'interface')? I mean you dont know if you are useing the function as intended and if not used as intended it might (actually will) break in the future. For auditing you are right, of course.

Not exactly.

I mean, as a first note one of the ideas here is reading code already written in zig to understand how to write code in zig - so in that case you're effectively inferring the interface from what the authors of the code itself are treating said interface to be.

But also, interface documentation is pretty much never truly complete because there are almost always some implicit assumptions involved (and if you try and make all of those explicit you rapidly end up with documentation that's so verbose people's eyes glaze over when they try to read it so their model often ends up incomplete anyway so how explicit to be is itself a trade-off).

Then zig embeds its test cases in the source file, so you can look at what the authors have explicitly declared -must- work to help you know what the interface is intended to be.

Plus when I'm source diving, I've done enough of it over the years to be able to at least attempt to build up a model of not just the implementation, but of the author's mental model as they were implementing it, and if you can figure out their intent, it's much easier to guess what their code is -meant- to do and thereby what it will hopefully continue to do into the future.

If in doubt, though, leaving a comment in your own code as to what assumption you're making -and- writing a unit test in your own code that verifies the assumption continues to hold will mean that at least if it doesn't you'll see a test failure in your own suite that tells you it changed.

(or: "code to the interface, not the implementation" is absolutely the right thing to aim for, but in practice the line between the two is fuzzy and cases where you have to make a judgement call will always show up eventually)

Re: Failing to Learn Zig via Advent of Code

#316

Post by pjmlp »

bradcray wrote: post #314
pjmlp wrote: post #290

Earlier quoted context omitted.

So here is a sample, Chapel, HPC language mostly sponsored by Intel and HPC https://chapel-lang.org/ D programming language, https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... Ada/SPARK, https://docs.adacore.com/spark2014-docs/html/ug/en/source/la... Swift, https://github.com/apple/swift/blob/main/docs/OwnershipManif... ParaSail http://www.parasail-lang.org/ Project Verona from Microsoft Research https:/…

> Chapel, HPC language mostly sponsored by Intel and HPC Minor correction: Intel hasn't traditionally been a sponsor of Chapel (though we'd love to see that change). Chapel was pioneered at Cray Inc. and continues on even stronger at HPE after its acquisition of Cray. -Brad

Thanks for the correction, I thought seeing them referenced in some talks.

All the best.

Re: Failing to Learn Zig via Advent of Code

#317

Post by otabdeveloper4 »

stephc_int13 wrote: post #148
messe wrote: post #135

Earlier quoted context omitted.

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.

In the worst case, and this is pretty rare these days, yes, adding two floats is a function call, but without memory allocation. 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 t…

Why 'memory leaks'? Presumably, destructors will be automatically called one way or another.

In the simplest case, you can just store all strings on the stack.

Re: Failing to Learn Zig via Advent of Code

#318

Post by ncmncm »

tialaramex wrote: post #296
ncmncm wrote: post #252

Earlier quoted context omitted.

There are no niches where Rust can do better than C++. In many places Rust can, uniquely, match C++.

De gustibus non est disputandum, and thus at such a high level of abstraction you are at best trolling.

The first person to mention trolling is invariably the troll.

Re: Failing to Learn Zig via Advent of Code

#319

Post by ncmncm »

pjmlp wrote: post #290
ncmncm wrote: post #286

Earlier quoted context omitted.

I have not heard of a lifetime checker in any other language, except maybe Midori.

So here is a sample, Chapel, HPC language mostly sponsored by Intel and HPC https://chapel-lang.org/ D programming language, https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... Ada/SPARK, https://docs.adacore.com/spark2014-docs/html/ug/en/source/la... Swift, https://github.com/apple/swift/blob/main/docs/OwnershipManif... ParaSail http://www.parasail-lang.org/ Project Verona from Microsoft Research https:/…

At least most of these don't seem to be added language features, but separate "static analyzers" that rely on inference from existing language structures.

Re: Failing to Learn Zig via Advent of Code

#320

Post by ncmncm »

cb321 wrote: post #307
ncmncm wrote: post #251

Earlier quoted context omitted.

Rust's purpose, its whole reason to exist, is to displace C. Rust will unavoidably fail in that, because anybody still using C is not willing to learn anything else: anybody willing to move on from C already did, long ago. Rust is already approaching C++ in complexity, surpassing it in some places; and also in expressive power, but not surpassing it anywhere yet. If Rust does not end up fizzling (which is still very…

Very minor correction - Nim tends to attract people specifically with its language power via its powerful Lisp-like metaprogramming facilities, static introspection, etc. These features are expressly there to automate away mundane repetition. I do not think it belongs in a list with Zig & C the way you use it here. I also think users of C (not sure about Zig) are quite happy to automate things. Linus Torvalds is a bi…

"Littered" is the operative word: who today uses any of them? (Maybe lex and yacc.) In the 80s and 90s, viable alternatives to C were thin on the ground, so the population demographic of C coders (which included myself) differed markedly from today. That hardly any are used today tells us about the inclinations of the long tail of remaining hold-out C coders.
Post reply on HN