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.
Wait, Zed is a modal editor? All i've seen is that it has vim mode, which most editors have and i generally find it insufficient.
Granted these days i still prefer Kakoune style modal editing (i use Helix, currently), so not sure i could move back to Vim style anyway. Nonetheless if Zed has real, first class support i'd be interested... but a second class compat layer is not sufficient in my view.
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.
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.
Fair enough, I have personally spent a decent chunk of time configuring my Emacs setup (though it has mostly stabilized at this point). You may be interested in checking out Doom Emacs[0] if you want to take a stab at it in the future. It sounds like it would be an out of the box experience closer to what you would want.
Do they have any compelling reason why "List<T>" isn't just "T List"? That's how they write it in OCaml. Then comma separated lists, are they mad? I much prefer how Uiua does this.
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.
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 agree that there are problems with limiting this to a subset. But for the most part it’s a very good subset that mostly only removes features which would be rejected if proposed today, because they have runtime semantics. This would effectively deprecate those features in the real world. I’m in the minority who likes enums, but I can live without them. The real, big gap here is JSX. But that rightly should be a separate proposal. I just want them to consider it a prerequisite, to avoid fracturing that aspect of TS.
I agree. The TC39 committee process has had a lot of advantages in modernizing the language, but in the last 3-5 years we've seen the pace of merging new language features grow in an unprecedented fashion. There are advantages to evolving the language but there is also a risk that the syntax becomes bloated if there is not enough deliberation within the standards process.
I like the idea of TypeScript, and am learning it, but am disappointed that we're still using build systems for JavaScript. I thought modules, HTTP2, and evergreen browsers would allow us to write just plain JS (like the olden times!), and not have to worry about bundling, but I guess not.
You'll still want to compile (or more specifically, type-check and minimise), but you'll probably be able to run your TS code without compiling, if you stick to that subset - but that'll likely be pretty easy. I'm imagining lint rules like the ones we're using to restrict ourselves to const and let instead of var, and things we'll quickly internalise like avoiding enums, and things we're no longer using anyway, like namespaces. Yes, it's a subset, but includes enough that you don't need the infra to run it.
This was my first thought as well, but I do think it could still be useful, even if not all TypeScript can be run as pure JavaScript. There's a lot of use cases where some type hinting would be useful, but the full feature set of TypeScript is not necessary. Long term, I could see a world where these features effectively replace TypeScript, which could help simplify dev pipelines.
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.
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.
