wolfadex

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.

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.