Hacker News Reader

Comment by subarctic | Hacker News Reader

Lots of interesting bits in the FAQ: https://flix.dev/faq/

Particularly in the sections titled "What features are not supported" (no exceptions or panics, so e.g. indexing has to return an Option in case it's out of bounds) and "What controversial design choices are made". Some pithy remarks towards the end as well.

To follow HN tradition and find the most controversial topic to discuss, my guess is it's either not allowing name shadowing, or divide by zero equals zero. Or the site not working without javascript (see the section on that near the end, but you'll need to turn on javascript to read it I guess)

View on HN

I did like seeing the FAQ become more and more deranged the further I scrolled!

I'll perhaps be the first to jump on the 1/0 != 0 hate train though; they mention they designed the stdlib to avoid the partial-function pitfalls of Haskell's, but the article they linked to support their design decision of 1/0 being 0 mentions that it boils down to division being a partial function - x/0 is not a case division can handle. Would it not then be reasonable to make division return an Option?

It would probably be reasonable but a lot of people would complain because they don't want to think about the zero case all the time, so maybe it's also reasonable to not do that.

I also don't like "Unused definitions, type declarations, etc. are compile-time errors" as I often want to test the validity of a statement, like a type declaration, by compiling before using it. Much prefer warnings.

I don't mind the disallowing name shadowing, but I really, really hate (I mean that) websites that are just good ol' text and the odd picture that require Javascript. The excuse of "we used React, it's easy" seems odd given that HTML is much easier.

> We use JavaScript for the online code editor.

Doesn't mean the whole site needs it though, just one page.

I think go made the same silly choice.

Make those warnings in debug/test builds, and errors in prod builds.

> Unused definitions, type declarations, etc. are compile-time errors

Any language that does it, is beyond usable (notably go and zig). Like, I would literally fork the compiler before using them with that “feature” on. It’s completely braindead thing to do — like okay, have a separate production release mode and make it an error there. But for quickly testing out stuff, you will inevitably comment something out, which makes a variable unused. Commenting that out will also make something else unused, so you literally have a recursive problem with some random depth, and depending on how deep it goes, you will literally lose all of the context on what you wanted to debug in the first place.

There is literally zero advantage of this idiotic bullshit, my proposed solution of doing it only in prod release gives all the benefits with none of the negatives.

Zig and Go both let you silence the error with `_ = myvar`. It can still be annoying, but it avoids the recursive problem you mentioned. Language design is hard, and it's best to not just assume that people are "idiotic" for not thinking the way you do. Turn the volume down a bit, and maybe find a synonym for "literally" for the sake of variety.

So now you just silenced a warning and transformed it into a semantically correct form you have no way of recognizing from afar, making the original problem 10-fold worse.

It is a brain-dead feature, verbatim if you prefer that word.

You know, I used to think that design was a nuanced grappling of complex tradeoffs, but you convinced me: those you disagree with are just "brain-dead" "idiots". I think there is a relevant quote by Charles Bukowski about confidence, but it escapes me...

There often is nuance. I haven’t seen any positive for this feature, nor here, nor in the relevant github issues for the languages in question, which were quite argumentative.

But feel free to give me the nuance to this design issue that you so miss.

I can't imagine why they would be argumentative with a gentle diplomat like yourself.

I was only a spectator.

What you describe is exactly what the V compiler does.

It produces warnings for unused variables, and warnings become errors, when you want to compile a production executable with -prod , so you can get both the benefit of prototyping without losing your flow, and you are still required to cleanup after that, when you are finished, before release.

The situation here is not unlike the problem with null: If you allow null in your language, you will have NullPointerExceptions at runtime. Unused local variables (and other unused constructs) are known to be correlated with bugs (see e.g., Xie and Engler, 2002), so if you allow them, you will allow these bugs. So, by enforcing the absence of unused constructs, a large class of bugs is eliminated.

But I agree, this can be cumbersome. So, Flix allows any unused construct to be prefixed with an underscore to mark it as unused. (But underscored things cannot be referenced.) This seems like a pragmatic trade-off.

(I am one of the developers of Flix).

I still think it is a bad decision, you still have to recursively go back a random depth and a random number of modifications on each level for no benefit (it could be an error in release version, but it is just annoying for development).

What benefit does it have in development-mode?

I think the most controversial feature is actually its effect system. Unlike division-by-zero, which is typically a rare occurrence, the effect system permeates the language and must be learned before one can write useable programs. This requires a new and refreshing mindset: I write pure functions, but inside each function, I can use mutable data structures to get the job done!

(I am one of the developers of Flix)

Reply on news.ycombinator.com