3 ms·

Elm is much more stable than every option in the market. Lots of companies with 100k+ loc web apps, and 2 companies with 250k+, with no runtime exceptions in pr

• geofft 8y ago
  "Stable" as in "doesn't crash in production" and "stable" as in "doesn't change backwards-incompatibly" are two almost entirely unrelated uses of the word. Most folks looking for a language prioritize the latter. There's no point in not having runtime ezceptions if your code stops compiling. I understand that removal of native modules was required for maintaining (some interpretation of) the promise of being crash-proof, and that it needs to be done before 1.0. My point is exactly that the language isn't at 1.0 yet. But more than that, my point is about the approach the developers take to the language, not about any specific decision. I'd still have the same comment about an Elm which lacked native modules from day 1, or an Elm where they figured out how to keep native modulea. Not running into breaking changes by luck is different from intentionally prioritizing stability and other people's use cases. It doesn't matter how many people are deploying Elm in production today—it's still a pre-1.0 language and maybe they shouldn't be deploying Elm in production.
  • G4BB3R 8y ago
    I agree with you, but breaking code is not really a problem since elm compiler is fast and has nice error messages. Porting big code bases takes time, but it's very worthy imo.
    • vmchale 8y ago
      > breaking code is not really a problem since elm compiler is fast and has nice error messages. Not true on either front. Elm's compiler does not have good error messages, and breaking code is absolutely a problem.
  • vmchale 8y ago
    > It doesn't matter how many people are deploying Elm in production today—it's still a pre-1.0 language and maybe they shouldn't be deploying Elm in production Maybe the Elm website shouldn't advertise the fact that people are using it in production.
• hellofunk 8y ago
  Lol Elm devs are often bragging about their huge line counts. Meanwhile I rewrote an Elm project in Clojurescript and it removed 75% the line count. Large line count is such a strange metric.
  • G4BB3R 8y ago
    I know that loc is not a good metric, but there is not a better one. A project with 1kk loc will always be more complex software than a 100k loc, so we can compare. Were you using cljfmt like Elm users use elm-format?
    • hellofunk 8y ago
      There's not a better metric? I disagree. I think the best metric is "how much does it ultimately cost to write and maintain the software?"
      • G4BB3R 8y ago
        So Elm could not be better. No runtime exceptions and easy refactor, what else would I need? There is not even comparison to a identical React project.
        • vmchale 8y ago
          no runtime exceptions except for infinite loops lol
        • hellofunk 8y ago
          There is more to consider than runtime exceptions. If it takes one-third or less time to write in Clojurescript, for example, this saves much cost. Even if you add in more runtime debugging, you still save time in writing code, and time saved in the compilation-fix cycle. Then of course, you save all the significant added time required in Elm to do non-trivial things with JavaScript libraries, which is inevitable. One language isn't necessary better, but I do think one can be argued to certainly be less expensive. Give two teams the same project. One team will use Elm and needs to write 20K lines and figure out some complicated JS interop. The other team uses ClojureScript and will need to write 5K lines and not worry about handling JS libraries. Which team costs more money?
• vmchale 8y ago
  >Elm is much more stable than every option in the market. This is false.