Hope to be able to bring Linux back at some point. Unfortunately there wasn't enough users to justify spending development time on it. It's hard to tell if the user count was low because of lack of interest of issues with app itself. It's also ironic that Linux is the hardest platform to support. It had too many pieces outside our control that would break. If/when we can get back to it I'd like to avoid Flatpak and take an approach that we can have more control over. Possibly a static build and maybe even look into native package manager integration.
Great game, cleverly demonstrates a fundamental problem with creating rules/laws. I've wondered if focusing on the goal/intent when creating rules would be more effective? For example, instead of just a rule that says "No vehicles in the park", you could say, the community wants the park:
- to be safe
- to be peaceful/relaxing
- to accommodate physical activities/games
For these reasons, we don't allow vehicles that will unnecessarily compromise safety and/or make a lot of noise.
Of course the goal/intent I've written suffers from the same problem as the rules did, the definitions are ambiguous, but I think there's a distinction between capturing the spirit vs the letter of the law. It's a guide for why the rules exist and when they should or shouldn't be applied. It's not perfect, but, I think it's an improvement of just listing rules. If capturing/publishing the reasons for rules alongside the rules was normalized I wonder how different things could be?
D's actually worse than Zig in regard to point 3. Kristoff's example demonstrates why. In D you would have to change the "if" to a "static if", D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.
The bigger issue D has with this example is that normal parameters are always runtime. If you wanted this to work in D you would need to implement 2 versions of "double", one that takes n as a template parameter and one that takes it as a runtime parameter. D keeps comptime and runtime parameters separate, making comptime-knowness a "parameter color" which in practice means having to implement things twice if you want it at comptime and often in different ways. There are some things that can work with both but it's small subset of both.
<i>D will always evaluate normal "if's" at runtime even if they are comptime-known, it will not do this automatically for you.</i>
WRONG. if in a CTFE function works without problems.
static if has nothing to do with CTFE. static if is conceptually a beefed up proper #ifdef/#endif.
The biggest issue D has is all the FUD and misconceptions that are propagated about it.
