Flix – Next-generation reliable, concise, functional-first programming language
Reading through the Design Principles [1]:<p>&gt; Separate pure and impure code<p>So IIUC, the effect system [2] means impurity is contagious. This seems reasonable to me, though I wonder what that means in practice. `Console.printLine` is impure [3], and presumably any debug logging would be too; the contagion might spread pretty far. I wonder if this is why seemingly pure functions like `Array.find` are flagged as impure [4].<p>&gt; Principle of least surprise: ... and when there is no immediately obvious default, we should not have a default at all, but force the programmer to be explicit about his or her intention.<p>I like that they called this part out. I&#x27;d wager most code really doesn&#x27;t have sane defaults, just the defaults that made sense to the developer at the time.<p>&gt; Local type inference<p>I find that in languages with type signatures (without inference), folks lean on the type to convey information, and in dynamic languages like Clojure, folks lean on good naming. Based on my not-much experience with type inference, the code ends up with neither. Sure the compiler can figure out what it is, but the humans not so much.<p>&gt; Uniform function call syntax: ... the function call length(xs) can also be written as xs.length()<p>I wonder what their motivation was for this; my guess is to appeal to both FP and OO devs. IMO, having multiple ways of writing the same thing is likely to lead to unnecessary style wars.<p>&gt; Private by default: ... declarations are hidden by default (i.e. private) and cannot be accessed from outside of their namespace<p>I like this a lot, though I foresee running into issues with unit testing, and thereby arguments over at what level things should be tested.<p>&gt; Bugs are not recoverable errors: ... For recoverable errors, we should enforce that they are checked and handled. For program bugs, we should terminate execution as quickly as possible<p>This seems reasonable to me, but I&#x27;m curious what counts as a &quot;program bug&quot;, or how to know that some error is recoverable.<p>&gt; No null value<p>Meh. I&#x27;ve think Option is just null with extra steps. NPEs  arise because of method invocation, e.g., `x.foo()` while `x` is null. In FP languages like Clojure, NPEs don&#x27;t really happen since `x` is just a value being passed to a function. With nil-punning and reasonable behavior of core functions (e.g., `(get m k)` yields nil when `m` is nil), an unexpected nil is really a type error.<p>&gt; No dead or unreachable code &#x2F; No unused variables<p>Perhaps it&#x27;s from my REPL-driven, exploratory style of development, but I think having to constantly comment out code I&#x27;m ambivalent about just to get it to compile would be a bit annoying. I&#x27;d think something like this should be a compile option, but I think that runs afoul of their &quot;One Language&quot;&#x2F;&quot;no flags&quot; principle.<p>&gt; No variadic (varargs) functions<p>Having worked with enough Clojure, and seen enough bugs when using `apply` on vararg fns, I think this is a good choice. IIUC, their approach would replace, e.g., `(+ x y z ...)` with `(sum [x y z ...])`.<p>&gt; No binary or octal literals: ...  It is our understanding that these features are rarely used in practice.<p>Until you need to do some bit-twiddling; maybe they still have hex. I wonder what they considered the downside of including it.<p>[1] <a href="https:&#x2F;&#x2F;flix.dev&#x2F;principles&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flix.dev&#x2F;principles&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;flix.dev&#x2F;innovations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flix.dev&#x2F;innovations&#x2F;</a><p>[3] <a href="https:&#x2F;&#x2F;api.flix.dev&#x2F;Console" rel="nofollow">https:&#x2F;&#x2F;api.flix.dev&#x2F;Console</a><p>[4] <a href="https:&#x2F;&#x2F;api.flix.dev&#x2F;Array" rel="nofollow">https:&#x2F;&#x2F;api.flix.dev&#x2F;Array</a>