Elm is on a faster release cycle now, and 0.19.3 is out today. The post also has a rough roadmap of what to expect for the next few Elm releases.

This post is about one of my favorite aspects of the Acadia compiler, symbolic evaluation.

The compiler evaluates queries as much as possible at compile-time, so it is able to reduce `case` expressions, `let` expressions, etc. One neat outcome of this is that large expressions can sometimes be fully evaluated at compile-time, so they end up having no runtime cost at all!

I like this feature because it also only works because the query language is not Turing Complete. The design choices described in https://acadia.engineering/blog/solving-the-1-plus-N-query-p... that avoids 1+N patterns, also guarantees that queries terminate. This means they terminate whether you run them at runtime or at compile-time!

Anyway, the post also has an example app that uses https://github.com/acadia-engineering/elm-simple-server to run Elm code on the server, so maybe that is interesting as well.

I updated the official guide (https://guide.elm-lang.org/) to try to do a better job at that. It covers "routing" and JS interop much more clearly I think. So I recommend starting there and then asking around in the community if you run into anything!

It "scales well" because of shouldComponentUpdate. That lets you avoid building huge chunks of virtual DOM as your app becomes very large.

The trick is that the same exact optimization is available in Elm and Angular 2 (with different names) so the same argument applies there as well.

The "Do these results generalize?" section makes an argument as to why the numbers you see on a simple TodoMVC app should generalize to apps of any size. When everyone has the equivalent of shouldComponentUpdate, the question becomes: when you finally DO need an update, how fast is it? That can be measured in small apps.

I think it is worthwhile stopping by the Elm slack channel to ask this. You have framed the question in a weird way. The answer is kind of "these things are not really related in any direct way" but I feel like you are asking a different question. Point is, ask on the slack channel and folks will help clarify :)

Definitely not ignoring. I talk about the relation between Elm and that sort of stuff in https://youtu.be/Agu6jipKfYw Lots of things look similar in this area that are not.

I also offer an analysis of "higher order" observables in https://youtu.be/DfLvDFxcAIA, and the big difference is the underlying thread architecture you get using these two.

I hope I'll be able to make these sorts of things clearer in time!

They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what?

So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.

> The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.

To be fair you can do this in javascript as well using a messaging pattern similar to elm. Many libraries like postal.js (synchronous) and msngr.js (asynchronous) support a messaging pattern where you can access resources without caring who owns them.

That's Standard ML for you ^

I'm excited that Haskell could bring more developers to ML-family languages.

I'm sure we could keep going, but the point I'm making is that Elm is very close to Haskell, and if you like Elm you will definitely like Haskell. I don't know if the same can be said about going from Haskell to Standard ML because I haven't... yet.

I think so! I'd like to get Elm running way faster than JS in browsers (which is possible thanks to some design choices) and that'd involve getting all this together. That opens things up on lots of different platforms, including servers. I also expect the next release to make things nicer on node.js as a first step in this direction. Point is, I think we'll start seeing folks doing server stuff, and it's a goal of mine to generate machine code for lots of reasons! It's a big project so I'm not setting a timeline at this point though.

Also, thanks for taking a look at Elm! I think of it as a member of "the ML-family" of languages and I draw from a lot of lessons from working with these tools and seeing what issues have come up for other folks, both within the typed functional world and not.

Actually, while it's still not direct machine code, if you can target Javascript as a backend I bet you can target Lua, which has very similar but less weird semantics; that means you get to run it on LuaJIT. That gives you a tiny, very very fast VM and garbage collector.

I'd be very happy with Elm compiled to WebAssembly as a stepping stone on the way to fully native :)

You need a garbage collector either way, so doing one implies you have pretty much succeeded at the other. So it's like two stepping stones that are right next to each other and quite a long jump away :P I think we'll get there though!

You can do stuff in JS really easily with [ports](http://elm-lang.org/learn/Ports.elm).

The TodoMVC example in Elm does this to use localStorage: https://github.com/evancz/elm-todomvc/blob/master/Todo.elm#L... and https://github.com/evancz/elm-todomvc/blob/master/index.html...

The same can be done for HTTP or WebSockets if you have needs that are not met by the existing APIs. Furthermore, the next major release is focused on drastically improving these APIs.

So there's a safety valve right now and there's a plan of how to make things excellent. I would not block on this, but I am also relatively biased :)