Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

331–338 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#331
post #322

Earlier quoted context omitted.

Something like WUFFS is exactly what we should be using for Wrangling Untrusted File Formats as it says in the name, even if you've decided to do that in a distributed system. Realistically you're definitely going to get this wrong, so, use a language where the worst case is it doesn't work is a massive improvement over using languages where it's all additional attack surface. That recent Apple bug where they render…

> Something like WUFFS is exactly what we should be using for Wrangling Untrusted File Formats as it says in the name, even if you've decided to do that in a distributed system. No, I was saying earlier that there are limits to WUFFS. The example I gave was that you can't write something like a distributed system (think consensus protocol like Viewstamped Replication, Raft or Paxos) in WUFFS, but where safety is neve…

> No, I was saying earlier that there are limits to WUFFS

Of course there are limits to WUFFS, that's why it isn't a general purpose language. You shouldn't implement these distributed protocols in it for the same reason toothpaste isn't a good engine lubricant, you deliberately can't even write "Hello, world" in WUFFS.

And yet, if you find yourself, in your distributed system, Wrangling Untrusted File Formats, you should reach for WUFFS to do that safely. Somewhere between "The device has a single button, it's green, press it" and "We process any PDF, HTML or XML documents sent to this email address" you will realise you need all the help you can get to Wrangle the data safely, and that's why WUFFS.

Re: Failing to Learn Zig via Advent of Code

#332
post #322

Earlier quoted context omitted.

> Something like WUFFS is exactly what we should be using for Wrangling Untrusted File Formats as it says in the name, even if you've decided to do that in a distributed system. No, I was saying earlier that there are limits to WUFFS. The example I gave was that you can't write something like a distributed system (think consensus protocol like Viewstamped Replication, Raft or Paxos) in WUFFS, but where safety is neve…

> No, I was saying earlier that there are limits to WUFFS Of course there are limits to WUFFS, that's why it isn't a general purpose language. You shouldn't implement these distributed protocols in it for the same reason toothpaste isn't a good engine lubricant, you deliberately can't even write "Hello, world" in WUFFS. And yet, if you find yourself, in your distributed system, Wrangling Untrusted File Formats, you s…

> Of course there are limits to WUFFS, that's why it isn't a general purpose language. You shouldn't implement these distributed protocols in it for the same reason toothpaste isn't a good engine lubricant, you deliberately can't even write "Hello, world" in WUFFS.

LOL, I would never have thought to do that till now! :)

I think we've always been on the same page regarding WUFFS and file format sanitizers. For me the question here really is, how do we improve the status quo when WUFFS is not an option? i.e. What are sane defaults for general purpose programming languages?

I still maintain that checked arithmetic should be enabled by default in general purpose programming languages, and that's because I believe in the principles behind WUFFS, having worked exactly on these kinds of tools myself.

Re: Failing to Learn Zig via Advent of Code

#333
post #298
post #23

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.

This is almost equivalent to my proposed syntax, just replace `->` with commas between each term (minus the parens)!

Yup, definitely, I find the parallels interesting. Also reminiscent of languages like Io that stack functions together based on the output of the last.

Re: Failing to Learn Zig via Advent of Code

#334
post #329
post #327

Earlier quoted context omitted.

The line is very, very easy: if it is in the language, you can see it represented syntactically in the source code, and programmers using the language write it there. If not, not.

Clang and Visual C++ static analysis tooling can be represented on the source code via C++ attributes and blessed library types, so...

So... not in the language, but in proprietary, non-portable extensions.

Re: Failing to Learn Zig via Advent of Code

#335
post #313
post #273

Earlier quoted context omitted.

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.

Nim is a far richer and higher level language that, like Zig, can run arbitrary code at comptime, but it also has templates and macros. But Zig does have a some things like "import a file imports a struct" which are unique to it and reflect its devotion to cross-compilation as a first class feature: every Zig compiler on every host can compile programs for every other host (at least within the Tier 1 support). Nim can't do that and I don't think any other language can. And its import mechanism is pretty standard, simply making names visible to the importing file or block; the names aren't organized into nested structs as in Zig.

Re: Failing to Learn Zig via Advent of Code

#336
post #287
post #262

Earlier quoted context omitted.

This is of course false.

I assure you there really are places where Rust can match C++.

Yes, but that's the sensible part of your comment, not the part I was obviously disagreeing with. (And no, the troll is not the one who first uses the word.)

Re: Failing to Learn Zig via Advent of Code

#337
post #325
post #261

Earlier quoted context omitted.

Where did you get that impression? No one has ever done that.

Here at HN. I never read anything about Zig outside of HN. What I remember was mostly that Zig should be easier to use than Rust, because Zig doesn't have lifetimes.

That doesn't make Zig higher level than Rust. It doesn't have lifetimes because it's low level, on a par with C ... all memory management is manual and you can abuse pointers to your heart's content.

Re: Failing to Learn Zig via Advent of Code

#338
post #285

Earlier quoted context omitted.

Not "you, the programmer", any programmer. The Rust standard library can and sometimes does have UB, and that's even more true for other libraries.

"This software may have bugs" seems like a very different situation from "Our language just doesn't care whether maybe your program is nonsense and might have Undefined Behaviour".

Nice strawman and goalpost shifting. You said that it's up to "you", the programmer, whether unsafe code misbehaves, but this simply isn't true because "you" don't control all the unsafe code you execute. Again, third party libraries can have UB ... that it's wrapped in "unsafe" keywords doesn't change that, it just means that the compiler offers a tool to help reduce it. What I said is that rust doesn't propose to prevent UB, and that's true. I didn't say that it doesn't care. (And it's not true that Zig doesn't care, either, but it makes a different tradeoff between intrusive limitations and safety.)
Post reply on HN