Elm from a Business Perspective | Hacker News Reader

Elm from a Business Perspective

gizra.com

166 pointsamitaibu75 comments

Well.

Summary: "I have no idea about the technical criticism or type classes, but we use Elm and it works for us. It's easy, you are productive quickly (quicker than with React/Angular), it prevents bugs, devs like it, and so it saves us money."

It's nice to hear that a company is able to utilize Elm effectively.

It would be nice to know how big their 5 Elm projects "in various stages and different scale" are to judge whether Elm in it's current form is a good fit for larger apps. Especially since the Elm library ecosystem is still very immature, so experience with building good, reusable libraries is not that great.

Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell.

In terms of maintainability (refactoring, etc) you can't get much worse than Javascript, so Elm will probably be a win there, regardless of a limited type system.

As long as you don't have to build and maintain lot of required libraries yourself, that is.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell.

Elm certainly has a lot of boilerplate compared to Haskell, but that might not be a fair comparison as they don't really have a shared use case. Elm ends up with considerably less, in my opinion, than something like React/Redux.

> Elm certainly has a lot of boilerplate compared to Haskell

This is not true based on my experiences with Elm and my knowledge of Haskell.

Could you elaborate on why you are certain of this?

Haskell has much more powerful polymorphism as provided by typeclasses and various extensions like Multi-parameter typeclasses. Haskell, more than any other production-ready language, is able to encapsulate the essence of "doing the same thing in a different context", which means you can easily write code that is reusable to a degree not imaginable in most languages.

For example, the expression "fold", from Data.Foldable, is capable of doing anything from concatenating all the strings in a set to adding up all the probability distributions in a sequence. This is a contrived example, but it's super useful in practice. It's hard to imagine all the code reuse you can get, especially as a library author, without using Haskell for a while.

The most obvious cases are Ord and Eq, where things like maps and sets can contain any orderable type, rather than just a few types like String and Int.

Instead of abstractly arguing over "writing generic code", here are some concrete examples I came up with when running down a random Haskell file:

* Thing.map :: (a -> b) -> Thing a -> Thing b instead of deriving Functor (or Applicative, Monad, Generic, ...)

* showThing :: Thing -> String, readThing :: String -> Maybe Thing instead of deriving Show/Read

* decodeThing :: Json.Value -> Maybe Thing, encodeThing :: Thing -> Json.Value instead of deriving From/ToJSON

* lenses definitions instead of makeLenses ''Type

* things like

    update (Event childEvent) model -> let (m, fx) = Child.update childEvent model.child in ({ model | child = m }, Fx.map Event fx)

instead of using lenses

* append :: (a -> a -> a) -> (b -> b -> b) -> (a, b) -> (a, b) -> (a, b) instead of reusing the Monoid instance on tuples

* toDyn :: (a -> TypeName) -> a -> Dynamic, fromDyn :: (a -> TypeName) -> Dynamic -> Maybe a instead of deriving Typeable

* things like type StateLogger st = { log :: [st], current :: st } and then writing StateLogger.map, StateLogger.return, StateLogger.andThen, StateLogger.modify, StateLogger.tell instead of just type StateLogger = WriterT [st] (State st) and getting all of that for free... not only that, but now you can use lenses for manipulating a deeply nested state as well, because guess what, Control.Lens.Zoom is written generically

And those are just the possible, but cumbersome things. There's stuff that's impossible to do:

* free monad custom DSLs

* GADT datatypes for typesafe request/response communication

* existential quantification in ADTs

Now this is very down-to-earth get-things-done Haskell code. All these things are there because they make the code simpler, easier to understand and eliminate repetition.

> Would also be nice to know how they deal with boilerplate, which is a big annoyance with Elm in my opinion when you come from, eg, Haskell.

We have over 55,000 lines of Elm code in production at http://noredink.com and it's now the majority of our front-end. Students use our site to answer millions of questions per day, and they've answered over 2 billion questions total. I think this qualifies us as a "big project." ;)

Our Elm code is about as DRY as our JavaScript code, and adding language features to squeeze even more DRYness out of it is way down my priority list. When I think about ways I want Elm to improve, I'm thinking about better support for server-side rendering and asset management (e.g. code splitting), not wanting to add type system features.

I'm always a bit confused by "I tried Elm and disliked how it wasn't enough like Haskell" posts. PureScript is a fine language that's already on board with this design philosophy. Instead of lobbying for Elm to change, why not use PureScript? There's plenty enough room in the programming world for both languages to coexist!

The creator of Elm works for your company though [1]. Seems like your experience is going to be a lot different from the average developer because you can probably walk 20 steps to the designer of Elm to ask a question. I haven't used Elm just raising the point.

[1] https://twitter.com/czaplic

Not only does the creator of Elm work there but so do the people who know Elm more than anyone else in the world. Literally. While it's proof Elm can work it's not really a fair comparison for teams wanting to adopt it.

That's true for me, yes, but the author of this article works at a totally different company halfway around the world. :)

That's only been a recent development, rtfeldman has been using Elm for noredink for a long while before that.

We hired him because we'd already been using Elm for awhile and were so happy with it we wanted to contribute financially in addition to contributing with the libraries we open-source. :)

My boss wrote more about it here: http://tech.noredink.com/post/136615783598/welcome-evan

> Our Elm code is about as DRY as our JavaScript code

Not to be flippant, but that's not saying much.

JavaScript code is or can be extremely DRY. I have noticed this especially on a redux (inspired by Elm's architecture) codebase. The pitfall is that JavaScript is very unsafe and hard to read.

I've worked with TypeScript too, and there I started to notice more repitition and boilerplate, although IMO It is very well worth the safety.

Javascript is dynamically typed though.

And Typescript has generics or circumventing the type system with :any to enable reusability.

Exactly my point, dynamically typed means writing less boilerplate. At the cost of safeness and mantainability.

TypeScript's any is more for compatibility with js libs though.

Yes, in a sane codebase, you (almost) never use <any>. 98% of the time, if you type <any>, you're being lazy.

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana".

Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

> Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple.

I just straight-up disagree with this. If Elm added Haskell-style typeclasses today, and we refactored our whole code base at work to use them, I bet it would save us less than 1% LoC.

This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language.

What reasonable response can anyone make to that claim, except "I really don't think that's what the language should focus on improving?"

Yes, that's true, but I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case. So it could be that half of your code is "library" code that could be open sourced - if it could be written generically with typeclasses.

For example, Rust has typeclasses (called traits) and Rust has a lot of libraries that do the right thing for you.

    fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option<T>
            where T: From<&'a str> {

        tuples.iter()
            .filter(apply(second, i))
            .map(first)
            .cloned()
            .map(<&str>::into)
            .fold1(T::op)

        //op just concatenates, but Cow<'a, str> does not satisfy Add
    }

Here, the functions first and second are taken from tool.rs, fold1 is from itertools, the type Monoid and the function op is taken from monoid.

I did have to write the delayed apply function myself, though. It's definition is:

    fn apply<A, B, C, F, G>(mut f: F, a: A) 
    -> impl FnMut(&B) -> C // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
             where F: FnMut(B) -> G, // must not be `for<'r> FnMut(&'r B) -> G`, because regular functions do not implement it
                   G: FnMut(A) -> C,
                   B: Copy, // for dereferencing
                   A: Clone {

        move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }

I think that could also be in a library somewhere

> I bet you some of the functionality that you wrote can be factored out into a more generic library that applies to everyone's use case.

Of course. We publish quite a few such libraries, in fact. :)

Search for "NoRedInk" on http://package.elm-lang.org

> This is such a weird thing to try to respond to. It's like a group of people started insisting that JavaScript's big problem is all the parentheses, and accusing JavaScript developers of sticking their fingers in their ears about the most obviously glaring weakness in the language.

That's a straw man which isn't directly analogous to the question of typeclasses. The reason is because parens are a syntax concern, which is understood at this point to be largely a matter of personal preference. Typeclasses are a language semantics matter. They could add new levels of reuse for identical operations over different types, and they've done exactly that for other languages.

> What reasonable response can anyone make to that claim, except "I really don't think that's what the language should focus on improving?"

Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses to pick concrete examples from NoRedInk's open source Elm and show you how they could be improved, disproving your hypothesis that typeclasses wouldn't really help.

(edit: removed redundancy around "burden of proof")

> Well, the burden of proof should be on the proposer: that the feature is useful. A good next step would be for someone who's interested in persuading you of the importance of typeclasses

I agree! That would make for a much more straightforward discussion. :)

As an example, I see code all the time with many showX functions whose sole purpose is to turn come ADT into a string, this is the kind of boilerplate that would be reduced with some kind of abstraction mechanism.

Same for map operations, fold, etc.

Then there's other things that would benefit from further abstraction, like being able to compose apps or update functions without boilerplate.

These are just a few examples. What else do you need for it to feel like abstraction beyond simple functions is a useful feature?

To be clear, I'm not saying it's not useful! No need to convince me of that. :)

What I'm saying is that even useful features come with both benefits and drawbacks. For example, I think user-defined typeclasses would add significant complexity to the language and especially to the library ecosystem.

I'm not saying "these are worthless ideas," I'm saying "these benefits wouldn't improve my life enough to justify the cost." :)

Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is.

Perhaps you can't see the benefit and you're happy writing 10 implementations of "show", but don't claim there is no boilerplate.

For the record I don't care if it's typeclasses and I wouldn't want to see Elm turn into haskell. I'd just like some other type of mechanism for abstraction besides extracting to a function.

> Your claim was that Elm isn't boilerplate heavy, but without these types of abstractions, it is.

You seem very certain of this, so surely finding some real-world code examples to back it up should not be too difficult, yeah? :)

> Perhaps you can't see the benefit and you're happy writing 10 implementations of "show"

Like I said, I do see the benefit, but don't think it's worth the drawbacks.

Also, "deriving" saves you from writing "show" implementations, not typeclasses, so I'm not sure why you're bringing that up.

Hi leshow, can you be more concrete? If I have a record

  `data Foo = Foo {fooA :: Text, fooB :: Text}`

then I must write a method `show :: Foo -> Text` for it. It is immaterial if I write

  `instance Show Foo where`
  `   show foo = (... implementation ...)`

  `shooFoo foo = (... implementation..)`

I save no code with typeclasses (at this point at least). (I do save code with the magic "deriving", but that's not part of the typesystem; it's just the compiler implicitly generating a bit of code for me.)

Likewise, map operations, fold. They need to be written and used.

I'm sceptical of Elm's claim that typeclasses aren't useful, but your post doesn't show what it sets out to, because it lacks concreteness.

Out of your post, it is only when you get to function composition that typeclasses can theoretically help — but the question isn't, can they theoretically help, it's do the help in practice.

So can you show some example? To meet the challenge and provide convincing evidence that a language without typeclasses is lacking, you would need to say "This is what the code is. And this is what it could be with typeclasses". Unless you do that, Noredink's claim that their code wouldn't be simplified with typeclasses stands.

I do not think you are obliged to do this. It is perfectly legitimate for you to ignore my message. But I think both sides can agree that this is what would be convincing to the anti-typeclassists.

Of course you save no code on definitions. Some may even get more verbose.

You save code on usage, because you can use generic functions that will work for any instance of Show, instead of specifying them for every type.

The ridiculous comparison with parens only hurts your message.

I think a more apt comparison is comparing Elm to Go missing generics. Without do-notation I imagine that elm code is filled with a lot more awkward case branching.

My major question is: how do you write reusable code without type classes?

It's not really possible, as far as I can tell.

Are you trying to say that in the 30 years of time between the discovery of Lisp and the discovery of typeclasses, no one wrote reusable code?

Come now, don't hyperbolize: the statement is strictly about Elm, for which typeclasses are a proposed generics mechanism and for which userland generics don't exist right now.

As far as my sleep deprived brain remembers, Lisp is not statically typed... :P

Well of course there are ways to write reusable code without type classes. But let's say for the sake of argument that that's really what you want. You can in fact implement ad-hoc polymorphism, or something very close to it, without type classes. Type classes can be seen as a way to implicitly add a set of values to scope, but this can be done explicitly by using a record type. Consider (I'm guessing at syntax, I don't know elm):

    -- Monoid as a record type
    type Monoid a = {
      empty: a,
      append: a -> a -> a
    }

    -- Using this to make a generic concatenator 
    mconcat : Monoid a -> [a] -> a
    mconcat m = foldl m.append m.empty

    -- Instance of Monoid for strings
    MString : Monoid String
    MString = {
      empty = "",
      append = (++)
    }

    -- Instance for ints
    MInt : Monoid Int
    MInt = {
      empty = 0,
      append = (+)
    }

    -- Use the generic function
    unlines : [String] -> String
    unlines = mconcat MString . intercalate "\n"

You'll note here that the actual function signature for mconcat looks almost exactly like its Haskell counterpart, just that the Monoid instance is a regular argument like any other.

Of course the downside is that you have to pass in the instance argument to any "type class polymorphic" function, so you lose a bit of conciseness but not much in the way of expressiveness. And you actually gain a bit, because instances are explicit (for example, you could make an instance of Monoid Int which used 1 and (*) instead).

I'm not sure if this pattern is used anywhere in extant Elm code, but this is a common way to implement type classes under the hood in languages that support them, and the approach seems doable in elm.

I'd like to refer you to the article that was posted earlier today on exactly this technique in Elm:

http://reasonablypolymorphic.com/blog/elm-is-wrong

I formulated it badly I guess.

I knew it's possible, s we discussed in the "Elm is wrong" comment thread though, this technique get's awkward quickly.

Is that 55,000 lines of elm in a single large project or across all projects?

A single large project.

We've also split out several pieces of it into libraries that we've open-sourced, but I'm not counting those.

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper (https://github.com/NoRedInk/take-home/wiki/Writing-your-firs...) that we cannot access?

Anyone can write a native module. You can't publish it, but you can use it in your project.[1]

[1] http://faq.elm-community.org/#why-doesnt-the-elm-compiler-fi...

Native modules are accessible to anyone. Unfortunately the link you provided is a little out of date despite being the top hit on google. Here is an example of a native module that works with 0.17 though: https://github.com/evancz/elm-markdown/blob/master/src/Nativ...

Yeah I figured the "rules" to write a native module for a while, but there is no tutorial, no support at all, which makes me rather uncomfortable, and I am never confident with that code.

The academics always miss this part. They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism. When in reality pragmatism in software engineering is mostly about making things obvious enough at a cheap enough price point. This is why golang is so popular even though all the academics on r/programming hate it.

Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.

This is interesting because Elm has been removing features that Evan considers "too hard" and confusing for the average developer. I'd argue it's not "academic" any more (though it might be interesting for an academic who wants to do UI).

Yes, that is my point. I don't think Elm is "too academic". I think it strives for pragmatism in real world engineering scenarios and that is why it gets flak from a certain segment of the programming community. Similar to how golang does.

Is it truly because they are "too hard" or is it because their current implementation in the language falls short? I was pretty sure in at least one of the cases Evan mentioned the possibility of revisiting it later.

Other languages don't make these choices and end up with things like Python's async/await.

I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.

> They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism.

Alternatively, perhaps many academics don't care about pragmatism and appreciate elegance and conciseness for their beauty. Admittedly I might be projecting, but part of the reason I have considered getting a PhD is to stop having to concern myself with the interests of the industry and money.

That's not what I've observed. The discussions actually turn out to be quite inflammatory when these matters are involved. Even folks that claim to have PhDs in language design consistently confuse these concepts. That's the only way I can explain all the condescending remarks when it comes to things like type systems, monads, curry-howard correspondence, etc. In fact the above article is a response to one such inflammatory and condescending blog post by a programmer who clearly values theoretical beauty and specific patterns that typeclasses enable above software engineering pragmatism. Although I can see how typeclasses help in cutting down boilerplate in this case his tone does not help make that point.

I'm no stranger to abstract and theoretical beauty. My undergrad and grad training is in pure math but I also understand that theorems and proofs don't necessarily lead to good software engineering in the large. So valuing the abstractions is great and all but using it as the ultimate arbiter of good language design is not.

There are many points to respond to here.

1. Evan (the Elm author) has pledged to support type-classes, it's on the issue tracker, and because he believes that they are useful.

2. "The academics" is a mischaracterization. I use Haskell and PureScript professionally and share the same problem of the "Elm is Wrong" author, which is that it's impossible to do any generic programming.

3. Generic programming is important for something as simple as inserting my own data types as keys into a dictionary. So is being able to write "show x" and just have the thing showed if it has the instance of a showable class. Or to parse a nested data structure of various types from JSON.

4. Being able to use my own types as keys in a dictionary is pretty pragmatic, I think. A typical pattern in ML-style languages is to wrap types like Int in a UserId type that just wraps it and protects it from being mistakenly used with other Ints. Now try to make a dictionary of users via the UserId type. Nope.

5. "They" in this case aren't concerned with elegance or concision for the sake of it, but because the features under discussion help them do their job better, avoid mistakes, reduce maintenance cost, and that's good for business.

6. Go has non-academic, purely pragmatic problems that are orthogonal to its popularity, as does PHP or nodejs.

None of the things under discussion are difficult to implement, novel or exotic. Given that other languages like PureScript exist under the same domain and from the same family of languages, we have the luxury of holding other languages up to the same standard. In this particular point, Elm is a -1.

And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. The author of "Elm is Wrong" might have good intentions but the tone of that post is so condescending and inflammatory that all the points being made are lost. The title alone already starts everything on the wrong foot.

Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though. Most of these "critical" posts end up just being that. Comparing a language that programmers use every day to ship working solutions to another one that has considerably smaller mindshare and community and then calling the more popular solution a failure because it doesn't have the feature from the more "pure and elegant" language. There is clearly a disconnect in tone and intent across all such posts.

I don't have any horses in these races. Programming languages are just tools and the religious zealotry around them does not appeal to me.

I don't think you get to call people condescending when you just generalised "the academics" to be ignorant of the "real world".

> Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though.

That's what the "Elm is wrong" post did though. It outlined the shortcomings and showed how it was impossible to implement the solution because of somewhat arbitrary limitations to the extensible record system. The tone was way off and made it an unpleasant read, but valid points were made.

> I don't think you get to call people condescending when you just generalised "the academics" to be ignorant of the "real world".

Those are your words, not mine. My comparison wasn't about ignorance but of a different value system that is consistently substituted in discussions about programming languages and the substitution is then swept under the rug. The substitution being as I said theoretical concision and expression vs more easily understandable boilerplate and pragmatism.

> And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them.

This is definitely true. The firmware on your phone is probably written in assembler.

> Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream.

You complain about sitting on high horses while the author did exactly that and got a high-horse response from Evan.

> Comparing a language that programmers use every day to ship working solutions to another one that has considerably smaller mindshare and community

Are you talking about PureScript? Judging by GitHub popularity I'd say both languages are about equal in that regard, but who knows.

> Are you talking about PureScript? Judging by GitHub popularity I'd say both languages are about equal in that regard, but who knows.

I'm not talking about any language in particular. Just a generic observation about the pattern I've noticed across language communities. I'd much rather see less inflammatory rhetoric and more awesome stuff being made in whatever language people enjoy using so that the rest of us can see the technical design decisions and trade-offs involved. As I said in another comment programming languages are tools, they're not religions, so we should stop treating every little shortcoming as an affront to the one true way to write code and ship software.

Re: doing the right thing. I don't think he did. He didn't even bother looking into why the decision was made to take out a certain feature. He just assumed the decision was wrong because it made a certain design pattern he likes hard to emulate.

As I'm writing this I think I've spent too much time on explaining why the quality and approach of posts like "Elm is Wrong" is not the proper way to approach language design discourse. I'm sure it feels good to a certain segment of the population to point things out this way but to the rest of the community, especially other programmers that just do programming as a job all this drama seems quite childish and I think it again goes back to the point about programming languages being tools. When put in the proper context the drama is amateurish.

I agree the blog post wasn't professional, but there was none of that tone where it mattered, the Github issue.

I can see where his frustration stems from though, getting a response like "I don't want to unless you show me a use case" when clearly presented with a use case after spending weeks trying out someone's language can be infuriating. As I said, not very professional, but understandable imo.

> But than again, Elm is not too easy. This means that almost every developer I see that is already involved in Elm is a seasoned developer. Getting experienced developers on board means that they are immediately productive, which means we gain more per hour.

Not really seeing this as a strong point. It feels like the same mindset that drove me away from Scala (and many others [0]!). Sure, it might be good for the company in short term, but what happens when you run out of experienced Elm developers? At least Elm fairs fairly better with having usable samples on their own (clean) site.

[0] https://groups.google.com/forum/#!topic/scala-internals/r2Gn...

I don't think he's saying that Elm is actually hard to learn (like Scala or Haskell).

Yup, Elm isn't actually hard to learn. Nor is Scala (I had a team of people productive with it in under 2 weeks, with no significant prior FP experience).

My interpretation of that sentence was that it's easy for developers familiar with other languages to pick up Elm, but less easy for people with little or no experience what-so-ever.

I think he was contrasting with languages like Haskell and Scala, where even people very experienced with other languages have a hard time picking them up.

You hire experienced developers. Then you teach them Elm.

I looked around at Elm a little bit recently. I use React/Redux daily at work and have been learning Haskell on the side. When I took another pass at Elm it was extremely easy to pick up. I was able to skim through the docs super fast and start writing real code in about 15 minutes.

I noticed myself typing Haskell code a bunch of the time and wondering why it didn't work though. For me, the hardest part in Elm, and Haskell as well, is figuring out how to structure data that is composition in nature or that involve Union types that are records. I can never quite seem to get the dereferencing right.

This typeclasses discussion reminds me a lot of complaints about Go's lack of generics. Even without this "glaring shortcoming" Go became the de facto winner in the ops space, by staying a simple language with a smaller learning surface. Elm could be walking down the same route.

Personally I find composability under The Elm Architecture more of an issue than pure language abstractions.

> Go became the de facto winner in the ops space

Can you explain what you mean by this and possibly provide a source? I'd like to know how the different languages / platforms compare.

I don't get how having type classes makes the learning curve steeper. It's not like the mere existence of type classes means you have to start writing your own and doing functional dependencies and all that.

For a beginner, it just means being able to write filter instead of List.filter or whatever.

There is no business perspective to programming languages. Stop kidding yourself to explain your favorite tool of the week as good for business.

Successful companies have used plain st* languages like PHP and Java, thousands of companies that use the tool of the week go bust. There is no correlation (perhaps you should not use Assembler or COBOL for web development)

If there is any then companies that use the tool of the week do too many rewrites instead of focusing on delivering business value, the correlation is negative if any.

As someone who worked at a large software company that suffered huge losses because of 1) client data loss caused by using unsophisticated tools and strategies and 2) accounting errors caused by a lack of type-safety: I disagree.

I always think that usage of such technologies can be only in some cases – mostly for small companies, which are not sure that this product will be maintained more than few years. Like, it is not that bad to use it in startups, in some small projects, or if you have pretty strong and enthusiastic team with a lot passion, which are ready to dive into new cool technology. Moreover, in the short term it can be even more beneficial, because you can attract even better developers, who like cutting edge stuff.

But the problem is what if this product will be maintained throughout years? Then to support it, you have definitely hire much more skilled engineer than for the same in stable JS framework. I completely understand about types, strict rules how to write Elm code, etc, but there are literally no guarantees that it will be the same after some time, that new developers will pick it up quickly, and, if you decide to rewrite it much later, there is a big chance that you'd have to rewrite it completely (this applies for JS too, but there are quite a lot of success stories of gradual integration of new framework).

To summarize, I don't think it is bad, it just doesn't scale and creates big technical debt, so you'd pay for it later; though it is a great chance to attract very skillfull and passionate developers – so, it is all about risk.

I'm guessing pragmatism and practicality is why they went with Elm over PureScript? If their backend is in Haskell then it seems like they have devs who know it well enough to use PS.

From my limited experience, I would say PureScript sounds more practical. You can choose your own UI engine, and has additional language features that are useful like typeclasses. It also compiles without needing a runtime baked in to the output.

When you hit a wall you can probably work around it in Purescript whereas I feel you are too sandboxed in with Elm and you'd have to start patching your Elm source to get around it.

It's more likely that they tried Elm first and liked it so they thought they might be able to use Haskell as well.

I actually find PureScript quite practical by design and goals (for example the ffi and readable generated code).

I really love this Elm drama. We get to discuss Elm a lot, talk about it, think about it, keep it in out minds. I don't like negativity, but it is good to popularize language, to let people know about it.

I thought this was going to be about the email client: https://en.wikipedia.org/wiki/Elm_(email_client)

You were wrong.

Reply on news.ycombinator.com