Comment by InefficientRed | Hacker News Reader

Comment by InefficientRed | Hacker News Reader

Parent Full thread

> A bug that unintentionally leads to creation of null is wildly different than V not supporting non-nullability at all.

You have the "badness" ordering here totally the wrong way around. Soundness is about trust.

A known-unsound system is not necessarily bad. I use C and Python. I know the tooling can't give me very many guarantees, and that I have to do the book keeping myself. "Caveat emptor".

In a much, much stronger sense: there is absolutely nothing wrong with a sound system with explicit escape hatches. Bothing. I use sorry in Isabelle and admit in Coq. I do type casts in Java. I know where I can and cannot trust the tooling, and there are clear flags where I need to do my own book keeping. FFI in Rust is an explicit escape hatch.

I can't think of a single system that doesn't have some sort of explicit escape hatch from soundness. As long as it's explicit and understood and above all intentional, this is a feature rather than a bug.

But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

And the blog's examples are not contrived. They are actually very straight-forward mistakes as far as type systems go... most production type system bugs are much subtle.

> But it's very hard to justify using a system that's supposed to be sound and isn't! I don't know where to trust the tooling.

At the point V was version 0.2. Of course it has bugs - even bad bugs.

The article went through each feature of V, found one bug per feature, and claimed that V failed to have that feature.

There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

> There are constructive and non-constructive ways to start a conversation about bugs in a language. One constructive way is to open Github issues. Writing an article claiming that a language fails to have those features at all is one of the least constructive ways I can imagine.

Github issues vs. articles must be a generational thing; I have never used Github's issue tracker even for FOSS projects (admittedly not because we had better alternatives). I'm not even particularly old, but I am old enough to pre-date GH issue trackers as the de facto FOSS issue tracking solution.

Certainly, I would reach out to the author of a project -- especially a personal not-for-profit FOSS project -- before putting them on alert with a highly critical blog post. Except in exceptional circumstances (eg intentional spyware or backdoors embedded into the project).

But I don't think of articles as better or worse than GH issues in terms of form.

This kind of reminds me a tame version of the "disclosure debate" in security in the 90s/00s, I guess. Just because a lot of that debate was claimed to be about protecting users but was actually often about protecting egos (and "look how smart I am" zine articles that weren't entirely written in good faith or professional ethos). Except, of course, that in this case I think a simple cultural difference could explain a lot without any ill intent on either side.

(FWIW I'm not saying either of us is right or wrong. Perception is inherently subjective and all culture is relative. But I think I better understand how this project became so controversial...)

Reply on news.ycombinator.com