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!
The communities for languages like Elm are definitely smaller, but they're also "passion languages", if that makes sense. Nobody is learning elm because they've been or feel forced to (like you might with React, eg) or because they needed to maintain a legacy codebase at an old job or something. They're learning it because they're interested/like it, etc. So when it comes time to hire you have a small(er) pool of candidates than a react position might draw but the candidates are going to be people who've played around with Elm and enjoyed it and want to get a job writing Elm.
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.
But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.
> But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe.
I think they may be safer hires, anyway. They will be able to program themselves out of a wet cardboard box, which is more than you can say about the average Joe who may just be good at bluffing the interview.
Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag.
The thing that would worry me about niche languages is the amount of wheel reinvention you'd have to do. Not sure the cost/benefit calculation starts to look so great any more when you realize that your enthused elm developers will have to build a whole lot of stuff that you can just import in other languages.
Most niche languages have an FFI escape hatch for when you really need a library and don't want to re-invent a wheel. Elm, Purescript, Bucklescript, and ghcjs can all interoperate with javascript; Scala and Clojure work with most (all?) native java libraries; F# has access to most (all?) .NET libraries. Haskell, Idris, ATS, Erlang, and SBCL Common Lisp all allow you to access native system libraries.
FFIs can have warts, but in the general case library support isn't the obstacle people make it out to be.
I don't agree. I find that the impedance mismatch of an FFI is an incredibly fertile breeding ground for nasty and obscure bugs and deployment problems.
> Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag
Interviewing costs money—good tech interviewing particularly so. The less of the people you have applying to start with, the more money you save on culling then by way of tech interviews.
Not sure how Elm interacts with Javascript libraries, but JVM languages can generally use any existing Java libraries. So a language built on a popular run time (JVM, .Net VM, guess there's exactly two), can still have excellent library support.
Aren't you just as likely to get people who excel at hyping and hello-worlding new languages but can't actually make applications? Or people who just read the python paradox (with python scribbled out and Elm written over it) who think they can look like a great developer who understands the value of Elm but really don't?
You'll get those, yes. I know because I was one of them... But I think you unerestimate how bad the average interviewee can be.
Someone who hello worlds new languages may not know the syntax or idioms to write fizzbuzz in any specific language, but they will be able to characterise the rough shape of the problem, and not just sit in silence...
I have noticed a lot of language / framework collectors where every new project is in a new framework or language on their CV. While it will expose you to a lot of different ideas I doubt you will code very well in any of them if you are swapping every year. I have seen plenty of Python written like its Java and its just less elegant code. And Django code that doesn't follow best practices seems to be the norm. If you take the time to master a few things you can produce some quite elegant solutions. If you only know the basics, you reinvent the wheel in a crappy way usually.
The best ideas are those that you can share between languages. When you get hung up on idioms, or when you recreate idioms that don't matter in another language, that's where the problems are. Exposure to a lot of languages allow a person to figure out that union of computation that benefits all languages.
Like I say when I see python written in a Java style its verbose, and doesn't take advantage of much of the expressive syntax that Python provides over Java. You have given up the speed benefit of Java and have kept code that is nearly as verbose.
And don't get me started on the way people misuse Django.
In my experience they're quite correlated (but not 100%). It seems to be a strong signal for passion about development, which I'd say is important for hiring someone who really cares about doing their job well (which I also find is an important and rare attribute in a good dev).
I think this depends on what you mean by “actual value”. A working product powered by a tangled yarn of hastily-assembled spaghetticode has a highly dubious long-term value, and what’s worse, your “average-Joe” coders might not even realize/see the value of what that “one overly-careful coder” brings to the table
They're a great way to seed your recruiting pipeline. Enough of them ought to be good hires to make this useful. After that, you just have to trust your hiring process, just like you would for any other source of candidates.
Because you get all of the problems that you get mentioned in the article. And on top of that javascript land is fad heavy, and whats cool today might not be cool 2 years from now.
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.
He was working in a health startup and this was something like a couple of years ago. He said that datomic was immutable so actually deleting things to HIPPA standards was not possible I think. They might of fixed it by now.
Having installed a medical records system for live-fire use by an optometry practice, I can say that it's exceedingly rare that you ever want to delete anything that is logged in a medical records environment. It's so rare that it's never been done on the four or so years I've been maintaining the system.
You're correct that Datomic considers immutability a feature. That said, Datomic on-prem supports excision which completely removes data for exceptional cases. I suspect Datomic Cloud will sometime in the future.
With EU's GDPR (General Data Protection Regulation) looming on the horizon I think Cognitect would do themselves a disservice should they not include excision in their Datomic Cloud platform sooner rather than later.
F# is a bit surprising, since it’s already on top of a mainstream platform. If all else fails you can glue in C# if you ever find that you really can’t do something with F#.
F# and C# compile to the same intermediate language, are interpreted on the same runtime, and are produced by the same organization for the same IDE... Their libraries are compatible and they rely on shared access to the common .net ecosystem.
Your absolute worst case scenario would involve decompiling your F# source as C#. More realistically you would use dependency management to gracefully transition out of one of the languages.
Transitioning piecemeal works exceptionally well: it's exactly how I've transitioned numerous projects away from C# onto F# ;)
Ummm Purescript compiles to JS and shares the same runtimes. Both languages have support from popular text editors, and their libraries are compatible and rely on shared access to the common JS ecosystem. In what way is it an apples-to-oranges comparison?
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.
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.
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.
Good developers should be able to pick up new technologies on the job though. And you are conducting interviews in such a way as to select for good developers, right? To the extent that that's possible anyway?
I'd rather just hire for good developers in general who are interested in working in Elm than to hire only for Elm experience. As you've pointed out, there are problems in doing the latter.
Yep, I'd rather take the person who says "I've never worked with Elm but I've heard it does X, Y, and Z well because those are things I've always found lacking in [insert JS framework here]" or even "I've never heard of Elm, but based on your description it sounds like it might mitigate X, Y, and Z problems because of [reasons], cool!"; over the person who says they've used Elm before but gives vague answers to follow-up questions (even if they aren't lying and have actually used it).
This can get really messy. Using it on your job, creates a one-off orphan that no one knows how it works. Then I've seen a number of people claim they used it but didn't
I've also found this as a partial negative. Positive you took initiative, and want to learn. Negative you've now written a product that only you can maintain, and doesn't listen well.
I go down the honest path. Of I did a proof of concept, or scratch project in this language. But didn't get the buy in from the rest of the team. Which sometimes leads to why am I not good at sailing new technologies.
Aside, at least my side projects can be pushed to Github. I feel like committing to publishing a repo is the only reason I even finish anything, like writing a solid README, stubbing out a few issues, and then eventually closing them.
I never know if someone has seen my repositories but it's been invaluable to have projects I can confidently link to. Until I got to that point, I remember an anxiety of "gee, I sure hope they take my word for my skills." Talk about imposter syndrome.
But yeah, I agree with what you were trying to say. Whether you are honestly representing your skill level doesn't have much to do with whether your experience was paid or done in free-time.
The aspects in which they differ are numerous and substantial. If a candidate expressed the sentiment that they are the same in an interview, I would not take them seriously since it would indicate that they are either ignorant or naive, and either apathetic about work, or likely to favor personal coding pursuits over the job they're applying for.
And you've managed to try your best to denigrate me without actually stating any of the reasoning. If you would, try again, but hopefully without the ineffective sense of superiority.
* Technical failure in a professional setting can lead to loss of your source of income and therefore, in the worst case scenario: loss of access to food, shelter, comfort and other basic life necessities. Failure at a personal project has no such comparable consequences. Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.
* In a professional setting, you often have little choice of who you work with. Therefore the technical choices you make in a professional setting must take into account the possibility that the next person who works on your project may be someone who does not understand, like, or care about the way you do things, and that the way they interact with your work may have significant negative repercussions for both you and the project. This is often a tedious, difficult, and time-consuming task that requires different techniques and approaches than one would use when working on a personal project. Conversely, in a professional setting you will also inherit the work of others which may be done in ways you don't understand, like, or care about, with few or no options to change those ways, and you must develop and adopt technical strategies to deal with this as well.
* Documentation, readability, and testing take much more precedence in a professional setting since they serve as guardrails for the long-term integrity of your work as it gets passed on to others to maintain and expand.
* Working with others also requires agreement, and usually mutual compromise, on basic standards, conventions, and processes that can significantly affect your daily workflow and may greatly differ from how you would work on a personal project.
* The end goal of personal projects is usually personal enjoyment, satisfaction, and learning. The end goal of the vast majority of professional projects is to generate revenue, or otherwise serve some need that your employer deems sufficiently important to fulfill by compensating you. The intersection of techniques that are personally appealing to you and the ones that will generate value for your employer may be very small or nonexistent much of the time.
* Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
* Personal projects are usually started from scratch, and often dropped or 'completed' once they reach a certain level of complexity, due to the increased level of difficulty brought on by said complexity. Rarely does one have the luxury of dropping projects on a whim for such reasons in a professional context. In general, working in a professional context often involves dealing with a lot more annoying complexity and thorny problems that simply cannot be ignored. Even successful, enjoyable professional projects may become boring after a while since their success will draw continued investment by the employer, oftentimes in areas that are uninteresting or largely irrelevant to the aspects that were originally exciting.
> Techniques to minimize failure are quite literally a matter of survival in a professional context; they are often an afterthought in a personal project. Fault prevention and tolerance are often the most difficult characteristics to achieve in any sufficiently complex software system, and their prioritization or lack thereof has an enormous impact on virtually every aspect of working on such a system.
See, I almost see this as backwards. My personal projects often depend on only myself to maintain survival, and I didn't put all that time in to see them go by the wayside so easily. This means I build in tools and resources to help put them up and keep them up, because I'm the only one who can. In a professional context, I've often seen team members not consider these issues because once it's out, it's someone else's problem- if it causes downtime, DevOps, if it's a simple bug, whoever takes the ticket.
> Your employer may not care about letting technical debt pile up indefinitely as long as you can keep cranking out new features and meeting deadlines, code quality be damned. Alternatively, your employer may impose onerous processes to ensure code quality and integrity that aren't really necessary or effective, and which may even be counterproductive. In fact, there's a good chance your employer will understand very little about what you do at all and make demands that are incongruent with technical realities, which you must deal with, sometimes by performing pointless tasks solely to appease them.
While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
---
However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints. Personally, I code at home the same way I code at work: With quality and hope that it will continue to have a life long into the future. Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down. The other thing I recognize, is the kind of experience that has to do with working with others- something most personal projects certainly don't approach, but I don't look for them to solve it. Team experience still matters, I just also think personal projects mean something for technical experience.
> My personal projects often depend on only myself to maintain survival, and I didn't put all that time in to see them go by the wayside so easily.
That's great, but when push comes to shove, you can and will ignore an intractable issue in a personal project until you feel like working on it again. With a job, consistently ignoring issues can endanger your career and thereby, eventually, your ability to provide for yourself. (And to me, being a parasite who punts issues like you describe is hardly a better existence even if you're able to get away with it.)
> While certainly true, this is also something I would never expect someone on my team to be proud of. This is a shameful act, and done often enough leads to the departure of good talent. I expect management(including myself) to do it's job: Manage. This means not taking advantage of your employees often enough to make it a norm.
Sometimes accumulating technical debt is a more pragmatic option in the bigger picture - what I'm describing isn't necessarily a universally bad thing (although it often is bad); the point is that professional and personal projects have fundamentally different priorities and that they require different skills and approaches to navigate effectively.
> However, the thing I keep noticing about a lot of these is a certain level of assumption of what a personal project entails. That you may be producing something with significant technical debt, that you are coding in a way that isn't trying to work best with others, that you're not aiming for revenue or having to work under unrealistic constraints.
You are validating this assumption with statements like this:
> Sometimes I don't return to projects for months- and I want to be able to pick them up the way I put them down.
When you are in production with real customers, you rarely have the option to do this. It's great to strive to adopt good practices in your personal projects, but when shit hits the fan at 3am, you're not going to get out of bed and fix it unless you have some real skin in the game, and you're not going to be truly motivated to code as if that's a real possibility (That means having: runbooks, paging, escalations, dashboards, metrics, alarms, gradual rollouts, time windowing, calendar blackouts, rollbacks, multi-step deployments, canaries, tech-ops, feature toggling, A/B testing, backup/restore, DNS safeguards, load balancing, SLAs, pentesting, failover, status reporting through 3rd-party channel, etc. etc.). I never said personal projects don't mean anything for technical experience; they certainly do. But that doesn't mean they're representative of professional experience either.
Don't you want people that care about your product instead of the technology behind it? I do. Because there may come a time when another technology is a better fit for your product and ultimately your customer's experiences. Then what? Now your not using elm and your team leaves or is disgruntled. I hire on passion for what we are trying to accomplish, not the technology stack.
> Don't you want people that care about your product instead of the technology behind it? I do.
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.
Depends how good people you want on your team. If your bar is low, then you
might find enough people above the skill threshold that care about your
product, but there are plenty of good craftsmen who couldn't care less about
your IPTV offering or some other SaaS for housewives, but who would put their
skills to great use for either, just because they do care about how solid is
the technical part.
Seems like a false dichotomy to me. It's plenty possible to choose (and recruit based on) a suitable language at the time you start a project, and to have people psyched about making a great product.
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.
I tried this. Bought into the company vision despite lack of experience/desire for RoR. The plan was to migrate to microservices. This happened too slowly and rarely and I ran out of enthusiasm working with a legacy monolith. The scaling problems we're interesting although they could be sidestepped other ways.
I find this whole line of thinking odd. First peoples preferences over technology change and pretty much everyones preferences or "passions" develop. Second, you dont need to be passionate about product to produce good work. You need not to hate it. You need to like the position and work you are doing, but that does not require passion for contracted web page for financial company (or whatever).
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.
The Python paradox is interesting in 2018. At time he wrote this, Java was the go-to language to teach in university and Python was reserved for hobbyists. It seems that has almost completely flipped now, and everywhere wants to teach Python first. Evidently, there's an awful lot of no-so-smart python programmers available on top of the smart ones now. It looks just like Java looked in 2004.
I definitely disagree that java is looking like - or even starting to - python did in 2004, it still has a huge market share, even compared to python. Yes python is definitely more popular now, enough so that the python paradox doesn't even apply, but it will probably never apply to java, or at least not in the current computing paradigm.
Maybe I read GP wrong, but what I took it to mean was that the market/talent position of python in 2018 is similar to java in 2004, not that java in 2018 is similar in any way to "2004 python".
Elm, Haskell, Clojure, etc, seem like they fulfill the role of "2004 python" in 2018.
Yes sorry, I worded that badly and didn't intend to mean that Java was in any way like Python was in 2004. Only that Python is no longer something you'd consider someone smart for using.
I saw the same at CircleCI with clojure. People want to use functional langs in real systems - we had a lot of Haskell lovers apply because "close enough". Way easier than hiring rails devs. One of the reasons I'm using OCaml/Elm in my new startup :)
> One of the reasons I'm using OCaml/Elm in my new startup
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!)
I'm not the quoted person, but we hire Elm devs (or people who want to become Elm devs - no prior Elm experience necessary; you can pick it up after joining!) all over the world.
Most of our team is remote, including one from Copenhagen!
You and your team (NoRedInk, Evan, et.al.) could actually grow the number for amazing Elm devs out. I think part of the reason is that there's a very narrow avenue to traverse to even build production-level Elm apps. One of the sure fire discouraging factor for someone learning and wanting to embrace a language is when s/he is unable to see the same see the light of the day at the hands of real users/consumers.
P.S. I'd love to learn and apply Elm across. I've applied at NoRedInk but did not get any response.
There is SimCorp and Issuu that I know of, but I've also been at a meetup hosted by a company doing ReasonML. And there are a couple of people doing OCaml at Zendesk, but I don't know if they use it in production or just for fun.
Strangely, if you switch Elm for Scala, you get the exact opposite result (at least where I work). We got mostly inexperienced candidates and the ones able to understand the codebase can get more interesting offers elsewhere.
Scala has a steep learning curve, so we're looking for devs having at least one or two real production projects (that aren't using spark) on their belt. It turns out to be quite a challenge to find someone who have experience in the ecosystem and the language, AND who _like_ working with it.
Plenty of developers have significant Scala experience and like working with it, but the demand greatly outstrips the supply - if you look at a chart of average salary by language Scala is a huge outlier.
Interesting, I wonder if there is a fade on the Python effect, where the talented devs that pick up on new languages move on to something else. eg If you want to create a big new long-lived project you pick a new language to get a good team, but for maintenance you'll struggle if that language doesn't become popular.
I'm a little confused. React isn't a language, or at least I thought it wasn't a language. When I hire people I'm not the least bit interested in which JavaScript framework they have already used. I kind of assume that if you can learn one you can learn them all. The idea of labelling yourself a react engineer seems really limiting to me
> I kind of assume that if you can learn one you can learn them all.
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.
I would look askance at someone who calls themselves a "C Developer" in much the same way I would at someone who calls themselves a "React Developer". The reason being that it just smells wrong, like they read a "C for Dummies" book and are trying to fake it til they make it or something. The correct label is something more general about the domain (eg. systems developer, front-end developer, etc), although I realize these labels are imperfect and subject to their own anti-patterns (eg. devops engineer), they at least signal you understand something about the broader landscape.
Where does that specialization stop, reasonably? Isn't this the same with JavaScript? If you have worked with any Algol-derived language you can learn them all.
In theory it doesn't stop. Most developers have the capacity to learn anything. In reality though I've found its more that some Devs are not willing to work with certain languages.
Specifically with respect to the hiring advantage it’s a little disingenuous to not explicitly state that the creator/designer of the language works there.
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”.
Part of the reason we hired Evan was because the hiring advantage had been so great already, we started to ask the question "how do we maintain this hiring advantage as Elm gets more popular and the Python Paradox eventually wears off?"
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. :)
You really ought to disclose that you also hired the language's BDFL when you make comments like these.
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.
Yes it's the ol' Haskell tax. As a part-time Elm enthusiast that's why I'll probably use it to build my own stuff to opensource/sell, rather than try to get a job doing it, lest my family goes homeless. Hyperbolic, but kind of true! However it's great for the company hiring. They can get solid code at a solid price. I've seen the same with a Haskell/Blockchain job. The company owner admitted in a chat channel that he would have said "Berlin Salary" rather than "Not quite SFO" in the job ad if he had know the response rate he would have got.
Elm doesn't support code splitting or `insertRule` styling, both of which are important for performance. `elm-package` is currently piggybacking GitHub's infrastructure instead of having its own hosting. I think Elm should have more patch releases. I don't think `comparable`, `number`, or especially `appendable` should be in the language, and hope they get removed someday. I don't think `==` should be `a -> a -> Bool`. If I were in charge, ports would work with `Value` directly instead of doing automatic conversions at the edges.
Also, your comment was needlessly harsh. If you wanted to know what I consider Elm's flaws, you could have tried just asking.
I'm always impressed by your ability to keep cool when someone seems to be making a personal attack (though I'd like to assume they aren't). I think Elm/Evan is lucky to have you as a kind of evangelist.
You're right, my comment was needlessly harsh and I apologize for that. You didn't deserve that and it was rude of me.
The subject of Elm often gets me riled up because there's so much good about it mixed with what to me is a greater portion of frustration. I strongly disagree with how the language is managed, with the closed nature of its development, but mostly with what looks like the constant dismissal of any concerns about any of these issues any time they're brought up. By far, the most common response feels something like "everything is fine and your opinions are baseless."
There are people I know who, like me, have tried to convince employers to even consider Elm and have been shot down because, in management's words, "there doesn't seem to be any idea where the language is going", or its "too unsafe, its all dependent on one guy" or "looks like its dead now anyway, no releases in over a year and apparently it sucks at basic things like dealing with json". And yeah, some of those things, like the json nonsense, shouldn't be showstoppers. But not having an idea of what the roadmap or timeline looks like is a big deal. No releases in a year is a big deal. So then you bring that up on the elm forums or the slack, and you end up getting blasted there too because now you're seen as criticizing this thing that everyone loves.
Obviously I'm just a jackass on the internet with more mouth than brains and I wouldn't hold your breath waiting for me to ever make anything as interesting or yes, successful, as Elm is right now. I appreciate the work you've put into making Elm as good as it is.
> what looks like the constant dismissal of any concerns about any of these issues any time they're brought up.
I remember earnest (and exhausting) discussions of these topics from back in like 2014, when it was unclear what the best way to scale Elm's development would be. We tried different approaches, but the outcomes weren't great.
We're actually still experimenting with this. For example, Evan wanted to put a community member in charge of the debugger, so he did...about a year ago. That experiment hasn't been fruitful (the debugger has not had a substantial release in that period), so we're trying handing it off to someone else. We'll see if that works better based on what we've learned from the previous attempt.
It's easy to say someone else should have taken it over sooner, but at the time there wasn't anyone else who understood the internals well enough to manage it, while also being interested in taking it over. Now there is.
Relatedly, I get that some bosses want to see a higher bus number on the compiler, but functioning teams of compiler authors don't just drop out of the sky. It's a rare specialization, and even among the few people who have the training to do major work on a compiler like Elm's, most are academically oriented and didn't go through a pH.D program so they could performance optimize Haskell code, make nice error messages even nicer, or find ways to remove language features rather than adding that cool new one they read about in a paper.
There's also communication. Evan used to give lots of updates about his progress on upcoming releases, and the main effect was to delay the release. He'd announce some progress and it would instantaneously become a Q&A - at best. Often people would pressure him to give up on whatever the latest impediment was and ship something sooner. If he didn't respond to those responses to his progress update, people would complain that he was unresponsive. So doing public updates strictly increased complaint volume, which of course also takes a toll on Evan, being a human and all.
> But not having an idea of what the roadmap or timeline looks like is a big deal.
The two options here are:
1) Be honest
2) Try to trick bosses
There isn't a world where Elm stakes out a roadmap and a release timeline and then hits it. Elm is trying to do a bunch of things differently than how they've been done before, which means each release is in some ways experimental, and also that each release changes substantially based on lessons learned from the previous release.
So yeah, it'd be possible to make up a bunch of "oh yeah, Feature A is gonna come out in April, and then B will land in July" but anyone could look back a year or two later and realize that the stated roadmap had barely any relationship to what actually happened. (People would complain about that too - that Evan wasn't sticking to the roadmap he'd laid out.)
We know from past releases that this is how it's gone (in my hubris, I told my editor at Manning I predicted Elm 0.19 would be out last summer) so there's no way to publish an official roadmap without knowingly misleading people.
If anyone considers it a red flag that there's no official timeline, well - that's because such a timeline wouldn't mean anything anyway. Evan's approach is to be open and honest about this. [0]
This is how we've ended up with a community of people who largely don't think it's a big deal: process of elimination. Everyone who considered it a deal breaker is still using JavaScript.
I don't know how helpful that all is, but maybe it sheds some light on the history of some of these things. :)
Maybe it would be useful to list your criticisms of the language? All Robert did was point out a single point about how NoRedInk's decision to go all in on Elm has been a net win on hiring, why such a negative comment without anything constructive being said?
His FrontEnd Masters course demonstrates this to be false. He was straightforward about the language and acknowledged shortcomings around things like JSON decoders, for example.
Furthermore, last I checked the source code doesn't live inside Evan's head like a family recipe. The functional principles and clear Haskell influences won't die if Evan were to go away.
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