TakeBlaster16

> And its caller would need to be generic, and so on.

My point though, was that it's extremely similar to code you already write. Zig encourages you to write `fn foo(allocator: Allocator, ...)`. That would just become something like `fn foo(allocator_type: anytype, ...)`. Sure one is generic and one isn't, but since types are just normal parameters, it works out to the same amount of typing.

> std::io::Read::read_to_end takes a Vec<u8>

In Rust, read_to_end is part of a trait and appears in a vtable, so it can't be generic. The Zig equivalent `Reader.readAllArrayList` however, is a free function that is statically resolved. Object safety isn't a concern. In fact, Reader already has generic functions, such as `readInt`. `readAllArrayList` could be generic for the same reason that `readInt` can be.

What's the alternative? Should he choose to risk dying in a crash for the nebulous greater good of lowering the average size of vehicles on the road? This problem will not be solved by individual drivers acting against their own self-interest. It needs to be solved at a societal level, probably with regulations on maximum vehicle size (which already exist, but are being worked around by mfrs)

Signed, A Miata driver. If I ever get in a wreck, I'm guaranteed to lose, but at least I'll go out in style.

Zig already encourages you to pass the allocator around as a value. Passing it as a type would be about the same amount of typing. Instead of this:

  var list = ArrayList(u8).init(my_allocator);

you do this:

  var list = ArrayList(u8, MyAllocator).init();

How is that more busywork?

Rust's issue is not really related. They added the generic after 1.0 and so it needed to have a default for backwards compatibility. If it had been generic from the start with a matching lint (like `implicit_hasher`) things would be fine. Zig on the other hand is not yet 1.0, so they can afford to make allocgate-like changes.

Re: Comptime interfaces

I wonder why Zig didn't decide on the convention of making the allocator type comptime-known. It would make code faster by eliminating a runtime indirect call, and it would let you lower memory usage if you choose a zero-sized type as your allocator, since e.g. every single ArrayList in your app would no longer need to reserve space for the allocator field.

Huh, looks like you're right. I distinctly remember getting an error for emoji domains but not normal ones. I might have made an incorrect assumption from that. Either way I've accepted I'm never getting that domain back.

I bought the punycode domain {emoji_rabbit}.to (i.e. "hop to") intending to build a url shortner. But I never did anything with it and let it expire. And now it doesn't seem like .to even lets you buy emoji domains anymore. I kind of wish I had held on to it.

Maybe it would work, but I can't see myself ever using a font without lowercase letters.

There is a spectrum from obvious breaking changes (removing a method), to non-obvious ones (trait methods, glob imports), and beyond (https://xkcd.com/1172/)

Before adding methods to a trait, they test the change against all public Rust code known to exist, to verify no breakage. Very occasionally this causes them to put plans on hold or work with downstream library authors (see: the num-traits crate)

For the benefit of closed-source code, they also emit a warning before the change is made, so you have time to prepare or give feedback (https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/bu...)

It's a perfectly reasonable policy. I'm not sure what more they could do, unless you expect them to literally never change any traits ever again and ossify the stdlib into whatever state it was in 2015 when Rust 1.0 was released. If that's what you want, pin your compiler/library versions and you can have it!

You could paraphrase this submission as, "The title is not the article"

Here's the full interview https://www.youtube.com/watch?v=GjENnyQupow

The quote at is 11:10

Nice to see you here. I'm not much of a twitch guy, but I'm glad this is on your radar and I'll read about it afterwards!

If you're talking about the `zig fmt` idea, I'd like to draw your attention to a possible pitfall -- Silencing the errors with _ increases the risk that unused vars will be committed to the repo. https://news.ycombinator.com/item?id=32753079

I normally add the equivalent of `-Werror` to pre-commit and CI. But if those warnings are silenced directly in the source code, I can no longer rely on the compiler's guidance to clean up the code, and I would have to hope I could remember all the places I need to clean up before committing. In that way, solving this in the formatter could have the opposite effect on code quality than you intended. I _do_ want the compiler to yell at me... just not yet. Only when it comes time to commit.

Overall I've been impressed reading about Zig's design. You clearly have good engineering taste and I respect you challenging the status quo and trying unconventional ideas, even if I may disagree from time to time. I'm itching to start using the language once this is solved!

> It's funny you say that when [member of group] just [did something once]. It's not a sweeping generalization! They always do this!

"Optimizing for incorrectness" is a funny way to describe the practice of enforcing lint checks as part of a CI pipeline.

Strawman. Incremental compile times don't hit 2-5 minutes in either language, otherwise it obviously wouldn't be viable for real-world use.

And juggling variables was an ongoing ordeal when I tried. I can't imagine how you would work on code without changing any of the variables.

That's just going to result in people committing unused vars to their repos. People are already doing that now after adding '_'s by hand. https://news.ycombinator.com/item?id=32753079 It's going to get even more common when underscores are automatically added all over your project without user input and you have no chance of remembering where they all were.

If the goal of not having warnings is to increase code quality, it's actually doing the opposite.

I don't understand this insistence on working around the problem by layering on tooling, instead of just fixing the problem to begin with.

Yes. If Zig takes 100ms to compile, and Rust takes 2s, but you just spent 20 seconds commenting unused vars in your Zig code, then the slow compiler comes out ahead. It's a great example of how good UX can be more important than raw performance numbers.

The patch works, but it's not efficient to have every user patch their own compiler on every release (and forgo the system package manager for upgrades). I was also envisioning adding a warning system, changing the checks to warnings instead of removing them completely, and adding a `-Werror` flag (or maybe `-Wno-error`). It would be a bit more than 5 lines, but still relatively low effort compared to how impactful the project would be.

Zig is the new HN clickbait, taking over Rust's spot. That's a good sign for the language, honestly

That's the one thing keeping me from considering Zig for new projects right now.

If some enterprising young developer is reading this and wants to make a name for themselves, you should fork the Zig compiler and change those errors to warnings. It would be an extremely popular project.

EDIT: I'll even give you a catchy project name. Wig: Zig with Warnings

I understand wanting to protect real-life children, but I'll never understand why we need to protect drawings of fictional bears

What if they ran official Microsoft servers with moderated chat, but also let you join custom servers after showing a scary warning message (and maybe checked your account birthday or something too). Would that not be enough to free them of liability?

If I had to bet, I'd say it's 3. the C-suite not understanding what they do. Borrowing from the old IT truism:

"We've never had a security breach, what am I paying you for?"

"We're having a security breach, what am I paying you for?"

No, but I have paid Stripe 3 cents on the dollar for pretty much all of the above. To be fair our business was much smaller than Patreon

I had the same thought. I guess you and I are talking about the same Order? If so, I'll see you tomorrow evening!

I've always felt bad about 133% and this thread is putting things in perspective for me

Maybe he should have said, "I encourage readers to skip any interview that discusses views not listed on this 3x5 card"

All our problems would be solved if we simply jailed everyone who put the wrong kind of mushrooms on their pizza

I wish there was a showroom or something I could visit to try them all out and see what fits my hands. I don't mind dropping $300 on a keyboard once, but I don't want to buy 10 different keyboards just to try them and then have to sell the ones I don't want.

Yeah I agree with you! Most new compilers these days are built with these kinds of diagnostics baked in from the start. Since the compiler is doing analysis anyway, it's well-positioned to expose that information to the user.

The one thing I've noticed missing from Zig's implementation is separating those diagnostics into different categories, aka errors/warnings. I can't fault them too much for the oversight since the language isn't 1.0 yet, after all. But I do look forward to them finishing this feature!

That's hilarious, I had no idea! I'm glad I didn't embarrass myself by proposing an RFC. Thanks for the links!