It does fit here very good I think ! 
1 Like
I posted a lightly edited version of one of the links I shared:
https://github.com/elm/compiler/blob/master/roadmap.md
I hope this file is helpful to regulars on discourse who might see threads like this one. Exploring compilation techniques and targets is quite slow and uncertain work, so I appreciate people’s patience while I try to figure out what can really be done in that direction.
Again, for whoever has access to the FAQ, please DM if there are other things to coordinate on.
19 Likes
Thank you for that, I think that is a step in the right direction
Taking a step back , I have found that working in this looser style has produced a high baseline of quality, and I think that is an important part of Elm
I think so too… it allows to approach its design holistically based on experiments and their results…
If you need help with anything, don’t hesitate to ask ! That could be even the smallest thing ! Don’t fear entropy 
Have a nice day, and thank you very very much for all this dedication and commitment ! Awesome
There are many axes along which one can compare Elm to other languages and frameworks. I’d like to mention just one: the ease and safety of refactoring.
Refactoring is the only way a code base can reliably grow in size, expand in scope, and be sanely maintained over the long term. This task is both riskier and more costly in developer-hours and dollars for languages that are (a) not compiled, (b) lack an expressive type system.
Elm has an outstanding type system and is compiled, so is a high-scorer on this axis. That is one reason why it is my preferred tool. Aside from personal preferences, however, there is a serious business issue. Time is money, and in any case is a limited resource. Less time spent debugging and refactoring means more time for productive work, e.g., advancing the project in ways that will please the users and generate revenue for the company.
++++++++
Oh — one more thing: the compiler is fast!
7 Likes
I also strongly recommend publishing a post the Elm blog. The Elm slack and subreddit have had frequent posts of concern about Elm’s future lately. The roadmap in the compiler repo is a good first step, but I don’t think it’s enough.
It’s currently really hard to convince people that the compiler or the core library are going to receive (substantial) updates, or that Elm can keep up with the web platform with the limited opportunity for outside contributions. I am not seeing Elm staying competitive without support for web workers, WebRTC, non HTTP transports and the like. “use ports” is not a strong argument.
@evancz it’s great to hear that you’re still able to work on Elm full-time. That’s worth (re-)stating publicly too, in the light of rumours in e.g. the Elm subreddit.
Given the the positive blog posts like the Rakuten one mentioned in this thread, maybe the post could round up positive experiences from the last year or so? There’s bunch of great things going on, like `elm-3d-scene´ and work on the WebGL support.
3 Likes
I am curious, what makes you think this?
I wonder if the existence of Reddit /r/elm does more harm than good. Would a proposal to close it down be out of order?
3 Likes
Generally, I think drama just catches people’s attention better, which is why I think it’s good to make an effort to shut it down. To an outsider, Luke’s post looks like it has valid concerns that are being ignored. Yeah, there’s a few tweets about it, but looking at reddit, Luke’s post is the all time highest rated post on the sub-reddit. Then comes a few posts about new releases, and then there’s a post titled “Evan’s response to ‘Why I’m leaving Elm’ is less than ideal.”
But there’s no post titled “What we learned from Luke’s situation” or something like that. People who are very involved in Elm may not consider it as something that needs to be done something about, but to an outsider, I would think it looks like an open wound that is barely being addressed. And that doesn’t look healthy at all, and greatly increases any feelings of uneasiness.
As for the Rakuten post, I’ve never seen that before, so I’m not sure where it got posted? It’s not on reddit or Discourse AFAIK, so I’m guessing people who just frequent those pages (which is the pattern I follow at least), don’t get that feeling that Luke’s post has been sufficiently addressed.
3 Likes
Closing down /r/elm would be sweeping problems under the rug.
It takes extra effort to join Discourse or Slack, but folks with Reddit accounts can relatively easily post their experiences of Elm and up/downvote posts to the subreddit. Of course the low barrier may result in low-quality posts, but at least it’s not the kind of echo chamber that the Elm Slack and Discourse can be. If the nature of /r/elm is critical, maybe that’s the average experience of casual Elm users. Something to consider.
In the best case the subreddit offers extra exposure [of Elm] to folks who are interested in Elm, but don’t want to keep tabs on e.g. the Slack (they see top content in their home feed).
3 Likes
It’s not on reddit or Discourse AFAIK
I submitted this post five days ago on reddit, but I could not see it in the timeline for several days… now seems to be there. Not sure why, maybe because I am posting from a new account…
https://www.reddit.com/r/elm/comments/l7is2e/elm_at_rakuten_dev_community/
1 Like
I often suggest that blog posts are a great way to contribute to the Elm community. Anyone in the whole world can write posts about projects like elm-spa or elm-tooling or elm-optimize-level-2 or elm-review or whatever else, and it does not need to be the authors of those projects. Creating those projects is hard enough on its own, and I am sure those authors would appreciate a surprise blog post from a happy user. If that happy user can get it on /r/programming or HN, hey, that’s great too.
Someone who thinks such posts are vitally important to Elm does not need to do any coordination with anyone else to make it happen. They can just do this. No one is blocked. It doesn’t need to be on any particular domain. Try to write the top post of /r/elm. Talk to people to get admin on there. DM people about questions you might have about a post you are writing. Etc. Take the initiative yourself.
18 Likes
Hi Rupert, you mistake me — I don’t think this — this is the impression that my client expressed having investigated Elm on the basis of my recommendation.
The client didn’t give a list of posts they’d read but…
This thread has lots in it. It in itself if worth pointing my client to I think as evidence. I was hoping that there’d be lots of good points made, and there are. So thanks again. (To all!)
4 Likes
@evancz It’s absolutely a boon to have the community write blog posts about Elm. Lately the Rakuten one and “Safe dead code removal in a pure functional language” have been the kind of posts I like to share to non-Elm users (colleagues and such). I do my part with the Liikennematto series and by endorsing Elm when writing about TypeScript.
Yet a blog post by you e.g. in the Elm news has more weight. The latest one was the announcement of 0.19.1, posted 15 months ago. I maintain that a “sign on life” from you would be welcome to folks endorsing Elm.
I know how you feel about demands from open source communities, and I am not demanding you to write a blog post, just a recommendation based on the observed uncertainty of Elm’s future.
The way I see it, the post pretty much writes itself. Something like this (please don’t take the phrasing too seriously):
Hi, Evan here. Still alive, still working on Elm full-time.
Elm as a language is stable and doesn’t urgently need new features. Elm as a platform has been growing by great community contributions, such as elm-review and elm-tooling. New libraries such as elm-3d-scene and elm-csv give way to new applications for Elm.
[a concise version of the roadmap.md goes here]
[maybe a roundup of interesting blog posts from the community here]
8 Likes
I remember seeing that traffic simulation post. Very nice work!
It is important to me that the News page is about concrete technical results in the compiler and core libraries. I do not want to run a blog or news aggregation service from that page, nor do I want to promise future technical results that I may not be able to deliver on.
I have changed some of the text on that page to try to address your concerns a different way.
If you want to write and maintain a “roundup of interesting blog posts” I am happy to link to something at elm-community.org that has “top posts of the last six months” or whatever. I cannot be the one who maintains such a list into the future though.
15 Likes
Hey Evan, I quite understand what you mean by the way of how you want to structure the blog. But please don’t forget the trade offs this implies… The community is offering improvements about communication here, finding balances for what is written in the elm blog is also important for adoption. It is difficult to communicate further things, if you just put this in the “news aggregation category”. Maybe it is a good approach to think about about the “categories” of which you want to communicate besides technical compiler results (Is it always only about results, if any ? Or is it also about the way to these results?)
I think the community wants to encourage you to improve the “elm (compiler)<->outside world” communication.
In case it helps create some balance here, I’m happy to throw in how we approach the Elm vs X decision at my company.
We’re all-in on Elm for our own products (circa 55k lines of Elm on in-market, multi-year projects) for all the great benefits I don’t have to explain to this audience, and but we’ve so far never offered Elm for our consulting customers (where we either advocate for consistency with their existing stack, or we recommend React).
For me that’s always come down to a principle of “least surprise” (ie financial stakeholders can remain bored with the technical aspects of projects they fund, rather than having to learn/remember that the inclusion of some non-commodity tech/skill may complicate a future hire or consulting engagement), and generally being conservative with other people’s money (ie the old “no-one gets fired for choosing IBM”).
The 2 key messages I’d like to promote here are -
-
A sincere thank you to Evan, and to everyone across the Elm community, for making such a robust and joyful technology. Every time I work in Elm on our healthcare products I just want to smile. Hide in a forest for years at a time if that’s what you want to do - you owe me nothing, and I’ll stay this grateful.
-
I believe that suitability of any technology for a client project, Elm included, is generally more about that client’s team/plans and the wider macro-economics at the time you’re providing advice, than it is about a particular technology or its trajectory.
If it’s a small project or your own company, it probably doesn’t matter what you choose. If the project will cost someone enough money that they ought to pursue damages if they think it was unwisely invested, or if the choices might reasonably affect future recruitment decisions, be a grown up and act responsibly. I don’t personally enjoy React or .NET, but they’re easy to recruit, and they certainly won’t be the reason a software project fails, even if they’re not sexy or best-in-class technology.
6 Likes
Thank you! The changes to the News page are another step in the right direction, and will improve the discoverability of community contributions.
The Elm Weekly newsletter is probably the best aggregation of fresh and interesting community content (blog posts, talks, books etc.). Maybe that’s also worth mentioning?
5 Likes
If financial interests are bored by the tech choices involved in a project, you have to wonder why they would be against using Elm - surely if they are bored, the don’t care what tech stack is used? The money side hires a good tech lead, and defers those choices to them.
I also think there is a strong argument as to why Elm can be superior in terms of costs to the alternatives. One of the premises of agile methods is that the further along the lifecycle of software development a bug is found, the more it costs to fix (so we develop/test/deploy in small increments and find the bugs early). The Elm compiler is very strong in this regard, an entire class of bugs are completely eliminated by it. Tony Hoare - Wikipedia and “The Billion Dollar Mistake”.
The money side should be positively ecstatic about this - Wow, how mcuh money are we going to save over the entire project? The total cost of ownership can be greatly reduced by using Elm!
Also, what about maintenance costs? Elm is great to refactor, and the same cannot be said of the alternatives. Software is hard to kill off once it gets into production, maintenance costs commonly outweigh the initial setup costs. To give an example from my own experience, the legacy Java project I am working on at the moment carries such massive technical debt combined with high operational risk that I am expected to add about 1 medium sized feature to it over roughly 3 months. A language that can improve over this kind of situation has a huge potential $ value.
3 Likes
Yes, that is true. The Software Lifecycle is a major cost point. Elm does increase the lifecycle of a Project much (if you mostly use Elm), but it also does delegate parts of it’s inability to work with most of Browser APIs to Javascript. So it also sacrifices a lot.
1 Like