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.)
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!
I'm kinda surprised more companies don't take the risk - its not like these are bad languages, either. There's still a huge chunk people (in terms of absolute number, not portion of total devs of course) out there playing around with languages like Elm or Haskell or a Lisp/Scheme, or OcaML, F#, etc. who'd be super excited to use those languages professionally.
I personally know of a story where a startup started with datomic and clojure, and it was a bad idea because datomic could not effectively delete things. Eventually they went the standard java and standard cassandra / postgres / redis type route.
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.
I would rather have people who care about their craftsmanship and are indifferent about the product than people who care about the product and are indifferent about the craftsmanship. The former ones do a good job regardless of what the product is about.
If down the line you find language XYZ is a much better fit, well you still have choices about migration/etc. I wouldn't expect the devs to revolt against this, if it really is a better fit.
Time and technology marches on, that doesn't mean we can't try to make the best tool choices we can while still accepting that change is a fact of life and adapting the best we can.
And, if it is a good tech that fits your business, why wouldn't you?
These are unbelievable fantasies. Where the time comes that another technology is a better fit is few years after when a.) team members might have changed preferences already multiple times b.) given average employee changing job once in 2 years your original team members left.
I think that hiring would is much better when companies hired less on applicant emotional state and more on calm rational decisions about work.
Where do I apply? ;-)
(To prove the point: yes, I'm one of those passion people, moving to Denmark to work in OCaml full-time, before working in Clojure full-time. Now someone give me an Idris job, heh!)
What are you looking for, exactly? As an "inexperienced" Scala dev, I'm genuinely interested.
Knowing C doesn't mean you can't learn React, but if you've only ever done C and low level systems programming means you have a lot to learn to get to the level of someone who has specialized in knowing React and it's environment. It's not just React. It's everything around it that also matters. Such as browsers, HTML, CSS, and all the best practices there. And while I'm sure anyone can learn that, the question is, would you do it in reverse?
Would you hire someone who knew React, CSS, HTML, and web development to write systems level C and expect them to learn it all, and, most importantly, be effective in their role?
Labelling yourself as a react engineer isn't limiting. It's just one of many things. You can have many labels, and adding a label doesn't take away from other things you can do. However, it is an effective way to communicate what skill sets you have to people that would be good to work for and with.
We've always been happy to hire good people who don't happen to be familiar with our stack already.
That’s a significant enough reason to pick one shop over another and also a reason to opportunistically apply.
“You get to work with Evan/Guido/dhh/Gosling” is a different sell than “we use Elm/etc”.
I don't think we're especially close to that happening yet, though. Obviously the opportunity to work with Evan is a big differentiator for us among Elm shops, but the cover letter I quoted exemplifies a person whose reason for leaving their current position was that they wanted to work with Elm, not React.
There are plenty of opportunities for companies to attract people like that. :)
With that said, I sort of agree with the sibling comment here. Most other people involved with a language that I've seen are still able to make objective criticisms about it.
While I understand that, I find it quite paradoxical given that Elm purportedly targets normal programmers. (Elmer here.)
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
Nope. jQuery fit(ted) a different use case (spicing up server-side rendered HTML upto small browser based app-bits). Doing a browser-side app in Elm (what it's specifically made for) makes for code base that is so much easier to work on some years from now, than using jQuery to accomplish the same.
What I want to say is, the debt you're going to accrue applying it to Elm's domain will not be a risk, it is impossible not to be destroyed by that debt. Where Elm provides a serious alternatives to the browser app frameworks that are 10 generations younger than jQuery.
Elm's size, OTOH, is certainly a risk factor.
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.
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).
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.
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.
[1] https://www.haskell.org/communities/05-2017/html/report.html
On to the topic of this submission itself, Elm turned out to be a gateway drug to Haskell for me. Similar to Paul Chiusano[1] I decided to switch from Elm to GHCJS (Haskell). I started with https://haskell-miso.org/ (based on the Elm architecture) but I'm currently developing using http://docs.reflex-frp.org/
[1] https://pchiusano.github.io/2015-04-23/unison-update7.html
Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.)
Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one.
Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before.
To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.
I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point.
But that was insightful, thank you!
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.
In this way, both your statement and the parent's statement can be simultaneously true.
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
I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
> 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.
Neither is even remotely as robust — let alone friendly — as Elm's type system.
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")
You're completely correct, though for whatever reason functional languages almost always have strong type systems.
Better than, say, assembly language.
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
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-story...
1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings".
But, on reflection, I am probably an pedantic iconoclast.
I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where
1 + "1"
"1" + 1
1 + 1
"1" + "1"
1 . "1"
"1" . 1
"1" . "1"
1 . 1
This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result.
That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2).
Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.
>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.
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.
Anyway, this is pure speculation on my part, I have yet to dive into either language.
FTFY.
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.
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.
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.
IMO this is an advantage of the smaller/smarter/niche (whatever you want to call them) programming communities. When they congregate around a couple libraries for common problems, those libraries tend to be very good. Speaking from experience in the Elm and Clojure ecosystems.
It’s much better in terms of developer time to evaluate 2 good libraries than 50 libraries where the quality ranges from abysmal to good.
But ... in addition to npm/babel etc. you need a wetware constraint checker. React says "human: make sure your data is immutable - please don't forget or something might break later in production". Elm says "I guarantee immutability"
That seems more of a metric for an ecosystem than a community.
Have you thought about the possibility that it's actually a community of people who first and foremost _consider_ themselves as being smarter than the rest? Maybe this is what's really off-putting to equally smart, but more humble developers?
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.
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
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)?
* 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.
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.
Because for something so mundane then it really doesn't matter what you use and you know the domain so well that you can recover from any hangups.
I certainly don't consider it self-evident that you always just use mundane solutions to mundane problems. Depends on your appetite for risk and how biz-critical the problem is.
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.
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.
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.
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.
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).
I guess there's only so many names in the world, and they're bound to be reused.
It feels like watching a cult of optimization function in a culture where measurement is taboo. It's absurd beyond belief.
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.
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.
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.
I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.
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.
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.
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."
> 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.
Elm-html is my biggest criticism of Elm. Why make the contemplating so difficult for the non-programmers to work with? It's holding back Elm adoption for sure.
But it's been 14 months since the latest full release.
As an Elm developer I would be interested to dive into your implementation and perhaps contribute.
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.
Some people mention this as a disadvantage. I think it would be cool to have a decent DSL dedicated to just frontends.
"What stack are you guys using for the backend?"
"SLEW: Selenium Webkit Elm LocalStoarge"
"Wat..."
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!
'bit of an odd thinking considering Evan's aversion to high-minded abstractions.
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
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.
While Tech evolves, being able to work with what exists and the future remains incredibly valuable.
uniqueAuthors =
books
|> List.map .authors
|> List.concat
|> Set.fromList
|> Set.size
uniqueAuthors =
books
|> List.concatMap .authors
|> Set.fromList
|> Set.sizeThen 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.