Vs. hackett about lux HOT 1 CLOSED

I think Hackett is still too immature to go around picking fights with it.

For all I know, it may not even be around anymore within a year.

I don't want to be dismissive, but in the time I've been working on Lux, I've already seen a few languages that were more mature than Hackett get abandoned by their creators, so I want to wait a bit longer until I treat Hackett as an actual rival.

However, if you're fine with a quick summary of differences, here I go:

• Hackett's target platform is Racket. Lux's is "anything that could possibly run Lux" (i.e. JVM, JS runtimes, CLR, Python, Ruby, even native). I'm not sure if Hackett's author is thinking in a practical way about this choice...
• Hackett tries to be Haskell with parentheses. Lux tries to expose the innards of the compiler and the type-system to the users so they can make anything they want out of it.
• The Lux compiler is aware of Lux's type-system, but Hackett's type-system is based on meta-data and only works at the macro level. In some ways, this is a point in favor of Hackett, but I'm still not sure if Hackett's method can provide all the integration with the compiler that Lux demands.

With that said, I'm intrigued by Hackett's way of doing types, and I read the paper from which the author got the idea.

I'm currently thinking if there is some merit to switching to that system in the future, or if I'm better off sticking to what I have.

But currently, the only interesting thing Hackett has over Lux is that particular type-system design.

Note: Hackett's method implies that the language must actually be dynamically-typed and have its type-system bolted-on (which makes sense for Racket).

I'm not sure if I'm comfortable with that, as some Lux users will undoubtedly abuse that and then that will cause trouble to the rest (which is why I'm not a fan of gradual typing).

from lux.