having worked in Elm in anger for a handful weeks all I can say its been a near religious experience.

I'm so much more productive than I used to be in CLJS is off the charts,

OFF. THE. CHARTS.

@martintrojer: A few people have commented that the tooling is considerably less mature. Do you agree?

I think Elm tooling > CLJS

Emacs integration pretty great

Interesting, good to know.

So you’re using it for work?

Compilation errors, and navigate back to the source

For work yes, we are re-writing a 20k CLJS app

I think there are pretty sweet looking modes for light table and Atom, too.

Wow, removing your legacy code 🙂

You’re at Juxt, right? How do your co-workers like it?

The think that clinches it for me (with regard to dev-setup) is how amazingly fast the Elm compiler / REPL is. That gives me a much more pleasurable dev experience than the sluggishness of figwheel and bloody google closure

Yeah, I can see that. Does it have a figwheel-type-thing?

I mean, a scratch build of the Elm prod artefact is ~10 seconds. The equivalent CLJS build is 6-7 minutes!

No shit.

Wow.

Yeah, cljs is just terrible

Re; figwheel-type-thing, Elm complier errors is pretty much state of the art. I haven't seen any other language even close.,

I meant in terms of live reloading.

And yeah, I love those errors.

Oh yeah, basically I don't to that (yet), its so fast so reloading the pages is fine.

Interesting.

but, Elm support pretty wicked hot reload (and time-travelling debuggers)

Yeah, that looks very nice.

but the basic setup is so great I haven't felt the need to setup hot reload.

I mean, CLJS dev withjout figwheel is just not possible, and its still not particularly good.

I’m keen to know about JS interop too, but I have to step out for a bit. I’ll be back later on.

martintrojer: really? is it that good?

martintrojer: were you using cljs and reagent?

martintrojer: I was thinking about investing some time with Elm

CLJS, Reagent, figwheel ofc

don't waste your time on cljs if you're considering Elm

martintrojer: wow.

martintrojer: you almost got me excited. How is the interop with js? Also what do you guys use for the backend - clojure or elixir? (I heard a lot of Elm folks like Elixir)

Clojure backend (I'm am/was a Clojure dude)

martintrojer: any plans to change the backend to something else?

not immediately, Clojure works better on the backend. Still looking for alternatives.

I'm blogging about my quest if you're interested

martintrojer: sure. Golang works well for some... https://www.reddit.com/r/golang/comments/4r8ah1/do_you_know_of_a_company_who_moved_from_golang_to/

markmandel: can you link me to your blog

golang doesn't pass the bar for me.

http://martintrojer.github.io/categories.html#beyond-clojure-ref

"Beyond Clojure"

have a number of in the pipe

racket?

so, what I'm looking for;

1. FP

2. Expression based

3. No nulls

4. ML-like type system

5. Practical, i.e. good library ecosystem

6. Something I can live with in prod

so golang, racket, elixir are out

what you're looking for doesn't exist yet

looking at; ocaml/reason, haskell, F#, Purescript, rust

markmandel: Elm doest not have point 5 as far as I know

don't agree, Elm is very practical

markmandel: oh how does F# compare to clojure in your opinion, i also considered looking at it

markmandel: Elm is not mature enough to have a good library ecosystem, isn't it

learning F# also means getting familiar with .Net ecosystem..I'll probably postpone that to another year lol

> Elm is not mature enough to have a good library ecosystem, isn't it

Totally disagree with this ^^^

martintrojer: I see. that's good to know I'll give it a shot.

I wish clojure had elm error messages; i would be in heaven

@lewix: http://www.compoundtheory.com/ is ma blog

markmandel: thanks

markmandel: any nice article that you want me to see?

isn't Elm's interop with vanilla js libraries still somewhat wonky?

as in, you have to use the ports system

I wouldn’t call that "wonky" — I’d call it a well thought out abstraction to keep impure code effects out of the Elm side of your app.

Elm has tried (and rejected) a number of interop abstractions and what it has today is pretty darn good. I followed the evolution of Elm for a long time (and was pretty involved in some of the language design discussions for a while). I think Evan and his team have done an amazing job in many areas.

I think the recent "course correction" away from FRP terminology is also a smart move, enabled by baking certain concepts into the runtime, to allow a more pure way to write your code. This mirrors the early decisions to avoid the "M" word and some other terminology that can distract from elegant abstractions and concepts.

which concepts have been baked into the runtime? The move away from FRP has definitely interested me, seems like it'd make a lot of applications more feasible

@lewix: ALL OF THEM 😄

lol

@scriptor: Essentially replacing FRP terminology with subscriptions and commands (baked into the runtime)

I wrote this little Elm program for fun one weekend, to get myself back up to speed on the latest changes (since I’d been away from the language since before the FRP course correction): https://github.com/seancorfield/solar-viewer/blob/master/src/Main.elm

I think that’s very elegant in terms of architectural separation (I could easily break it into separate modules at this point).