[_u9xp]

Only as safe as the creator decides. Andrew has shot down discussions about DOS vulnerabilities in the standard library and the cult-like discord community loves to dig on anyone who brings such things up.

I will be staying away from Zig exactly for that purpose. Great idea but I can't get behind a maintainer that adamantly refuses to even discuss proper, safe standard library design.

EDIT: Yep, the HN crowd tends to be the same. Downvote me all you want please :) We'll see over time.

[kbd]

> Downvote me all you want please :)

I think you're getting downvoted because "citation needed", while accusing the Zig community of "cult-like" behavior without justification.

Where has Andrew "shot down discussions about DOS vulnerabilities in the standard library"? As is, your comment isn't helpful.

[fctorial]

Can you share a link?

[_u9xp]

https://github.com/ziglang/zig/pull/4929#issuecomment-649191...

The bulk of the conversation happened in Discord around that time. Initial attempts to bring this up were met with "zig is perfect"-type conversation, none of which was very technical.

Finally, the conversation grew to be so large and fiery that Andrew had to step in and say "everyone play nice, now!" and then head back out.

Then this PR was filed. Invalid user input should not be classed as undefined behavior and concluding that the standard library's UTF decoder shouldn't be used if you want a safe execution is just absurd.

There were a few other run-ins on discord in the same vein. It made a few people at the time leave, including myself.

Andrew's smart. Zig is a cool idea. But I don't like when this laisse-faire attitude is taken when designing a programming language that places so much emphasis on being safe.

[kbd]

> Then this PR was filed. Invalid user input should not be classed as undefined behavior and concluding that the standard library's UTF decoder shouldn't be used if you want a safe execution is just absurd.

Just to copy Andrew's final words in here:

> I think the entire std.unicode needs an audit both in terms of API design and performance. This module is not yet what it will become before stabilization. But this commit is not where this is going.

The PR wanted to make a function that takes runtime values only take comptime values. I read Andrew's response as saying "this all needs to be looked at before 1.0 but this isn't the way to fix this", which seems to me to be an entirely reasonable thing to reject a PR with.