3 ms·

> It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the perform

> It also seems like it would be very hard to bolt this on to JavaScript; you’d have to break existing code and then your runtime would miss out on the performance benefits of assuming everything is immutable. Or you could have a runtime development option to detect mutations similar to existing redux-type solutions. This also still doesn't explain why the need for a new language instead of decoupling the two. As I mentioned in another comment, all these features make working in Elm probably a superior experience, but I fail to see why it's mandatory and the mandatory-ness is what makes this a much harder sell.

zachrose 9y ago
Yes, but using Elm has convinced me of the significant difference between runtime checks and compile time checks. In a large enough codebase, reaching every code path is non-trivial. It’s very easy to write code that only runs when it gets a certain response from a server, and at that point you need an entire integrated environment, plus a humongous space of configuration and use cases. (Or highly detailed mocks and 100% test coverage, which is even more rare.) By contrast, you get that much certainty every time an Elm program compiles. Maybe it’s possible to statically analyze JS to the point where you can get the same guarantees as compiling from a stricter language, but that seems very very hard.