"Make the Back-End Team Jealous: Elm in Production" by Richard Feldman

[@NoAlbatross]

Outstanding. I had wanted to do a talk on Elm for my company's devcon, but showing this video is the way to go. For one thing, no one will believe how easy and pleasant Elm is. You make the point nicely!

[@RasmusWriedtLarsen]

I feel like this is a great introduction to some of the awesomeness of functional programming to all the bewildered js lovers :) Also really makes me want to check out elm in more depth.

[@aion2177]

A video on Time Traveling Debugger can be seen here. kzbin.info/www/bejne/rISWqq2LpJyfbrs. Make sure you first watch "Inventing on principle" by Bret Victor. The elm debugger was greatly improved since then.

[@gewalli]

Great talk. Is there any good examples of the type of interop you are talking about (when switching an app from regular js)?

[@hondinatos]

Using ports to talk with javascript like an API: guide.elm-lang.org/interop/javascript.html

[@MiracleBlueOfficial]

In the TodoMVC perf, what versions of each framework was used for the test?

[@BorisBarroso]

Instead of why can't be ruby more like elm, just use Elixir

[@ZhioN360]

The compiler magic doesn't really solve the problem of back-tracing a nonexistent or undefined variable. It's fine in such a simple example, but in complex apps I'll still need to go weed-whacking for half an hour to find out where the problem is. In terms of the UX of the language, it's nowhere near languages like Python or Ruby (Maybe.withDefault 0?). That said, it enforces a really secure way of working that JavaScript currently lacks, which I think is nice.

[@qwerty-mz8is]

+Byron Houwens Have you even tried Elm or Haskell ? You will never get a undefined variable in runtime. The DX is awesome, it's just different.

[@MichaelCampbell01]

In elm there ARE no non-existent or undefined variables, so... there's that.

[@Fabroskii]

First impressions: there is *NO WAY* I am going to start writing code like `first = Maybe.withDefault 0 (List.head numbers)` After watching in full, it turns out this is just advertorial propaganda trying to build support for a new attempt at enforcing a coding standard on top of javascript. All the "bugs" this "amazing" compiler "catches", simply aren't a problem for skilled developers who pay attention to what they are writing. This is just another layer, existing only to try and move software development into the realm of people incapable of thinking like a programmer.

[@oliverweiler8113]

+Fabroskii Kids these days...

[@tryptamigo]

+Fabroskii that you don't yet understand why "Maybe.withDefault 0 (List.head numbers)" is vastly superior to "numbers[0]" only suggests that you are inexperienced with all the problems it solves.

[@Tibaltube]

+Fabroskii there's nothing unusual here, with js you can always write: var const = numbers[0] || 0; Though it would be great if compiler could find this potential problem for me.

[@ZhioN360]

+Dan Neumann The problem is not with the catches the "superior" option will make, the problem is with actually writing such a thing out. In terms of UX, what the hell is a Maybe? And why do I have to declare its withDefault method on something that shouldn't have anything to do with it? Really, it could have used something like "numbers[0]" and invisibly made default values on its own, instead of using cryptic internal systems. I suppose that comes with learning a new language, true, but anything to decrease the learning curve will increase adoption.

[@MrPatrikNygren]

+Byron Houwens the thing is that "Maybe Int" is a type. So this is for ensuring that the compiler catches the error at compile time and not during run time. I guess you could do a lot of these checks for undefined or null or something, but Maybe is more describing that it Maybe returns a value, it is being more declarative about the insecurity. And all functions using this Maybe Int needs to take the case that it could return a Null value into account. If you forget to handle that case. The compiler will tell you again.