With such high praise, I would expect the language to be more popular. What's with the disconnect? My hypotheses:

1) There are no unhappy users because unhappy users just don't use it. 2) HN goes easy on technological curiosities, saving harsh criticism for large projects that deserve it 3) While there may be a widespread lovefest for Elm, there is too much momentum behind current technologies.

Any other thoughts as to what the disconnect is? Moreover, how do we get to a world where the webstack we all use is "a great little webstack"?

[0] https://news.ycombinator.com/item?id=11846707

edit: clarity

Elm is a lot more experimental than Elixir, for instance. Elixir is still built on the classic Erlang BEAM virtual machine. And its syntax is fairly similar to that of Ruby, which is an immensely popular language among web developers. Elm looks like Haskell, though, which very few developers are competent with. It was originally based on FRP, which has long been considered highly speculative and theoretical. But I think by shedding FRP it's growing into a very practical language, and while it has a Haskell-lite syntax, it's considerably easier to use than Haskell.

:D

Somehow, though, convincing them to use a language that almost never has any runtime errors was not a hard sell.

The difficulty I'm having at the moment is just trying to find examples of non-toy application architectures. An application with multiple top-level screens, for example.

For a bit of context, the product I'm working on is a customer-facing kiosk. It'll be driven by a C# ASP.NET back-end. We have several different products using common back-end code but exposing different sets of features to the customer. We're moving from an old architecture that was your standard WinForms UI to something using HTML5 as the UI layer (definitely a big mindset change!).

Right now I'm trying to figure out what the front-end Elm code structure would look like. Is it going to be one huge monolithic Elm project that covers all our cases? Can it be broken up? Does the front-end have to know in advance what screens will be available? (the back-end uses the typical 'load features as plugin DLLs') etc. These are all questions I'm facing right now.

This is especially exacerbated by the recent change from 0.16 to 0.17. The changes themselves seem extremely positive (I jumped in at 0.17, so I'm only going off an impression here) but much of the example material that I've found which might be useful is still using stuff from 0.16 and I'm having trouble wrapping my head around it right now.

So from a commercial dev perspective, Elm, like anything else so new, is massively risky. I'm pushing on for the moment (would love any pointers if anyone has them!). I'm aware of the huge element of "not knowing what I don't know" that I've taken on right now. I'm hoping the payoff will be worth it :)

https://github.com/plentiful/shop

https://github.com/srid/chronicle

https://github.com/CultivateHQ/seat_saver

https://github.com/NoRedInk/elm-blogger

https://github.com/massung/elm-hn

https://github.com/sporto/elm-tutorial-app

https://github.com/elm-lang/package.elm-lang.org/tree/master...

I would probably agree with your first 2 hypotheses. However I don't really see any momentum against Elm. Just the opposite in fact. There are other projects that have the same kind of goals such as Purescript or GHCJS but Elm is the one with the momentum.

>However I don't really see any momentum against Elm. Just the opposite in fact.

I just edited my comment to reflect that by "momentum against Elm" I meant to suggest that Elm is fighting against momentum that is currently behind technologies like JS, angular, react, etc. in the web programming community.

So it's basically a language we desperately want to use, but can't.

The problem isn't that it doesn't work. It's that what you do with ports only work in the context of your application. The JavaScript part has to be defined somewhere else, the Elm code assumes the JavaScript part will be there. You can't redistribute that easily.

How to make it better? that's easy. IT ALREADY EXISTS and is part of Elm. It's just a private API. But it totally does work. It's how the native wrappers are written.

Ports use publisher/subscriber. If I want to, let say, wrap moment.js, which is just a bunch of synchronous functions, how would I do it? Dispatch side effects to "compute dates" and listen to the "response" in my update method? That would be silly.

The port system works beautifully to interface with the outside world. It is very poor to bring the outside world in.

You mean like this: https://github.com/mcapodici/capodicis-notes/blob/master/elm...

That is an example where I connected chrome extension storage functionality using native wrappers.

This is the Elm wrapping for it:

https://github.com/mcapodici/capodicis-notes/blob/master/elm...

For the record, I looked at Elm over 2 years ago and completely dismissed it. I regret that strongly now as I am extreeeeemely happy developing with it and I can build stuff in far shorter timelines with zero runtime errors than I could in react even (which was a high-watermark before Elm for me in that respect)

I understand why but in the meantime I'll use something else and will try it again once it's more open.

As far as why people don't just use Elm, I think it's the same reason functional language are less popular in general: fewer familiar engineers and steep learning curve.

But, I thought the same about Coffeescript. And then Rails gave it massive traction. I wonder if the same might happen to Elm, should Phoenix adopt it as their browser language of choice. That might also offset concerns about Elm's fledgling status and key man risk.

There's definitely a connection there -- for what it's worth, the keynote at 2016's Erlang Factory conference was a shared talk between Chris McCord (creator of Phoenix) and Evan Czaplicki (creator of Elm), "Making the Web Functional" [0]

[0] https://www.youtube.com/watch?v=XJ9ckqCMiKk

All that said, I'd probably check out elm now only because I've heard good things about it's developer experience.

Elixir is getting bigger with Dockyard and Pinterest using it among others, though it has the benefits of running on proven technology, having an "easy" syntax, and Phoenix.

I'm not deep enough into it to really assess yet, but I suspect the difficulty is how you integrate it with existing JS code. It feels like maybe it's an all-Elm or nothing world, which makes it hard for organisations to take it for a test run when they have an existing codebase to play nice with.

My exploration is an ongoing activity to figure out which framework / methodology is best to continue building our existing product on. We're currently using Angular (1) and some react components. I did some prototyping with Redux (including investigating Sagas) and familiarised myself with RxJS and MobX. I found the boilerplate in Redux distracting some I'm still looking to see what else is out there – would love to hear how others are assessing these tools.

One of the things that's really attractive about React is that there are already a lot of components you can drop in to handle behaviours for you. If I could somehow utilise those within Elm, it would lower the entry barrier for me.

It's not that I even have a clear picture of what I need to achieve but with each of these different tools I'm trying to poke at them to see where they fall down. So far, Elm feels the nicest, but it's the smaller ecosystem / lack of libraries that's the most obvious shortcoming so I'm trying to understand what the options are for interoperability on that front.

Please don't reject something based on its current (admittedly not 1.0!) state based on assumptions about its future! Evan and co. are in fact extremely smart and by no means does anyone consider Elm "done." I'd suggest playing with the language itself. That's the important part - not the state of the current runtime.

Elm is not just a language, it's a language + frontend UI framework. It is theoretically possible to run Elm code under Node, but the relative level of craziness is similar to "writing a C++ compiler in Angular", please let me exaggerate a bit :-)

After this adventure, I realized that having the ability to share code between server and client is too indispensable for me to trade for lack of runtime errors.

Native interface - I use a lot of js code already written by somebody else. I have a very extensive data manipulation library developed in Coffeescript for my application. It's proven, tested, documented and presents a solid foundation for whatever I decide to write using the data I have. I want to use this code freely. In Elm native interface is frowned upon and the official way is to use ports, which is quite cumbersome, especially for procedural libraries.

As an OSS project, Elm is too centralized for my taste. I'm fine writing helloworlds, toys, learning projects, etc in the language that is being designed and developed by a single person not accepting contributions from the public, besides probably a very small curated list (not sure about that part). But for the business, it's just too much risk yet.

I moved to Purescript. I haven't yet started writing for the browser yet :-) but so far Node and Google Apps Script were doing pretty well. In a sense as a language Purescript is both more demanding (it's much closer to Haskell than Elm) and more forgiving, more javascripty in a good sense of this word, just a part of the toolchain, not pretending to be an ultimate answer to everything. The native interface is best in class.

Frankly, for the category theory idiot like me, Purescript is easier than Elm, while Elm is considered much simpler exactly due to many compromises with "The Math". Almost every decent beginner-friendly Haskell book will work for Purescript, you don't need to break your head over "Elm doesn't have monads, but it does have Effects and Maybe and what not, which are technically monads, but we don't call them monads, etc...". Maybe for others it's different. I can recognize design decisions Evan made and why he made them and I'd like to see how it goes. But I'll watch from the sidewalk for now.

Just my 2 cents.

Another great thing about the community is a goal of a single great library for every use case, rather than a lot of half-baked competing libraries. So expect there to be a single great modal library. Etc.

[0] https://platform.html5.org/

The only "official" interop channel is the "port" system, which only lets you do a publisher/subscriber type thing with your application at runtime, and cannot be used in a library.

So you basically cannot make a "blessed" library that uses native browser APIs.

I'd love to chat with anyone that wants to know what we're doing and why we do it :)

I ended up learning Erlang after hearing about Elixir and not being a fan of the Rubyish syntax and immutability comporomise, which has been a very rewarding experience. Haskell even more so. And Purescript has some nice Elm inspired libraries [2].

[1] https://purescript.org

[2] https://github.com/search?utf8=%E2%9C%93&q=language%3Apuresc...

there is no "immutability compromise" in Elixir. Static Single Assignment != Immutability. Elixir is entirely immutable - it has to be as it just runs on the Erlang VM!

I think a legitimate complaint along these lines would be "pinning is confusing and error prone for beginners" and I think it's fair. Christopher Meiklejohn mentioned this on Twitter yesterday, and it's a point that's caught me plenty and I write more Elixir code than most people by far.

No, variables are mutable in Elixir.

   Interactive Elixir (1.1.0-dev)
   iex(1)> x=1
   1
   iex(2)> x=2
   2

In Erlang:

   1> X=1.
   1
   2> X=2.
   ** exception error: no match of right hand side value 2

I suspect you misunderstood gp's post and thought they were talking about data, which is immutable in both languages in general.

> x = [1, 2, 3]

> x = 2 # the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2

All data is still immutable, the BEAM itself requires so. Dave Thomas explains this in its "Programming Elixir" book.

I wasn't talking about data, I was talking about variables. Yeah you just called it "re-binded". I called it "changed" or "mutated".

You have a function, and you see x=1 first and print its value. You'd see "1". Then you can have x=2 maybe a few lines or pages below, print it, you get "2". Variable x has changed its value. I even illustrated with a short example.

> All data is still immutable, the BEAM itself requires so. All data is still immutable, the BEAM itself requires so

Agreed. I don't think I ever talked about data being mutable. Having used BEAM VM for the last 5 years, yes, I noticed data is immutable ;-)

immutable/mutable data and immutable/mutable identifiers are two different things. One is not called the other, they are separate things really.

> It's not mutated or changed it points to a totally different memory location

So you said it yourself. It points to a different memory location. So how is x not mutated then? "Mutated" is a synonym for "change", or so I thought apparently.

I don't see how one can look at a variable being reassigned and say "nope, variable didn't change", where it clearly has a new value in the line below.

> Immutable data is what eliminates a large number of potential bugs.

Agreed. Was using Erlang for many years and tried Haskell before. Immutable data is pretty nice most of the time.

> care if someone reuses the name above the point in code you used it.

Wait, is it the opposite of what you were trying to say? Wouldn't you want to care if you are now randomly re-using or changing variables someone else assigned. I thought immutability was a good thing.

> By allowing rebinding you only care about the code below the place your introduced a variable.

Unfortunately in my code base, the code above the place where variables are introduced is just as mission critical as the code after the place. Maybe I am using a strange coding style or paradigm ;-)

I prefer the way Erlang does it. But I get why Elixir did what they did as well.

  def t() do
    x=1
    f=fn -> x end
    x=2
    f.() 
  end

You're referring to static single assignment. This has been covered before in more detail than I care to go into.

I think you are confused though ;-) There is no renaming -- x=1, then x=2. Nothing was renamed. x wasn't renamed, it is still variable x. 1 and 2 wasn't renamed, it is still 1 and 2 (could have been a map, or list for example). So what do you think was renamed there?

> You're referring to static single assignment.

No, I am referring to immutable variables. Variables are not changing, they are immutable in Erlang. In Elxir variables change, they can be assigned different values later in a function. If that is not a change i.e. a mutation I don't know what is.

[1] https://github.com/fbonetti/elm-phoenix-socket

Also, Elixir community... there seems to be a paucity of awareness of Dialyzer and Typespecs. Perhaps they could be more prominent? They're included in the reference docs, but not really so much in a way that indicates what they are or how one would use them when writing their own software in Elixir.

There are many, many classes of problems that can be discovered before they're discovered at runtime. It's made a little harder in Elixir-land due to limited Map support in Dialyzer and Map usage being extremely common in Elixir code, but still spec'ing your functions is a good practice and habit to get into anyway.

Erlang 19's included Dialyzer improves the scenario of type-checking maps in useful ways. Namely that now you can represent an empty map, an arbitrary map of any type, and a partially arbitrary map which must include certain key type and value type associations but is not limited to those. Which leaves out one representation which is a map which includes and only includes a specific set of key type and value type associations.

Erlang 18's Dialyzer has basically just #{} =:= map() which is equivalent to the union of #{none() => none()} and #{any() => any()}, so it was basically a giant escape hatch in the type-checking system, and thus not particularly valuable.

Looking forward to a pending change in laxness as a result of the coming changes in 19. :-)

Elm and Elixir are like two neighborhood kids growing up together as best buddies. They are both new, functional, webby languages with communities that are very friendly and very interested in inventing new ways to make programming better. It's natural that both groups would be excited about working together.