My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should?

The problem with unpopular languages is twofold:

* lack of talent that can step right in and be effective

* lack of resources to push the language forward

The first can be remediated by planning to bring new hires up to speed, and just making that investment in them. (It can also be a useful filter, making sure you are hiring someone who is really interested to the company and is willing to make the time investment to learn what is probaly not a very portable skill.)

The second is a bigger problem, if the main sponsor of the language moves on. If the main sponsor is committed, then you're probably fine. (I have no idea who pushes Elm forward, looks like there's a foundation from the wikipedia page.)

Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all understatements.

[1] https://www.haskell.org/communities/05-2017/html/report.html

I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here:

>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

This is common reaction to Elm and especially to Elm.

I also use Elixir and it has great community and everything, but somehow Elm is even more.

All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention.

There are other smaller things that I noticed.

I wish I can work more in Elm, not less.

Also one more thing. Elm made me wish to be way better programmer. You are surrounded by smart people and you just need to show more if you want to keep up.

Elm is awesome. I just wish much more people and companies would adopt it (and ClojureScript) so it would gain popularity close to that of TypeScript. This could make the web (and the frontend job market) a better place.

I'm a Java dev with just some basic experience writing functional code, mostly in Java/Kotlin/Groovy/Ceylon (all of which are primarily imperative!). Can confirm: Elm is awesome, easy to pick up as long as you understand basic things like union types and immutability, and I found myself productive in it within a single day!

There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm.

I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.

There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.

My first thought: The author would probably be equally satisfied if they had used JavaScript with flowtype and react. It sounds like they're comparing JQuery + Bootstrap (and similar "old" frontend frameworks) to Elm.

I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.

I built this in browser database app entirely in ELM. Since there is no existing rich component library available I had to write everything including a high performance grid implementation from scratch. The entire app took about a week and has zero runtime bugs since launch. I have to give credit to Elm for most of that.

https://bellpluscat.com/

One of the main problems with unpopular languages (which this article completely ignores) is growing the team, and hiring in general. In other words: the future of your project.

It's not just that it's hard to find people to join you, it's that even engineers who might be considering joining might decide it's not a good career move since they are going to spend years learning a language or a platform that sees no adoption and will not serve their future career.

This piqued my interest in Elm which lead me to start reading the Elm introduction[0] and it's great! I don't know if I'll ever use it in production but these well-written docs sparked the programming interest in me once again. Will definitely write some side project in Elm.

0: https://guide.elm-lang.org

I agree with what the author is saying, but Clojure and Clojurescript are the unpopular languages I find valuable.

We use(d) Elm at the company I work at. (A start-up.) Elm is great. All of the positive rumors about it are true.

The issue we've had with Elm isn't typically discussed in these conversations: My CTO doesn't seem to see the value of it+. So we recently replaced our Elm code with JavaScript.

I wonder if anyone else finds themselves in a similar situation.

+It's a bit more nuanced. We're in a very "MVP" stage; the line of thinking is to use something everyone's more familiar with so we can move fast.

If you're looking for a language for your own projects then, sure, Elm is a fine choice. When it comes to getting a job as a developer, however, it's a different story. The languages companies are willing to pay big bucks for tend to have been around for a long time. Tech, as a profession, is paradoxically very conservative. Even startups tend to go with Rails and that's been around for over a decade. Ecosystem maturity matters where money is at stake. Today I was offered a £460 per day contract to do Codeigniter for MBNA. Unfortunately it involved relocation. Not even Laravel, just plain old Codeigniter. Who's paying that to write Elm? Personally I love writing Clojure for my own projects but, again, Clojure jobs are thin on the ground even in London so I don't expect to make a career out of it.

> First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case.

I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?

> You probably can’t use it (Elm) on the server side

Some people mention this as a disadvantage. I think it would be cool to have a decent DSL dedicated to just frontends.

I wonder how to become a good functional programmer. I think I'm already decent at procedural/OO.

Do I need to have a strong maths background? I didn't learn it very well at university and this worries me. Many functional language fans seem to have degrees in maths.

> But when I joined Real Kinetic, I found out we were writing web client code in Elm. Elm? Really? The experimental language created for Haskell snobs who can’t handle stooping to the level of a regular blue-collar language like Javascript?

'bit of an odd thinking considering Evan's aversion to high-minded abstractions.

> "I don’t want to be the guy that finds a bug in the compiler."

When I'm wearing by "be productive" hat, I don't, either, but how realistic is that? Unless you've memorized the bug database for your compiler, running into a known bug is just as frustrating as discovering a new one, and I'm pretty sure I've run into at least a few bugs in every compiler I've ever used. According to my comments, my current flagship program has workarounds for 5 (known) compiler bugs.

I'd love to use only stable bug-free compilers (maybe Forth?), but I'm not sure that's practical. A more reasonable solution is to only use the popular parts of languages -- though apparently I'm not so great at discerning what those are, either!

Elm is not unpopular: its just not yet common. its popular with people heading to strongly typed FP. GHC-JS

> Elm requires that you think through all the edge cases. You must consider and specify what will happen in every case.

Wouldn't that be the case with _every_ typed and compiled programming languages (or at least, every typed and compiled programming languages that support pattern matching)?

> Even though Elm is a small language with a small community, that doesn’t affect the Elm experience in a noticeable way.

This conclusion was pulled out of thin air, with no justification from the rest of the article. The title is misleading, the article is really about why the author enjoys Elm over JavaScript...

The general rule of thumb that a larger active community leads to faster software development is more or less still true. There is no reason to suspect this is not the case with Elm.

It's all fun and games until you get hired to build a production-grade web stack in a dinky game-scripting language with no community, that you have written 0 lines of code in. Some people live and breath to reinvent wheels in 19 different languages. Not my cup of tea.

I tried and failed to pick up Elm. I've tried and failed to pick up a few FP programming languages. They tend to become more and more cryptic as I progress with them. I feel dumb, but I'm happy to stick with C like languages, like PHP for web development.

I've played with Elm a while ago and it's been a very nice experience.

I wouldn't use it for any frontend work just because I believe that it's possible to avoid single page apps if possible, but if I had to write a SPA I'd reach for Elm.

The only thing that makes me worried is that Elm 0.18 has been out for quite a while now and most of the development has been carried on behind the scenes by Evan.

This is good because it gives the time to the language to evolve in a coherent way instead of being a collection of bolted on features, but it also means that for outsiders is a bit hard to track progress in the language

> choose the one more people were using

After reading this article and reflecting on my own experiences and habits, my rule of thumb would be "choose the best of those with second-tier popularity." It's common that the most popular isn't the best, has advantages in numbers, but also disadvantages like low S/N ratio.

Many of the pitfalls of a scarcity are avoided, and can sometimes find a well-organized, curated, cultured pocket of enlightenment.

Programmers who believe just one stack is the right way to do things aren't probably the best hires long term.

While Tech evolves, being able to work with what exists and the future remains incredibly valuable.

I see that the current version is 0.18. Curious if the language has become more stable with fewer breaking changes than when I looked at it two years ago.

Can rewrite the example from the post:

  uniqueAuthors =
              books
                  |> List.map .authors
                  |> List.concat
                  |> Set.fromList
                  |> Set.size

  uniqueAuthors =
              books
                  |> List.concatMap .authors
                  |> Set.fromList
                  |> Set.size

Is it true that Elm is going to remove custom operators in the next release?

Yep, we are on ELM

I feel unpopular languages are best relegated for niche use cases the language is well suited for. If you are going to build something mundane like a CRUD App or a game, or an ERP, why wouldn't you just use some mundane blue-collar language like Javascript or its equivalent?

What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to achieve the same result? Just seems like added complexity for no reason, even if the code looks simple with the first pass.

>I made it a hard and fast rule: if I found two technologies that could solve a problem, I would choose the one more people were using. I didn’t want to include an obscure graphics API and then discover that no one had ever called set_color() followed by resize_window() (resizing is hard) and somehow those two functions in sequence cause a segfault. I don’t want to be the guy that finds a bug in the compiler. I just need to ship the product.

Then he links to issues for Qt and Go. They're certainly not obscure. What kind of weird argument is this? If anything, the argument there is that it doesn't matter how popular something is, as even extremely popular things like Qt and Go will still have bugs.

Nowadays it's really easy enough to use real Haskell in the browser with GHCJS, and FRP libraries like Reflex provide a much more complete experience than Elm's restricted form.

Queue the Alan Kay "programming is pop culture" quotes.

OP sees the world through a tribalistic lens.

And has an experience much like the extreme-leftist (those haskell snobs) turned Trump supporter (I've found my one true family! Forget the others!).

I used to use Elm, then I moved to Pine, then Mutt (which is still going strong)

I guess there's only so many names in the world, and they're bound to be reused.