[jnbiche]

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler.

I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.

[tomtheelder]

I would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.

[jnbiche]

Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole.

Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types.

Have you actually tried flow?

[simplify]

I've tried to use flow three times now, but the tooling just isn't there yet. It might be better now, but Facebook doesn't seem to invest heavily in developer UX.

[jnbiche]

What problem did you have?? I've been using Flow.js for work for several years now, to great success. I feel very uncomfortable now writing plain JS.

[simplify]

For some reason I could never get flow's in-editor errors and type information to work. Personally I use TypeScript. Their sublime support is nice and fast.

[fbonetti]

Cons of using Typescript:

* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.

    function add(x: number, y: number): number {
      fireTheMissiles()
      return x + y
    }

* It's impossible to validate that external JSON data is the correct type at runtime. If a JSON API returns something weird, you're going to get a runtime error.

[jnbiche]

> Lack of purity.

I agree. Which is why I said "many if not most" benefits, not all benefits.

> It's impossible to validate that external JSON data is the correct type at runtime.

Not sure I understand what you're saying. Of course you'll get a runtime error if your external JSON is the wrong type, what else could you do? Accept the data and enter an inconsistent state?

However, similar to the Elm JSON validation, in Typescript and Flow, you can write schemas to to runtime validation of external JSON. There are multiple libraries for this.

[Skinney]

I've used both Typescript and Flow, and this breaks down in practice. At least, it did for me.

Problem with both Typescript and Flow is that it requires discipline from you, your team, and those who provide third party libraries. If someone was lazy and inserted `any` at a key location, you can start having familiar bugs even if the type checker tells you everything is fine.

[jnbiche]

This is trivial to avoid with a linter (which is a good idea to use anyway with JavaScript). For Flow, there's an eslint plugin that allows you to raise an error on the use of any weak type, such as `any` [1]. I'd be very surprised if the same doesn't exist for TypeScript.

1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...

[Skinney]

Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/

I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.

[jnbiche]

> Cool! Does it enforce third-party libraries as well?

Yes, as long as you lint those libraries, too.

> A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type?

That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm?

> But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be

In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.

[Skinney]

It's not different from Elm. My point was that Elm forces you to do it, there's no way around. With Javascript+Flow or TypeScript, you need discipline to end up with code that is as reliable as Elm.

Me, personally, I take short-cuts when I'm pressed for time, stressed, or in a bad mood (which happens more often than I'd like to admit). I can always improve the code later (which turns into never). In Elm, I can't cut corners (as easily). This makes me write better code using Elm, which in turn makes me happier.

You --can-- get the same experience with Javascript, but it does require more from you, the developer.

[fulafel]

That's like saying an angry bear has many of the benefits of a bicycle. It may be factually true but the downsides of riding an angry generally outweigh the benefits, and anyway it's a different kind of thing altogether from a bicycle.

[laughinghan]

It's nothing like that. The downsides of riding an angry bear relative to a bicycle also apply relative to just walking, to the point that it's always better to just walk than to ride an angry bear for transportation. The downsides of Flow.js or TypeScript relative to Elm don't at all apply relative to vanilla JS, it's often better to use them rather than vanilla JS.

[gcanti]

working on a fp library for TypeScript if you want to take a look https://github.com/gcanti/fp-ts