26 ms·

Elm changed my mind about unpopular languages

509 points by lyddonb 9y ago

mooreds 9y ago
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.)
- blunte 9y ago
  This is always a risk with new tools and techs. Thankfully there are sometimes enough early adopters to help keep the new thing in motion and improving. Considering that a lot of code that gets written is thrown away or otherwise doesn't survive for years, a bit of risky experimentation isn't actually as risky as it seems. Even though I'm one of the never-satisfied/always-seeking-newer-better group (and my list of used and discarded tools/languages is very long), I do sometimes wonder if we would be better off with fewer choices and more effort spent on the concepts and methods of software development rather than on the tools.
  - mooreds 9y ago
    > This is always a risk with new tools and techs. Absolutely. Whenever I see a new project, I look at business risk and technology risk. Either one is OK, but both are not. (I picked that up from someone, don't remember who). I think that there's real value to being a Tom Bombadill (and really learning a language/framework/problem space deeply) as opposed to being a Gandalf. However, one fundamental issue is it's easier be a consultant and speaker if you are focused on the new shiny objects, and so much of what is written is from that perspective.
    - blunte 9y ago
      I have pondered about this depth vs breadth approach for some time. My path has made me a generalist who learns and does whatever I think is necessary in a given situation. This is great because I can do anything. But I envy the domain experts who do one (or a related few) things VERY well. Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shiny tech guys may seem to have more opportunities, I believe the domain experts may get paid more and have more of their career time spent as "recognized leaders". It's probably good that people are all different, and both types (and all in between) exist.
      - mooreds 9y ago
        I think it's also a risk tolerance thing. To analogize, if you are a general carpenter, you can always find work, but it will be at a lower rate. However, it will be varied. If you are a fine cabinet carpenter, your work will likely be more focused, possibly more repetitive, more lucrative, and harder to find (you'll have to seek out the folks who need really really nice cabinets).
        blunte 9y ago
        Exactly. And maybe the grass is always greener, but sometimes I envy the COBOL guy who earns a small fortune doing something that doesn't involve learning a new language and framework every two years.
      - rkangel 9y ago
        I work for a consultancy (both general consultancy and engineer), and the phrase they like to use is "a T-Shaped consultant". Meaning that you have a broad base of skills and one specialism. For us, most people fitting that model works pretty well.
- vages 9y ago
  Main backer is the online learning service NoRedInk. The language's creator works there.
  - rtfeldman 9y ago
    This has been true since January 2016. Source: http://blog.noredink.com/post/136615783598/welcome-evan http://blog.noredink.com/post/136615783598/welcome-evan
- deleted 9y ago
  [deleted]
- skybrian 9y ago
  Another risk is that the language hasn't reached 1.0 yet. Incompatible changes happen.
  - robertkluin 9y ago
    This has been a pain point for us with a couple of the language updates. Not as bad as other pre-1.0 languages I've used in the past (like Rust), but it has been painful. The compiler is helpful enough that upgrades are mostly just tedious.
- robertkluin 9y ago
  I'm a partner at Real Kinetic. At Real Kinetic we've actually been internally using Elm for 2 years. While at Workiva, I OKed some internal projects to use Elm as well. Your observations are absolutely correct. We have actually found on-boarding engineers to Elm is fast and relatively easy. There is a very predictable learning curve engineers seem to follow. That's one of the things we like about Elm versus some other solutions. The even bigger observation I've made is that all of the engineers we've exposed have become fans, like Alex. The lack of resources and other companies contributing to the community and libraries is a challenge, and a concern. As an example, we use Elm Native UI for some projects. It has a limited user-base, which has at times been frustrating. We're hoping to see more adoption of Elm to help mitigate this problem.
- adrianmsmith 9y ago
  Regarding the second point, As a counter-argument, it’s not certain that languages and frameworks from major vendors will continue to be supported either. For example Microsoft deprecated various UI frameworks, Firefox extensions are changing, and so on. (I’m sure there are better examples I can’t think of at the moment.)
  - mooreds 9y ago
    Sure, large vendors deprecate stuff all the time. But you'll probably have plenty of notice and they'll have a path for your existing applications to follow. It may be painful, but it won't be catastrophic. Contrast that with what would happen if No Red Ink went out of business and the author of Elm couldn't find a job that would allow him to continue to develop it. Things would be fine for months or years but eventually bitrot would set in. Definitely not trying to spread FUD. I know some great folks that swear by Elm. It's just another risk factor (just like tech debt that might accrue should you use jQuery) to consider. Edited to correct where the Elm author works.
    - exprezi 9y ago
      Actually, I used to work with Evan Czaplicki (the author of Elm) at Prezi around 2015. He was laid off with a bunch of other employees during a “reorg”. It didn’t seem to have affected Elm.
      - fjsolwmv 9y ago
        That's not a ringing endorsement of Elm's commercial viabity. Prezi hired the Elm creator and funded Elm development and then ran out of money to pay him.
        learc83 9y ago
        What does that have to do with Elm's commercial viability? The only conclusions I can draw from that are about Prezi's commercial viability.
    - 9y ago
- wwweston 9y ago
  > 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 It can be a useful filter in both directions. I'm more impressed with prospective employers who have an onboarding plan including some reasonable model of a learning curve than prospective employers who assume "oh, we use popular language/framework/tooling x/y/z, so if we find someone who knows these specific things, onboarding will be a snap or practically take care of itself."
- api 9y ago
  This is correct but sad. It's why better languages like Elm and Rust struggle to gain acceptance while inferior but well marketed efforts like Swift dominate.
  - leshow 9y ago
    Woah. I love Rust and program in it super often, but I've looked at Swift also and it seems like an incredibly capable language. It has similar capabilities for algrebraic types, and a "typeclass" like approach to parametric polymorphism. Also if I'm not mistaken, Graydon, the creator of Rust works on it now. What makes you say Swift is inferior? It seems like a huge improvement over ObjC.
    - michaelcampbell 9y ago
      > [What makes you say] Swift is inferior? It seems like a huge improvement over ObjC. Not the poster, but both of those can simultaneously be true.
- rtfeldman 9y ago
  Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading this morning; we see a lot of similar stories): > Despite my valiant evangelizing of Elm, my company has decided to embrace React over Elm, so I am looking for opportunities to develop Elm professionally. Our Head of Talent said she'd never seen an inbound pipeline as strong as ours, and the #1 reason people cite for wanting to apply is Elm. The "Python Paradox"[0] is real! [0] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
  - soulnothing 9y ago
    I have to ask, do you guys have the catch 22. Of we want you to have worked in it professionally before? I'm being totally serious. I worked in Elm, and loved it. I tried to get it in several positions I worked at. Applied to a few elm positions, but was told I needed prior professional experience. So moved all my personal projects to React so I could be more marketable. My day job is still using java server faces, or django templates largely. As noted above there are pros and cons. But if you're using a fringe language/tech and allow your team to contribute back upstream. That helps immensely. One of the other stands out I can think of is Jane Street and OCaml.
    - _d8fd 9y ago
      Just tinker with Elm at work on your lunchbreak and say you uswd it at work. If you're awesome, no one will know and/or care where you picked up your awesomeness.
      - not_kurt_godel 9y ago
        > say you used it at work Please don't do this. If you're not found out in the interview, you'll be found out on the job eventually due to your obvious lack of experience. Some of my most personally loathed coworkers have been people who have bullshitted their way into positions by claiming skills they don't have or aren't qualified in, making them a nightmare to work with.
- fpoling 9y ago
  Yet another problem is that for an unpopular language it is easy for its developers to introduce incompatible changes. If one does not have resources to fix the codebase, it is not much different from the developers abandoning the language. Elm still at risk of such changes, witness fundamental change to it's event subscription model after 0.16. Of cause, such incompatible changes may happen even with popular languages. But at least you know that you are not alone and there will be companies that support your version. Like, for example, the case of Python2, still supported and even installed by default on many systems instead of python3.
- zenhack 9y ago
  I think the hiring woes problem for languages like this is a reasonable hypothesis, but I've never seen any actual evidence for it. I constantly hear from folks who are worried that they will have this problem, and frequently hear folks saying they tried it and it wasn't a problem (see sibling comments, for example). I'm not sure I've ever heard from someone who has actually had this problem.
  - Joeri 9y ago
    Try hiring for obscure and legacy, like delphi. My employer has had this problem for years.
    - zenhack 9y ago
      Yeah, legacy is probably an entirety different beast.
    - fiddlerwoaroof 9y ago
      Part of me would really love to go back to Delphi: I learned it when I was like 10 and it spoiled me for every other GUI development process.
- quotemstr 9y ago
  In the worst case, you just adopt the runtime yourself. I don't understand why people draw boundaries around certain frameworks, runtimes, and languages and say "I'm hiring that kind of engineer". A good developer can go up and down the stack as needed and fix any part of it --- including the language runtime.
  - zenhack 9y ago
    People do tend to have a mental block where the possibility of fixing one of their dependencies is something that wouldn't even occur to them. To the point where they'll implement really complex workarounds in their own code instead of submitting a one-line patch (or sometimes even reporting it). That said, as someone who is no stranger to contributing to upstream, the prospect of becoming the maintainer strikes me as something that is certainly not to be done lightly.
- wpietri 9y ago
  By coincidence, I just had breakfast with someone whose company adopted Elm; they made a great case for it. I'm excited to check it out. But I'd add that popular languages have related problems. Java, Python, and Ruby are all ones I've used in production, and I'd say every one has a big problem pushing the language forward. They all have failed me differently in that regard, and I'd still happily use any of them again in the right circumstances. The talent situation is interesting as well. With a popular language I can find more people who claim to know the language. But of the people who show up, a lot more of them will not be particularly good. In practice, given the work necessary to get somebody up to speed on our domain, our chosen libraries and frameworks, and our own code base, helping them learn a new language doesn't seem like much on top of that. The big things that keep me from picking novel languages for long-lived production code are libraries and production considerations. It's such a huge advantage to be able to download a decent library rather than having to code everything from scratch. And I don't want to be the company pushing a language into unknown performance territory. It's noble work, but it can be expensive and introduce a lot of volatility that I really don't need.
- keithnz 9y ago
  In the general sense (not talking about elm) It's a risk going off the beaten path to leverage some new way of doing things that makes life easier, sometimes that risk pays off, sometimes it doesn't. Sometimes it pays off bigtime early and then starts costing big time later ( I experienced this using Meteor from early on in its life ). I went with C# when it was still beta, that paid off real well. I went with embedding lua into a embedded system very early in luas life, that was a great choice. I tried with moving to F# from C# and it was just too painful for the devs to switch (though I really like F#, it's advantages weren't huge over C# that made it compelling ). Considering trying again with converting C programmers to Rust for an embedded system where we are refreshing to a more modern chipset. So mixed results, but just because it might not work out isn't reason to not take a risk, just have to work out how appropriate that risk is.
- z5h 9y ago
  Your interested in solving problems you might have in 3 years, and Elm solves problems you definitely have now and will continue to have in 3 years. In 20 years of development I've never been happier, more productive, and more error-free.
- dmix 9y ago
  Most good devs can learn a new JS framework very quickly...hell I've done it about 10 times now. It's really not a big deal, most are pretty similar or variations on other popular frameworks from other languages. What matters more is the quality of the language/framework and relative availability of libraries for the particular usecase (general popularity is not always necessary).
- dozzie 9y ago
  > * lack of talent that can step right in and be effective Competent people, not "talent". Talented people are very rare, and the chances are, you haven't ever seen one in reality. And there are several things to note about hiring programmers for writing in less popular languages: (1) it's much more difficult to hire an incompetent idiot that knows Elm than similar idiot who knows C#, Java, or Python -- signal to noise ratio is much better; (2) there is such thing as Haskell tax, which pretty much means that writing in Elm can be treated as a job perk; and (3) you don't need people who know Elm, you only need people who can learn it in reasonable time. Especially (3) is important, because learning yet another language of the same paradigm is not that difficult for a competent programmer.
- quickthrower2 9y ago
  Hiring: Elm is quite easy to learn. It's a shaved down Haskell for the language, with a military style strict version of React as the view paradigm. So you just need someone who has done some ML type language or is keen to learn, which is many people. Also see my sister comment about Haskell tax. (The employee pays the tax to the employer!). We really need to get away from this idea of "She's a Java developer", because she isn't. She is a problem solver with programming skills. Lack of resources could be an issue. I am hopeful about Elm though as the founder has plenty of cash and passion to keep pushing it forwards, plus a full time job doing just that. Plenty of people who can step in if required. The compiler is written in Haskell so is probably quite maintainable. Much of the functionality is in libraries maintained by a diverse group.
- Spooky23 9y ago
  Sometimes niche technologies have benefits, as you can be a big fish in a small pond. When I need to do something new, I look for small companies from weird places with promising products. I get favorable terms, and usually rapid turnaround in features as we figure out what things we though we needed vs reality.
platz 9y ago
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!).
deleted 9y ago
[deleted]
GenghisSean 9y ago
I agree with what the author is saying, but Clojure and Clojurescript are the unpopular languages I find valuable.
brabel 9y ago
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!
- Latty 9y ago
  I notice Scala missing from your list - if you need the JVM or find Elm to not quite have what you need, it's a great language. It's basically the opposite end of the spectrum, design-wise - Elm is "let's create this highly opinionated, carefully curated language and try to make it perfect" and Scala is "let's throw every feature we can derive into our type system and let people work it out". It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages. I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested. https://github.com/lattyware/massivedecks https://github.com/lattyware/massivedecks
  - anthonybullard 9y ago
    Scala's flaw - and Elm's strength - is it is a massive language that allows for a large amount of magic to happen. Elm is by comparison tiny and extremely explicit, and error messages thrown by the compiler are almost always super helpful. But Elm can't (really) be used on the server, so it doesn't hurt to look at Scala there, though be prepared to have a hard time finding experienced engineers to hire.
    - leshow 9y ago
      Id argue that while Scala has more powerful features, it has less "magic". Elm can't be used on the server because it has a magical create app function that you must feed the exact right functions into in order to make anything. AFAIK it's not a general purpose language.
qwerty456127 9y ago
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.
- innocentoldguy 9y ago
  I agree. I think TypeScript is a decent language, but after working with the DOM in a functional way, verses object-oriented and imperative paradigms, I don't think I'll ever go back. To paraphrase and hijack what the author stated, HTML feels like it was created for Elm (and functional programming in general). I'd add HTTP to that as well. The combination just feels right.
  - qwerty456127 9y ago
    Indeed!
Jeff_Brown 9y ago
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 https://www.haskell.org/communities/05-2017/html/report.html
- fjsolwmv 9y ago
  That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.
  - Jeff_Brown 9y ago
    What changes do you think Haskell can't keep up with? If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching. * every valid Python program is valid Coconut
    - brightsize 9y ago
      "Coconut: Simple, elegant, Pythonic functional programming." http://coconut-lang.org/ http://coconut-lang.org/
      - rthomas6 9y ago
        Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?
klez 9y ago
> 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?
- seveibar 9y ago
  > > 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? Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX. So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
  - masklinn 9y ago
    > Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). Neither is even remotely as robust — let alone friendly — as Elm's type system.
    - boubiyeah 9y ago
      It's not so black and white :) Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time. I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")
    - 9y ago
seveibar 9y ago
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.
- ghthor 9y ago
  Perhaps, but with Elm you get a much better experience revolving about the tooling(Inspired from Golang I believe). This would be one of my top arguments for picking Elm over a giant mess of react+infinite choices of libraries and configurations.
- ajmurmann 9y ago
  Not the author, but I've used React + Redux and Flowtype and played a little bit with Elm. Elm felt so much cleaner, the typing was great and it was a breeze to learn. I'm certain I'll go with Elm on my next web project.
- Rotareti 9y ago
  I can't speak for the author, but I made the transition from JS+React to TypeScript+React to Elm and it "changed my mind" too. When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, ImmutbaleJS for immutable data structures, Ramda as a FP utility library and Recompose to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.
innocentoldguy 9y ago
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 https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
- joshribakoff 9y ago
  The recording of steps is called event sourcing and both vuex and redux implement the pattern, I'm sure elm is great but that benefit is not unique to elm https://martinfowler.com/eaaDev/EventSourcing.html https://martinfowler.com/eaaDev/EventSourcing.html
  - galfarragem 9y ago
    Elm's creator is a visionary [1]. E.g. Redux took inspiration from his thoughts. Rust's compiler error messages also. It was rather common on elm core newsgroup to see him asking for secrecy on new ideas before releasing a new version of Elm. The negative part is that Elm's development is rather slow and not pragmatic. This is painful on the short term - specially if you come from JS land.. [1] An example of a (great) conceptual talk: https://www.deconstructconf.com/2017/evan-czaplicki-on-storytelling https://www.deconstructconf.com/2017/evan-czaplicki-on-story...
- regularhackerer 9y ago
  Async only interop to JS is a bit sad though
_xgw 9y ago
> 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)?
- regularhackerer 9y ago
  exhaustive pattern matching
  - Multicomp 9y ago
    Exactly. That's why I started using F# wherever I can get away from it at work.
- masklinn 9y ago
  Not to the same extent, Elm: * sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0]) * has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience) * and which you use as bottom by hand-rolling pattern matches * at which point you might as well do it correctly To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust. You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience. [0] https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck
  - danharaj 9y ago
    GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.
kmicklas 9y ago
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.
masklinn 9y ago
> 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.
brudgers 9y ago
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.
- steinuil 9y ago
  It actually has... due to not having any major release in 2 years.
  - fjsolwmv 9y ago
    So it's abandoned?
    - gregdunn 9y ago
      No. It is still being actively developed: https://github.com/elm-lang/core/commits/master https://github.com/elm-lang/core/commits/master / https://github.com/elm-lang/elm-compiler/commits/master https://github.com/elm-lang/elm-compiler/commits/master But it's been 14 months since the latest full release.
ken 9y ago
> "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!
- woolvalley 9y ago
  At least you save a few hours when you look up the known bug
TremendousJudge 9y ago
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.
- macintux 9y ago
  I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.
  - TremendousJudge 9y ago
    That's one of the points he raised, and I see the value now. However, the author also talks about the dangers that come from using lesser-known, using unstable languages (he mentions finding bugs in the compiler, segfaults, and so on), and he doesn't say how Elm solves them
    - macintux 9y ago
      Good point. I suspect to some degree it's mitigated by the fact that anyone attempting to re-implement (most of) Haskell must care about correctness a great deal, and having Haskell already in place limits the number of conceptual bugs. Anyway, this is pure speculation on my part, I have yet to dive into either language.
    - callumlocke 9y ago
      The author does emphasise how complete and well-built the official Elm tools are, which kind of mitigates this concern. But I agree, the article doesn’t really spell out its reasoning.
desireco42 9y ago
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.
- ghthor 9y ago
  When you say smarter programmer I understand what you mean. But the way I look at it, Elm allows me to relax and be a dumber programmer. I commit my smarts up front to the type design and interfaces between types and then I can relax as the project grows from there because the compiler will enforce the invariants I've encoded into the types. Pure Bliss.
  - fjsolwmv 9y ago
    Big Design Up Front is back in style now? Agile is dead?
    - yawaramin 9y ago
      The beauty of strong static typing–you don't need to get the types right immediately. Just get an initial design out the door and iterate towards better designs as you go. The compiler helps you tremendously for refactoring, and managed deprecations let you change types gradually over time.
  - cpursley 9y ago
    > Elm allows me to relax and be a dumber programmer Yes, this! I don't feel smart enough to write programs well in JavaScript. Elm brings clarity and confidence without having to second-guess myself all the time (thanks to the compiler and fantastic error messages).
matte_black 9y ago
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.
- nogridbag 9y ago
  I find this line of reasoning a bit strange. I've only dabbled a bit with some unpopular languages, but I don't think their limited popularity implies they're only suitable for niche use cases. In fact after using some languages (most recently Clojure) I find programming in other mundane languages like JS a huge step backwards. People are probably the biggest determining factor in achieving a quality result. But I don't think that means we should forget about trying to improve our tools.
  - matte_black 9y ago
    It’s not just about the language itself. You might think Japanese is an awesome language and decide to learn it, but then what use is speaking Japanese outside of Japan? Around the world people still just use boring ol’ English, even though English is actually a pretty shitty language and full of hacks to make up for weird edge cases (read and read, goose and geese, mice and meese?, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo) Likewise, if you write something in Clojure, you have far less people and libraries and platforms that can help you accomplish whatever you are doing. If what you are doing is not something new or groundbreaking that could only be done well with Clojure, then the extra effort you have to spend to get up and running is not worth it.
    - annywhey 9y ago
      I have thought about this problem some and currently see it as an issue of scaling thresholds. If it's literally just you, there's a lot of benefit to leveraging existing work so that you can focus on the differentiating part of the project(which is probably not a language innovation). It's not just the libraries but the whole ecosystem - example code, troubleshooting help, IDE support. If you have an engineering team of even modest size, the picture can change very swiftly towards ensuring your result is built on a solid foundation, even if it means a lot of pioneering infrastructure has to be built and a lot of late nights spent debugging core toolchain issues. Team efforts have the necessary momentum to break free and do that ground work as the overhead gets swiftly absorbed in "person-year" budgetary terms. Individuals can only really justify the same as their core direction of research, sole hobby, or speculative investment - e.g. being the "first to implement" some hot new standard could be a well incentivized career move.
isostatic 9y ago
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.
- mrweasel 9y ago
  True, I still think article with ML in the title are all about ML the programming language.
- Retra 9y ago
  This is why I'll never be a web developer. "Let's drop names! I made bridges out of Wood.io, then I used Steel (TM), now I use Stone.js. What's fun, now there's data in the kiddie pool!" It feels like watching a cult of optimization function in a culture where measurement is taboo. It's absurd beyond belief.
  - always_good 9y ago
    That's fine. I don't think the ecosystem needs any more people that get their blood pumping over some inconsequential name reuse. To get Elm confused with the email client with this title, you'd have to not know the Elm language existed. So it seems like it's a moment to go "oh I see, that exists" than cursing the world because you thought "Elm changed my mind about unpopular languages" somehow referred to an email client. But I get it. It's cathartic to be angry on the internet. The angry shadow boxing just gets pretty old for the rest of us no matter what kind of developer you are.
    - Retra 9y ago
      I'm talking about the uselessness of saying "I used X, now I use Y." WHY does one change what one uses? For reasons supposedly. But of course nobody ever provides reasons. It is enough to simply drop names. Print out your resume. Because heaven forbid anybody provide some real data that shows why one platform is better than another. I'm certainly not confused about what Elm is. That'd be easy enough to find out. But "why you stopped using it" sure as shit isn't something I can google.
pixelpp 9y ago
Yep, we are on ELM
antonkm 9y ago
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 https://guide.elm-lang.org
Rotareti 9y ago
> 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.
- amorphid 9y ago
  If one really wanted to... one could run a browser on the server to run a page powered by Elm, and then click on the page using Selenium style web driver. I'm guessing it wouldn't scale well :) "What stack are you guys using for the backend?" "SLEW: Selenium Webkit Elm LocalStoarge" "Wat..."
alphaalpha101 9y ago
>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.
ggm 9y ago
Elm is not unpopular: its just not yet common. its popular with people heading to strongly typed FP. GHC-JS
j45 9y ago
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.
hota_mazi 9y ago
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.
- joevandyk 9y ago
  It would be a hiring point for me for someone that became quickly comfortable and productive in a language that was unfamiliar.
gsvclass 9y ago
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/ https://bellpluscat.com/
- boundlessdreamz 9y ago
  This looks great. Btw why save to google drive instead of google sheets?
- cbenz 9y ago
  Is the source code available? For the whole product, or else for the table (or grid) component? As an Elm developer I would be interested to dive into your implementation and perhaps contribute.
cutler 9y ago
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.
yawaramin 9y ago
Is it true that Elm is going to remove custom operators in the next release?
anonytrary 9y ago
> 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.
- quickthrower2 9y ago
  > 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. Yes, and not only because the volume of copy-paste source code on StackOverflow. I suspect Elm is slower to get a feature out, but once it is out you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. And so later on in the same project ... you are faster. > 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. From what I have seen Elm is absolutely fit for production grade work. There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. Sounds elitist? Maybe.
  - anonytrary 9y ago
    > There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are. For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose? Modern JavaScript undoubtedly towers over Elm in terms of go-to-market time for arbitrary apps. > you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. This is a big problem with 2007 JavaScript and jQuery. React/Vue and other declarative VDOM frameworks bring the Elm philosophy to the masses.
b0rsuk 9y ago
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.
- _sdegutis 9y ago
  Math isn’t required. FP is about thinking of data structures and transformations from A to B. If you’ve ever used underscore.js, you’ve probably used FP patterns and functions. Map, filter, reduce are all part of that.
- lewisinc 9y ago
  I don't think so. If anything I feel it's a bit easier as you don't need to reason about object state. It's also different, which is the main hurdle. If you use emacs you've already been exposed - Emacs Lisp is functional. If you're coming from a Web background both Elm and Elixir are great places to begin. You'll often hear stuff like "Javascript can be written in a functional style" - which is true, functional programming is a paradigm you can just go with - but seeing it really embraced by the language is really inspiring.
- ff_ 9y ago
  FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps). How to approximate FP in a mostly OOP language: - use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java. - you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing - of you stick to the above, you will find that returning void from a method is very difficult. Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state. Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core. And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end). HTH
PaulStatezny 9y ago
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.
- latch 9y ago
  I wouldn't write off an entire company on this abbreviated description, but damn, I'd be worried about this. It does not speak highly of your CTO. I'm not saying Elm is objectively better than JavaScript (I don't do either). But, can't these things sit side by side. And, if so, how is rewriting code aligned with moving faster? At worst, keep what you have in Elm, and write new code in JS? Also, there's plenty of "ugghh" with JavaScript that I'm skeptical of anyone throwing away existing code in order to rewrite it in javascript. This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."
  - PaulStatezny 9y ago
    Perhaps my description of our CTO/situation left out too much detail. (I was trying to be succinct.) > It does not speak highly of your CTO Our CTO is the kind to speak highly about. Strong technical/software engineering skills. Willing to experiment with new/different tech. Business minded. He agreed whole-heartedly to move forward with Elm in the first place. This is actually our 2nd project with Elm now. > Can’t these things sit side by side? How is re-writing code aligned with moving faster? Yes; in fact, we’d always had a mix of Elm+JS. Our product is not a Single Page App. (Very deliberate decision.) We’re only using JS/Elm to make small parts interactive. So there was only a relatively small amount of Elm code that was replaced. It allows us to move faster because our designer and a couple of junior devs on the team don’t have to struggle through learning Elm.
    - 9y ago
leke 9y ago
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.
- justinhj 9y ago
  You can adopt some practices from fp when writing PHP. For example often instead of iterating over an array and doing some imperative sequence of modifications you can do a sequence of maps, filters and reduce... you replace error prone mutable code with more a declarative approach that says what you are doing clearly.
msangi 9y ago
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
nivertech 9y ago
Can rewrite the example from the post: uniqueAuthors = books |> List.map .authors |> List.concat |> Set.fromList |> Set.size as uniqueAuthors = books |> List.concatMap .authors |> Set.fromList |> Set.size
deleted 9y ago
[deleted]
karmakaze 9y ago
> 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.

509 points by lyddonb 9y ago

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.)

blunte 9y ago
This is always a risk with new tools and techs. Thankfully there are sometimes enough early adopters to help keep the new thing in motion and improving. Considering that a lot of code that gets written is thrown away or otherwise doesn't survive for years, a bit of risky experimentation isn't actually as risky as it seems. Even though I'm one of the never-satisfied/always-seeking-newer-better group (and my list of used and discarded tools/languages is very long), I do sometimes wonder if we would be better off with fewer choices and more effort spent on the concepts and methods of software development rather than on the tools.
- mooreds 9y ago
  > This is always a risk with new tools and techs. Absolutely. Whenever I see a new project, I look at business risk and technology risk. Either one is OK, but both are not. (I picked that up from someone, don't remember who). I think that there's real value to being a Tom Bombadill (and really learning a language/framework/problem space deeply) as opposed to being a Gandalf. However, one fundamental issue is it's easier be a consultant and speaker if you are focused on the new shiny objects, and so much of what is written is from that perspective.
  - blunte 9y ago
    I have pondered about this depth vs breadth approach for some time. My path has made me a generalist who learns and does whatever I think is necessary in a given situation. This is great because I can do anything. But I envy the domain experts who do one (or a related few) things VERY well. Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shiny tech guys may seem to have more opportunities, I believe the domain experts may get paid more and have more of their career time spent as "recognized leaders". It's probably good that people are all different, and both types (and all in between) exist.
    - mooreds 9y ago
      I think it's also a risk tolerance thing. To analogize, if you are a general carpenter, you can always find work, but it will be at a lower rate. However, it will be varied. If you are a fine cabinet carpenter, your work will likely be more focused, possibly more repetitive, more lucrative, and harder to find (you'll have to seek out the folks who need really really nice cabinets).
      - blunte 9y ago
        Exactly. And maybe the grass is always greener, but sometimes I envy the COBOL guy who earns a small fortune doing something that doesn't involve learning a new language and framework every two years.
    - rkangel 9y ago
      I work for a consultancy (both general consultancy and engineer), and the phrase they like to use is "a T-Shaped consultant". Meaning that you have a broad base of skills and one specialism. For us, most people fitting that model works pretty well.
vages 9y ago
Main backer is the online learning service NoRedInk. The language's creator works there.
- rtfeldman 9y ago
  This has been true since January 2016. Source: http://blog.noredink.com/post/136615783598/welcome-evan http://blog.noredink.com/post/136615783598/welcome-evan
deleted 9y ago
[deleted]
skybrian 9y ago
Another risk is that the language hasn't reached 1.0 yet. Incompatible changes happen.
- robertkluin 9y ago
  This has been a pain point for us with a couple of the language updates. Not as bad as other pre-1.0 languages I've used in the past (like Rust), but it has been painful. The compiler is helpful enough that upgrades are mostly just tedious.
robertkluin 9y ago
I'm a partner at Real Kinetic. At Real Kinetic we've actually been internally using Elm for 2 years. While at Workiva, I OKed some internal projects to use Elm as well. Your observations are absolutely correct. We have actually found on-boarding engineers to Elm is fast and relatively easy. There is a very predictable learning curve engineers seem to follow. That's one of the things we like about Elm versus some other solutions. The even bigger observation I've made is that all of the engineers we've exposed have become fans, like Alex. The lack of resources and other companies contributing to the community and libraries is a challenge, and a concern. As an example, we use Elm Native UI for some projects. It has a limited user-base, which has at times been frustrating. We're hoping to see more adoption of Elm to help mitigate this problem.
adrianmsmith 9y ago
Regarding the second point, As a counter-argument, it’s not certain that languages and frameworks from major vendors will continue to be supported either. For example Microsoft deprecated various UI frameworks, Firefox extensions are changing, and so on. (I’m sure there are better examples I can’t think of at the moment.)
- mooreds 9y ago
  Sure, large vendors deprecate stuff all the time. But you'll probably have plenty of notice and they'll have a path for your existing applications to follow. It may be painful, but it won't be catastrophic. Contrast that with what would happen if No Red Ink went out of business and the author of Elm couldn't find a job that would allow him to continue to develop it. Things would be fine for months or years but eventually bitrot would set in. Definitely not trying to spread FUD. I know some great folks that swear by Elm. It's just another risk factor (just like tech debt that might accrue should you use jQuery) to consider. Edited to correct where the Elm author works.
  - exprezi 9y ago
    Actually, I used to work with Evan Czaplicki (the author of Elm) at Prezi around 2015. He was laid off with a bunch of other employees during a “reorg”. It didn’t seem to have affected Elm.
    - fjsolwmv 9y ago
      That's not a ringing endorsement of Elm's commercial viabity. Prezi hired the Elm creator and funded Elm development and then ran out of money to pay him.
      - learc83 9y ago
        What does that have to do with Elm's commercial viability? The only conclusions I can draw from that are about Prezi's commercial viability.
  - 9y ago
wwweston 9y ago
> 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 It can be a useful filter in both directions. I'm more impressed with prospective employers who have an onboarding plan including some reasonable model of a learning curve than prospective employers who assume "oh, we use popular language/framework/tooling x/y/z, so if we find someone who knows these specific things, onboarding will be a snap or practically take care of itself."
api 9y ago
This is correct but sad. It's why better languages like Elm and Rust struggle to gain acceptance while inferior but well marketed efforts like Swift dominate.
- leshow 9y ago
  Woah. I love Rust and program in it super often, but I've looked at Swift also and it seems like an incredibly capable language. It has similar capabilities for algrebraic types, and a "typeclass" like approach to parametric polymorphism. Also if I'm not mistaken, Graydon, the creator of Rust works on it now. What makes you say Swift is inferior? It seems like a huge improvement over ObjC.
  - michaelcampbell 9y ago
    > [What makes you say] Swift is inferior? It seems like a huge improvement over ObjC. Not the poster, but both of those can simultaneously be true.
rtfeldman 9y ago
Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading this morning; we see a lot of similar stories): > Despite my valiant evangelizing of Elm, my company has decided to embrace React over Elm, so I am looking for opportunities to develop Elm professionally. Our Head of Talent said she'd never seen an inbound pipeline as strong as ours, and the #1 reason people cite for wanting to apply is Elm. The "Python Paradox"[0] is real! [0] http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
- soulnothing 9y ago
  I have to ask, do you guys have the catch 22. Of we want you to have worked in it professionally before? I'm being totally serious. I worked in Elm, and loved it. I tried to get it in several positions I worked at. Applied to a few elm positions, but was told I needed prior professional experience. So moved all my personal projects to React so I could be more marketable. My day job is still using java server faces, or django templates largely. As noted above there are pros and cons. But if you're using a fringe language/tech and allow your team to contribute back upstream. That helps immensely. One of the other stands out I can think of is Jane Street and OCaml.
  - _d8fd 9y ago
    Just tinker with Elm at work on your lunchbreak and say you uswd it at work. If you're awesome, no one will know and/or care where you picked up your awesomeness.
    - not_kurt_godel 9y ago
      > say you used it at work Please don't do this. If you're not found out in the interview, you'll be found out on the job eventually due to your obvious lack of experience. Some of my most personally loathed coworkers have been people who have bullshitted their way into positions by claiming skills they don't have or aren't qualified in, making them a nightmare to work with.
fpoling 9y ago
Yet another problem is that for an unpopular language it is easy for its developers to introduce incompatible changes. If one does not have resources to fix the codebase, it is not much different from the developers abandoning the language. Elm still at risk of such changes, witness fundamental change to it's event subscription model after 0.16. Of cause, such incompatible changes may happen even with popular languages. But at least you know that you are not alone and there will be companies that support your version. Like, for example, the case of Python2, still supported and even installed by default on many systems instead of python3.
zenhack 9y ago
I think the hiring woes problem for languages like this is a reasonable hypothesis, but I've never seen any actual evidence for it. I constantly hear from folks who are worried that they will have this problem, and frequently hear folks saying they tried it and it wasn't a problem (see sibling comments, for example). I'm not sure I've ever heard from someone who has actually had this problem.
- Joeri 9y ago
  Try hiring for obscure and legacy, like delphi. My employer has had this problem for years.
  - zenhack 9y ago
    Yeah, legacy is probably an entirety different beast.
  - fiddlerwoaroof 9y ago
    Part of me would really love to go back to Delphi: I learned it when I was like 10 and it spoiled me for every other GUI development process.
quotemstr 9y ago
In the worst case, you just adopt the runtime yourself. I don't understand why people draw boundaries around certain frameworks, runtimes, and languages and say "I'm hiring that kind of engineer". A good developer can go up and down the stack as needed and fix any part of it --- including the language runtime.
- zenhack 9y ago
  People do tend to have a mental block where the possibility of fixing one of their dependencies is something that wouldn't even occur to them. To the point where they'll implement really complex workarounds in their own code instead of submitting a one-line patch (or sometimes even reporting it). That said, as someone who is no stranger to contributing to upstream, the prospect of becoming the maintainer strikes me as something that is certainly not to be done lightly.
wpietri 9y ago
By coincidence, I just had breakfast with someone whose company adopted Elm; they made a great case for it. I'm excited to check it out. But I'd add that popular languages have related problems. Java, Python, and Ruby are all ones I've used in production, and I'd say every one has a big problem pushing the language forward. They all have failed me differently in that regard, and I'd still happily use any of them again in the right circumstances. The talent situation is interesting as well. With a popular language I can find more people who claim to know the language. But of the people who show up, a lot more of them will not be particularly good. In practice, given the work necessary to get somebody up to speed on our domain, our chosen libraries and frameworks, and our own code base, helping them learn a new language doesn't seem like much on top of that. The big things that keep me from picking novel languages for long-lived production code are libraries and production considerations. It's such a huge advantage to be able to download a decent library rather than having to code everything from scratch. And I don't want to be the company pushing a language into unknown performance territory. It's noble work, but it can be expensive and introduce a lot of volatility that I really don't need.
keithnz 9y ago
In the general sense (not talking about elm) It's a risk going off the beaten path to leverage some new way of doing things that makes life easier, sometimes that risk pays off, sometimes it doesn't. Sometimes it pays off bigtime early and then starts costing big time later ( I experienced this using Meteor from early on in its life ). I went with C# when it was still beta, that paid off real well. I went with embedding lua into a embedded system very early in luas life, that was a great choice. I tried with moving to F# from C# and it was just too painful for the devs to switch (though I really like F#, it's advantages weren't huge over C# that made it compelling ). Considering trying again with converting C programmers to Rust for an embedded system where we are refreshing to a more modern chipset. So mixed results, but just because it might not work out isn't reason to not take a risk, just have to work out how appropriate that risk is.
z5h 9y ago
Your interested in solving problems you might have in 3 years, and Elm solves problems you definitely have now and will continue to have in 3 years. In 20 years of development I've never been happier, more productive, and more error-free.
dmix 9y ago
Most good devs can learn a new JS framework very quickly...hell I've done it about 10 times now. It's really not a big deal, most are pretty similar or variations on other popular frameworks from other languages. What matters more is the quality of the language/framework and relative availability of libraries for the particular usecase (general popularity is not always necessary).
dozzie 9y ago
> * lack of talent that can step right in and be effective Competent people, not "talent". Talented people are very rare, and the chances are, you haven't ever seen one in reality. And there are several things to note about hiring programmers for writing in less popular languages: (1) it's much more difficult to hire an incompetent idiot that knows Elm than similar idiot who knows C#, Java, or Python -- signal to noise ratio is much better; (2) there is such thing as Haskell tax, which pretty much means that writing in Elm can be treated as a job perk; and (3) you don't need people who know Elm, you only need people who can learn it in reasonable time. Especially (3) is important, because learning yet another language of the same paradigm is not that difficult for a competent programmer.
quickthrower2 9y ago
Hiring: Elm is quite easy to learn. It's a shaved down Haskell for the language, with a military style strict version of React as the view paradigm. So you just need someone who has done some ML type language or is keen to learn, which is many people. Also see my sister comment about Haskell tax. (The employee pays the tax to the employer!). We really need to get away from this idea of "She's a Java developer", because she isn't. She is a problem solver with programming skills. Lack of resources could be an issue. I am hopeful about Elm though as the founder has plenty of cash and passion to keep pushing it forwards, plus a full time job doing just that. Plenty of people who can step in if required. The compiler is written in Haskell so is probably quite maintainable. Much of the functionality is in libraries maintained by a diverse group.
Spooky23 9y ago
Sometimes niche technologies have benefits, as you can be a big fish in a small pond. When I need to do something new, I look for small companies from weird places with promising products. I get favorable terms, and usually rapid turnaround in features as we figure out what things we though we needed vs reality.

platz 9y ago

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!).

deleted 9y ago

[deleted]

GenghisSean 9y ago

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

brabel 9y ago

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!

Latty 9y ago
I notice Scala missing from your list - if you need the JVM or find Elm to not quite have what you need, it's a great language. It's basically the opposite end of the spectrum, design-wise - Elm is "let's create this highly opinionated, carefully curated language and try to make it perfect" and Scala is "let's throw every feature we can derive into our type system and let people work it out". It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages. I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested. https://github.com/lattyware/massivedecks https://github.com/lattyware/massivedecks
- anthonybullard 9y ago
  Scala's flaw - and Elm's strength - is it is a massive language that allows for a large amount of magic to happen. Elm is by comparison tiny and extremely explicit, and error messages thrown by the compiler are almost always super helpful. But Elm can't (really) be used on the server, so it doesn't hurt to look at Scala there, though be prepared to have a hard time finding experienced engineers to hire.
  - leshow 9y ago
    Id argue that while Scala has more powerful features, it has less "magic". Elm can't be used on the server because it has a magical create app function that you must feed the exact right functions into in order to make anything. AFAIK it's not a general purpose language.

qwerty456127 9y ago

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.

innocentoldguy 9y ago
I agree. I think TypeScript is a decent language, but after working with the DOM in a functional way, verses object-oriented and imperative paradigms, I don't think I'll ever go back. To paraphrase and hijack what the author stated, HTML feels like it was created for Elm (and functional programming in general). I'd add HTTP to that as well. The combination just feels right.
- qwerty456127 9y ago
  Indeed!

Jeff_Brown 9y ago

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 https://www.haskell.org/communities/05-2017/html/report.html

fjsolwmv 9y ago
That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.
- Jeff_Brown 9y ago
  What changes do you think Haskell can't keep up with? If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching. * every valid Python program is valid Coconut
  - brightsize 9y ago
    "Coconut: Simple, elegant, Pythonic functional programming." http://coconut-lang.org/ http://coconut-lang.org/
    - rthomas6 9y ago
      Wow, this looks very cool! Why is this not more popular? Coconut seems like something many people, including me, would want to use for every Python project of sufficient complexity. What's the catch?

klez 9y ago

> 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?

seveibar 9y ago
> > 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? Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX. So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
- masklinn 9y ago
  > Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). Neither is even remotely as robust — let alone friendly — as Elm's type system.
  - boubiyeah 9y ago
    It's not so black and white :) Robustness, you're absolutely right, Elm cannot be beat. But it comes at a price: It's pretty limiting/underpowered. Typescript is very expressive these days and you can write some very neat libs that feel dynamic but are actually fully typed, if you bother (to be fair, most people don't bother). On the other hand, Elm usually doesn't provide many ways to do something, and you may even have to cheat and offload some work to dirty-old-JS-land via a port to unblock yourself or simply deliver a functionality on time. I'm still unsure whether the freedom is worth it or whether the robustness wins at the end of the day; it may depends on what kind of app you're writing and how strong the team is (e.g scala has the same "issue")
  - 9y ago

seveibar 9y ago

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.

ghthor 9y ago
Perhaps, but with Elm you get a much better experience revolving about the tooling(Inspired from Golang I believe). This would be one of my top arguments for picking Elm over a giant mess of react+infinite choices of libraries and configurations.
ajmurmann 9y ago
Not the author, but I've used React + Redux and Flowtype and played a little bit with Elm. Elm felt so much cleaner, the typing was great and it was a breeze to learn. I'm certain I'll go with Elm on my next web project.
Rotareti 9y ago
I can't speak for the author, but I made the transition from JS+React to TypeScript+React to Elm and it "changed my mind" too. When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, ImmutbaleJS for immutable data structures, Ramda as a FP utility library and Recompose to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.

innocentoldguy 9y ago

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 https://pragmaticstudio.com/courses/elm), if you're interested in learning it.

joshribakoff 9y ago
The recording of steps is called event sourcing and both vuex and redux implement the pattern, I'm sure elm is great but that benefit is not unique to elm https://martinfowler.com/eaaDev/EventSourcing.html https://martinfowler.com/eaaDev/EventSourcing.html
- galfarragem 9y ago
  Elm's creator is a visionary [1]. E.g. Redux took inspiration from his thoughts. Rust's compiler error messages also. It was rather common on elm core newsgroup to see him asking for secrecy on new ideas before releasing a new version of Elm. The negative part is that Elm's development is rather slow and not pragmatic. This is painful on the short term - specially if you come from JS land.. [1] An example of a (great) conceptual talk: https://www.deconstructconf.com/2017/evan-czaplicki-on-storytelling https://www.deconstructconf.com/2017/evan-czaplicki-on-story...
regularhackerer 9y ago
Async only interop to JS is a bit sad though

_xgw 9y ago

> 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)?

regularhackerer 9y ago
exhaustive pattern matching
- Multicomp 9y ago
  Exactly. That's why I started using F# wherever I can get away from it at work.
masklinn 9y ago
Not to the same extent, Elm: * sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0]) * has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience) * and which you use as bottom by hand-rolling pattern matches * at which point you might as well do it correctly To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust. You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience. [0] https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck
- danharaj 9y ago
  GHC will coverage check any case equivalent to one you can write in Elm. You can just write more powerful types where GHC can't tell that your case is exhaustive so it warns about missing branches that won't ever actually be taken. I seem to remember that perfect exhaustive checking for some combination of Haskell extensions is undecidable.

kmicklas 9y ago

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.

masklinn 9y ago

> 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.

brudgers 9y ago

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.

steinuil 9y ago
It actually has... due to not having any major release in 2 years.
- fjsolwmv 9y ago
  So it's abandoned?
  - gregdunn 9y ago
    No. It is still being actively developed: https://github.com/elm-lang/core/commits/master https://github.com/elm-lang/core/commits/master / https://github.com/elm-lang/elm-compiler/commits/master https://github.com/elm-lang/elm-compiler/commits/master But it's been 14 months since the latest full release.

ken 9y ago

> "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!

woolvalley 9y ago
At least you save a few hours when you look up the known bug

TremendousJudge 9y ago

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.

macintux 9y ago
I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.
- TremendousJudge 9y ago
  That's one of the points he raised, and I see the value now. However, the author also talks about the dangers that come from using lesser-known, using unstable languages (he mentions finding bugs in the compiler, segfaults, and so on), and he doesn't say how Elm solves them
  - macintux 9y ago
    Good point. I suspect to some degree it's mitigated by the fact that anyone attempting to re-implement (most of) Haskell must care about correctness a great deal, and having Haskell already in place limits the number of conceptual bugs. Anyway, this is pure speculation on my part, I have yet to dive into either language.
  - callumlocke 9y ago
    The author does emphasise how complete and well-built the official Elm tools are, which kind of mitigates this concern. But I agree, the article doesn’t really spell out its reasoning.

desireco42 9y ago

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.

ghthor 9y ago
When you say smarter programmer I understand what you mean. But the way I look at it, Elm allows me to relax and be a dumber programmer. I commit my smarts up front to the type design and interfaces between types and then I can relax as the project grows from there because the compiler will enforce the invariants I've encoded into the types. Pure Bliss.
- fjsolwmv 9y ago
  Big Design Up Front is back in style now? Agile is dead?
  - yawaramin 9y ago
    The beauty of strong static typing–you don't need to get the types right immediately. Just get an initial design out the door and iterate towards better designs as you go. The compiler helps you tremendously for refactoring, and managed deprecations let you change types gradually over time.
- cpursley 9y ago
  > Elm allows me to relax and be a dumber programmer Yes, this! I don't feel smart enough to write programs well in JavaScript. Elm brings clarity and confidence without having to second-guess myself all the time (thanks to the compiler and fantastic error messages).

matte_black 9y ago

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.

nogridbag 9y ago
I find this line of reasoning a bit strange. I've only dabbled a bit with some unpopular languages, but I don't think their limited popularity implies they're only suitable for niche use cases. In fact after using some languages (most recently Clojure) I find programming in other mundane languages like JS a huge step backwards. People are probably the biggest determining factor in achieving a quality result. But I don't think that means we should forget about trying to improve our tools.
- matte_black 9y ago
  It’s not just about the language itself. You might think Japanese is an awesome language and decide to learn it, but then what use is speaking Japanese outside of Japan? Around the world people still just use boring ol’ English, even though English is actually a pretty shitty language and full of hacks to make up for weird edge cases (read and read, goose and geese, mice and meese?, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo) Likewise, if you write something in Clojure, you have far less people and libraries and platforms that can help you accomplish whatever you are doing. If what you are doing is not something new or groundbreaking that could only be done well with Clojure, then the extra effort you have to spend to get up and running is not worth it.
  - annywhey 9y ago
    I have thought about this problem some and currently see it as an issue of scaling thresholds. If it's literally just you, there's a lot of benefit to leveraging existing work so that you can focus on the differentiating part of the project(which is probably not a language innovation). It's not just the libraries but the whole ecosystem - example code, troubleshooting help, IDE support. If you have an engineering team of even modest size, the picture can change very swiftly towards ensuring your result is built on a solid foundation, even if it means a lot of pioneering infrastructure has to be built and a lot of late nights spent debugging core toolchain issues. Team efforts have the necessary momentum to break free and do that ground work as the overhead gets swiftly absorbed in "person-year" budgetary terms. Individuals can only really justify the same as their core direction of research, sole hobby, or speculative investment - e.g. being the "first to implement" some hot new standard could be a well incentivized career move.

isostatic 9y ago

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.

mrweasel 9y ago
True, I still think article with ML in the title are all about ML the programming language.
Retra 9y ago
This is why I'll never be a web developer. "Let's drop names! I made bridges out of Wood.io, then I used Steel (TM), now I use Stone.js. What's fun, now there's data in the kiddie pool!" It feels like watching a cult of optimization function in a culture where measurement is taboo. It's absurd beyond belief.
- always_good 9y ago
  That's fine. I don't think the ecosystem needs any more people that get their blood pumping over some inconsequential name reuse. To get Elm confused with the email client with this title, you'd have to not know the Elm language existed. So it seems like it's a moment to go "oh I see, that exists" than cursing the world because you thought "Elm changed my mind about unpopular languages" somehow referred to an email client. But I get it. It's cathartic to be angry on the internet. The angry shadow boxing just gets pretty old for the rest of us no matter what kind of developer you are.
  - Retra 9y ago
    I'm talking about the uselessness of saying "I used X, now I use Y." WHY does one change what one uses? For reasons supposedly. But of course nobody ever provides reasons. It is enough to simply drop names. Print out your resume. Because heaven forbid anybody provide some real data that shows why one platform is better than another. I'm certainly not confused about what Elm is. That'd be easy enough to find out. But "why you stopped using it" sure as shit isn't something I can google.

pixelpp 9y ago

Yep, we are on ELM

antonkm 9y ago

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 https://guide.elm-lang.org

Rotareti 9y ago

> 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.

amorphid 9y ago
If one really wanted to... one could run a browser on the server to run a page powered by Elm, and then click on the page using Selenium style web driver. I'm guessing it wouldn't scale well :) "What stack are you guys using for the backend?" "SLEW: Selenium Webkit Elm LocalStoarge" "Wat..."

alphaalpha101 9y ago

>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.

ggm 9y ago

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

j45 9y ago

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.

hota_mazi 9y ago

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.

joevandyk 9y ago
It would be a hiring point for me for someone that became quickly comfortable and productive in a language that was unfamiliar.

gsvclass 9y ago

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/ https://bellpluscat.com/

boundlessdreamz 9y ago
This looks great. Btw why save to google drive instead of google sheets?
cbenz 9y ago
Is the source code available? For the whole product, or else for the table (or grid) component? As an Elm developer I would be interested to dive into your implementation and perhaps contribute.

cutler 9y ago

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.

yawaramin 9y ago

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

anonytrary 9y ago

> 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.

quickthrower2 9y ago
> 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. Yes, and not only because the volume of copy-paste source code on StackOverflow. I suspect Elm is slower to get a feature out, but once it is out you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. And so later on in the same project ... you are faster. > 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. From what I have seen Elm is absolutely fit for production grade work. There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. Sounds elitist? Maybe.
- anonytrary 9y ago
  > There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are. For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose? Modern JavaScript undoubtedly towers over Elm in terms of go-to-market time for arbitrary apps. > you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. This is a big problem with 2007 JavaScript and jQuery. React/Vue and other declarative VDOM frameworks bring the Elm philosophy to the masses.

b0rsuk 9y ago

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.

_sdegutis 9y ago
Math isn’t required. FP is about thinking of data structures and transformations from A to B. If you’ve ever used underscore.js, you’ve probably used FP patterns and functions. Map, filter, reduce are all part of that.
lewisinc 9y ago
I don't think so. If anything I feel it's a bit easier as you don't need to reason about object state. It's also different, which is the main hurdle. If you use emacs you've already been exposed - Emacs Lisp is functional. If you're coming from a Web background both Elm and Elixir are great places to begin. You'll often hear stuff like "Javascript can be written in a functional style" - which is true, functional programming is a paradigm you can just go with - but seeing it really embraced by the language is really inspiring.
ff_ 9y ago
FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps). How to approximate FP in a mostly OOP language: - use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java. - you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing - of you stick to the above, you will find that returning void from a method is very difficult. Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state. Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core. And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end). HTH

PaulStatezny 9y ago

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.

latch 9y ago
I wouldn't write off an entire company on this abbreviated description, but damn, I'd be worried about this. It does not speak highly of your CTO. I'm not saying Elm is objectively better than JavaScript (I don't do either). But, can't these things sit side by side. And, if so, how is rewriting code aligned with moving faster? At worst, keep what you have in Elm, and write new code in JS? Also, there's plenty of "ugghh" with JavaScript that I'm skeptical of anyone throwing away existing code in order to rewrite it in javascript. This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."
- PaulStatezny 9y ago
  Perhaps my description of our CTO/situation left out too much detail. (I was trying to be succinct.) > It does not speak highly of your CTO Our CTO is the kind to speak highly about. Strong technical/software engineering skills. Willing to experiment with new/different tech. Business minded. He agreed whole-heartedly to move forward with Elm in the first place. This is actually our 2nd project with Elm now. > Can’t these things sit side by side? How is re-writing code aligned with moving faster? Yes; in fact, we’d always had a mix of Elm+JS. Our product is not a Single Page App. (Very deliberate decision.) We’re only using JS/Elm to make small parts interactive. So there was only a relatively small amount of Elm code that was replaced. It allows us to move faster because our designer and a couple of junior devs on the team don’t have to struggle through learning Elm.
  - 9y ago

leke 9y ago

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.

justinhj 9y ago
You can adopt some practices from fp when writing PHP. For example often instead of iterating over an array and doing some imperative sequence of modifications you can do a sequence of maps, filters and reduce... you replace error prone mutable code with more a declarative approach that says what you are doing clearly.

msangi 9y ago

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

nivertech 9y ago

deleted 9y ago

[deleted]

karmakaze 9y ago

> 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.