I'm not seeing it in the docs, maybe I should write up a little something on my editing experience!
Also to correct my self, I think I mistakenly said `modal` when I should have said `buffer` earlier.
So searching across the project brings up your results in multiple buffers, each about 5 lines (expandable to more) and you can do all of your normal editing within each/all of the buffers.
If I happen to write something up, I'll try and remember to share it in this thread.
It does, though I found learning and setting it up to be more complicated. My preferred editor is one that's very simple to setup and use (e.g. Sublime, VSCode, Zed, nano). Emacs is cool, and maybe someday I'll get around to using it but so far it hasn't met my needs.
When I specified the modal editing I was referring to how the workspace search in Zed brings up each result in an editable "window" allowing me to make edits across my whole project from 1 tab. VSCode's workspace search feels much more limited in comparison.
For me the "killer feature" is a graphical editor (like VSCode or the Jet Brains editors) but with performance more like vim. I'm also very much enjoying the modal editing, which VSCode lacks.
Elm is like American politics. The most vocal people are divided as strongly as if they'd stabbed each other in the back. The majority people aren't vocal and just go about their day, sometimes using it and sometimes not.
My 2 cents. Don't use this place as a metric for whether or not something is successful or worth trying. 20 years ago this community would tell you not to use Ruby or Javascript, but today they'd call you an idiot for not using them.
Elm has easily saved me hundreds of hours per year in compile time alone, not to mentioned the likely thousands of hours it's saved me in time spent debugging. I still shudder to think of the horrendous compile times I got from even small TypeScript projects, and the days I'd waste trying to debug them.
I work on the app mentioned in the podcast. It is roughly 600k lines of Elm. I have previously worked at bigger, more well known companies, on apps 1/3 the size if not smaller. I've seen more frequent, and more reliable refactors in this Elm code than any I've worked in before. I'd easily take 1M lines of Elm over 100k lines of any JS framework, and I've worked with most of them.
There are a handful of people in the Elm Slack that work for companies that fit this description. I've seen everything from education to green energy and more. Might be a good place to ask. I know each of those companies needs back end devs, and likely had some non-Elm code as well.
How would these features replace TypeScript? TypeScript is more than just a syntax as it also requires a compiler, config, IDE tooling, and typically additional plugins to make it compatible with testing tools and bundlers.
Everyone keeps saying variations of "It would become possible to program (e.g.) TypeScript without compiling the source code." but that's not true. This proposal is only a subset of TypeScript, meaning that all of the existing TS infrastructure would remain and still be used. All this does is further bloat the ECAMScript for no gain.
This reminds me a lot of https://lamdera.com/, though more React and less Elm. Lamdera has the added benefit that changes are deployed in real time instead of having to reload, including in production. This means the user doesn't get those annoying popups saying something like "there are new features, refresh your page".
I had the opposite experience with my last job interview. I didn't know any Ember but I did know Elm (and other languages and frameworks). My enthusiasm about Elm absolutely contributed to my being hired and my lack of Ember knowledge didn't hurt me. This was what the hiring manager told me.
I have coworkers using Rails for the back end of their Elm app. I think NoRedInk is using some Rails and some Haskell. I've have a friend who uses Python for his back ends. Also heard that some people really like using F#, as well as Node.
We have a team at Square that uses Elm and I've made a few commits. They've been working on their app for around 18 months now.
I find it slightly funny because I also write Svelte at work and that app is public facing so it gets public attention but the Elm app is internal facing so the public will never see it. Also helps that Svelte uses its own name in the code it generates. Which is why I try to promote Elm myself. To semi-quote @SvelteSociety "@Square, a >$100 billon company, uses @elmlang."
Firstly, my wife would strongly disagree with you.
Your argument implies that women are given the option between many nearly identical pairs of pants, some with large pockets and some with small pockets. Instead they're presented with dozens of pants with only small pockets. Given the choice between pants with small pockets or no pants, they buy pants with small pockets.
Also to correct my self, I think I mistakenly said `modal` when I should have said `buffer` earlier.
So searching across the project brings up your results in multiple buffers, each about 5 lines (expandable to more) and you can do all of your normal editing within each/all of the buffers.
If I happen to write something up, I'll try and remember to share it in this thread.