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.

There are Forth like languages, such as Kitten, that have variables and more.

https://kittenlang.org/

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.

The guide has a whole section about web components/custom elements https://guide.elm-lang.org/interop/custom_elements.html. I've also found them useful in my code outside of Elm as they work in vanilla JS.

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.

Or if you want to do Elm full stack there's https://lamdera.com/ or https://package.elm-lang.org/packages/choonkeat/elm-fullstac....

A little history of why Rust's error messages look and read they way they do:

- [1] back in 2015 Elm puts out a blog post titled Compiler Errors for Humans

- [2] then another, Compilers as assistants

- [3] then in 2016 Rust announces they'll borrow from Elm for error messages

Really great that the students were able to see how much the Rust community cares about error message quality.

1. https://elm-lang.org/news/compiler-errors-for-humans

2. https://elm-lang.org/news/compilers-as-assistants

3. https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...

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.

There's also https://github.com/xbmc/elm-chorus

https://github.com/rtfeldman/elm-spa-example is a good example app. I'd also recommend https://codebase.show/projects/realworld in general if you're looking for example apps in various frameworks and languages. I sadly can't share anything from work as it's all private.

I've seen some people mention using https://tauri.studio/en/ for building desktop apps with Elm, and others using https://www.electronjs.org/. I've also toyed with https://deno.land/x/webview though it's still very young.

I don't think elm-desktop-app is abandoned, just that the author is working on other things at the moment. The author is has been working on another Elm tool, and fixed a couple elm-format bugs too.

Feel free to reach out in the Elm Slack or Discourse if you have any more detailed questions. I know there's been discussions in the https://discourse.elm-lang.org/ around desktop apps too if you want to search there.

Did you try out https://package.elm-lang.org/packages/cmditch/elm-bigint/lat...? I've used that for things that I know exceed the browsers limits with JS numbers. Had to use it recently with something that returned a JS BigInt (which was a whole other buggy problem).

Having spent the past year plus in very large (over 1M loc) and old (10+ years) Ember code bases and having used it about 6-7 years ago I can confidently say that Ember has a very different mantra. Ember's selling point for many years has been "If you know Ember at company A then you know Ember at every company" (paraphrasing here). I've found this to not only not hold true, but to be very unhelpful for onboarding new developers. Conversely I've onboarded devs onto Elm projects with lots of ease.

Those Ember diehards definitely still exist too, I work with a lot of them. They, like a lot of the Elm die hards, are also really kind people and great devs. The main difference I've seen is that Elm devs get to spend most of their time building features while the Ember devs end up spending much of their time trying to keep up with Ember and a lot of time dealing with project build bugs and infra.

I've also been writing React on and off for around 6 years and can confidently say that React doesn't suffer from maintenance issues in the same way that Ember does. Where it does fall short of Elm, even when including TypeScript, is both speed (both build and runtime performance) and ease of refactoring.

I've also spent the past 2 months working on a small-ish Svelte + TypeScript app. That's probably the closest I've come to the experience of using Elm. It's runtime performance is on par with Elm, sometimes faster and sometimes slower. It's build time is still a bit slow, mostly due to TypeScript, and it's onboarding is quite quick for someone who already knows HTML + CSS + JS. It still falls short when it comes to refactoring though as it just can't match the error messages that Elm is able to provide.

Just my 2 cents having used many of the frameworks for many years.

The javascript example gets further compounded by doing something like `object["prefix" + variable]`.

I've seen some very large companies abuse JS object proxies so that code is nearly impossible to follow even with the best IDEs and someone who's excellent at grepping.

In my 10 years of paid development, Elm. Because it's the only language of the 13+ I've used in production code where the compiler actually helps you.

I've written C, C++, C#, Java, JS ES5+, ActionScript, HTML5 and CSS since IE6, many various compile-toJS languages, many different frameworks and more. Elm is the only language where I can jump into a foreign code base or my own months later and feel confident that I can change something, push to production, and not break things.

edit: I've also written Perl and Ruby in production too.

edit2: How does it help? When you make a change that isn't valid, like adding a new argument to a function, the compiler can tell you everywhere you need to make a fix and sometimes even suggest how to fix things. Add on top of that the editor tooling in Intellij or with the elm-langauge-server in VSCode and other editors and it's just super smooth. Build times are also crazy fast. There's no waiting for the compiler. The whole notion of "If it compiles, it works" I find to be true 99% of the time.

I, as a JS dev of 10+ years, wouldn't consider this "modern". I didn't see

- for in loop - for of loop

as a couple examples, and those have been around for at least a few years now. There's probably more missing too. To what the above person said. The usage of "modern" or "latest" or similar is going to fall behind and make for bad searching.

Why not have tools that specialize and are strong in some areas instead of trying to have a Swiss Army Knife language? In other professions it's normal to have different tools for different tasks. Or is there something I'm missing?

I personally would be happy with many different languages that are focused on front end development, like how we already have many that are focused on back end development.

Type annotations aren't inline in all languages. If you're writing Haskell or Elm, as a few examples, then you get static types without having to write them out and if you do write them out they sit above the function that uses them.

I'd love for the study to include various types of static types. Testing against only C#/Java style type systems seems fairly narrow compared to the various kinda of static type systems available.

For me it depends on the style of static types. I do find Java or C#'s static types to be helpful, but also time consuming. Elm or Haskell on the other hand don't force me to write out the static types while still giving me the benefits of them.

There's also the case that I find the type systems of Rust, Elm, etc to be much more helpful than the type systems of C++ or Sorbet (type system for Ruby).