3 ms·

It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little

It’s as much about what Elm _doesn’t_ have. The biggest thing here is that Elm does not allow mutation. This turns out to be great because it eliminates little pockets of state that make your app’s behavior hard to predict and that eventually cause bugs. 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. Elm also removes classes, inheritance, == vs ===, and a bunch of other JS junk drawer stuff that turns out to be unnecessary when you have immutability and a thorough type system. “Perfection is not when there’s nothing more to add, only when there’s nothing more to take away.”

BatFastard 9y ago
Trying to understand, I am still looking for my next front end language. Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?
kevmo314 9y ago
> 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.

BatFastard 9y ago

Trying to understand, I am still looking for my next front end language. Isn't immutability a problem in a garbage collected environment? I come from a C++ and ActionScript background, and on the ActionScript side garbage collection was a major issue. Would I not have the same if not worse issues in Elm?

kevmo314 9y ago

> 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.