From the Gitbook: [0]

    (;module: {#;doc "This will be our program's main module."}
        lux
        (lux (codata io)
            [cli #+ program:]))

    (program: args
        (io (log! "Hello, world!")))

I know syntax is subjective, and a common source of bikeshedding. But I'm puzzled by this choice for defining a module and its imports. It requires much more cognitive load to remember that "(lux (codata io) [cli #+ program:]))" means a combination of "import lux/codata/io", "import lux/cli as cli" and "import program: from lux" than, well, something more straightforward.

Especially for a new language in the modern programming world where there exist many dozens of languages, it's important that your "learning curve" be smoothed out where possible. Not to say that advanced concepts shouldn't exist -- a beginner's not likely to easily handle learning monad transformer stacks when picking up Haskell -- but rather that "simple" things should be kept simple. Show me a codebase where there are no imports, and I'll show you a codebase that's so trivial that its utility is minute. Importing other code is something 99% of all source code files will need -- so why make it complex and overwrought?

User Experience (UX) has gained proper or closer-to-proper attention over the past decade or so, Developer Experience (DX) is something that's still not thought of often enough sometimes.

[0] https://luxlang.gitbooks.io/the-lux-programming-language/

"Like Lisp, Lux runs on the Java Virtual Machine but promises more power and flexibility than its predecessors"

Literally the first sentence. I think the author meant "Like Clojure, Lux runs on the ..."

I love it when new languages come out like this. I'm always interested to see what new ideas they bring, and what justifications they have for creating a new language. I'm not really one to chase the new and shiny, but I have a soft spot for functional languages, despite being a longtime C++ developer.

A link to the GitHub repo would have been better.