[brigandish]

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.

[jorkadeen]

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).

[kaba0]

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?

[kaba0]

> 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.

[delian66]

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.

[sekao]

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.

[kaba0]

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.

[sekao]

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...

[kaba0]

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.

[sekao]

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

[troupo]

I think go made the same silly choice.

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

[rmuratov]

> We use JavaScript for the online code editor.

[brigandish]

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