6 ms·

It is interesting that the message locking the post seems to portray engaging with people with opposing views about design decisions as taking time away from wo

by geofft 8y ago

It is interesting that the message locking the post seems to portray engaging with people with opposing views about design decisions as taking time away from working on Elm, instead of being itself a form of working on Elm! Maybe Elm needs some sort of "Please do not use this language in production" sign, and no "Community" link at the top of the home page. There's nothing wrong with a group of folks making a language for themselves / their employers, perhaps putting it on GitHub because why not, but not having a home page at all and making it clear that this isn't a stable language for others to use and they will put much more emphasis on the feedback from their own experiences than from others'. There's definitely nothing wrong with them doing that until they get to a 1.0 they're happy with, and then releasing it to the community.

krainboltgreene 8y ago
> Maybe Elm needs some sort of "Please do not use this language in production" sign That's the point of 0.X.Y supposedly.
- MBCook 8y ago
  I think the problem there is that far too many projects live in that world for years and years and years despite being obviously used in production. At this point if a project has been around for a long time and has version numbers like that I just assume it’s not real semantic versioning.
- geofft 8y ago
  I looked at http://elm-lang.org/ http://elm-lang.org/ and the "Install" link (to make sure there was no comment about not using it in production). There is no mention of the version number anywhere. There are, however, testimonials from (what sound like) real companies using it in production.
  - lallysingh 8y ago
    And that counts a lot more than any version number - advertising it for production.
ModernMech 8y ago
> taking time away from working on Elm, instead of being itself a form of working on Elm! Indeed. I think somewhere along the way the line between "programming language" and "programming language implementation" has been blurred, where the language is the implementation. It used to be that in designing a programming language you didn't have to write a single line of code. e.g: https://en.wikipedia.org/wiki/ISWIM https://en.wikipedia.org/wiki/ISWIM I don't think there's anything wrong with the implementation being the language definition, but there has to be time left for reflection. > Maybe Elm needs some sort of "Please do not use this language in production" sign Except Evan has explicitly been pushing Elm for use in production. Like, hard. He even tells you how: http://elm-lang.org/blog/how-to-use-elm-at-work http://elm-lang.org/blog/how-to-use-elm-at-work
G4BB3R 8y ago
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 production, due to it's type system. Removing native modules was needed to keep the language guarantee to not crash in runtime for every program that compiles.
- 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

by geofft 8y ago

krainboltgreene 8y ago

> Maybe Elm needs some sort of "Please do not use this language in production" sign That's the point of 0.X.Y supposedly.

MBCook 8y ago
I think the problem there is that far too many projects live in that world for years and years and years despite being obviously used in production. At this point if a project has been around for a long time and has version numbers like that I just assume it’s not real semantic versioning.
geofft 8y ago
I looked at http://elm-lang.org/ http://elm-lang.org/ and the "Install" link (to make sure there was no comment about not using it in production). There is no mention of the version number anywhere. There are, however, testimonials from (what sound like) real companies using it in production.
- lallysingh 8y ago
  And that counts a lot more than any version number - advertising it for production.

ModernMech 8y ago

> taking time away from working on Elm, instead of being itself a form of working on Elm! Indeed. I think somewhere along the way the line between "programming language" and "programming language implementation" has been blurred, where the language is the implementation. It used to be that in designing a programming language you didn't have to write a single line of code. e.g: https://en.wikipedia.org/wiki/ISWIM https://en.wikipedia.org/wiki/ISWIM I don't think there's anything wrong with the implementation being the language definition, but there has to be time left for reflection. > Maybe Elm needs some sort of "Please do not use this language in production" sign Except Evan has explicitly been pushing Elm for use in production. Like, hard. He even tells you how: http://elm-lang.org/blog/how-to-use-elm-at-work http://elm-lang.org/blog/how-to-use-elm-at-work

G4BB3R 8y ago

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 production, due to it's type system. Removing native modules was needed to keep the language guarantee to not crash in runtime for every program that compiles.

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