This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-06
Channels
- # admin-announcements (2)
- # boot (51)
- # bristol-clojurians (1)
- # capetown (14)
- # cider (4)
- # cljs-dev (3)
- # cljsrn (23)
- # clojure (76)
- # clojure-gamedev (2)
- # clojure-germany (2)
- # clojure-greece (2)
- # clojure-hk (5)
- # clojure-poland (1)
- # clojure-quebec (3)
- # clojure-russia (19)
- # clojure-spec (7)
- # clojure-sweden (10)
- # clojure-uk (77)
- # clojurescript (42)
- # clojurex (5)
- # core-async (40)
- # cursive (12)
- # datomic (58)
- # editors (1)
- # events (1)
- # heroku (1)
- # hoplon (4)
- # jobs (6)
- # jobs-discuss (1)
- # ldnclj (2)
- # lein-figwheel (1)
- # leiningen (5)
- # om (66)
- # onyx (51)
- # other-languages (80)
- # proton (20)
- # protorepl (12)
- # quil (3)
- # re-frame (3)
- # reagent (18)
- # spacemacs (14)
- # untangled (78)
- # yada (16)
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
Compilation errors, and navigate back to the source
For work yes, we are re-writing a 20k CLJS app
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
I mean, a scratch build of the Elm prod artefact is ~10 seconds. The equivalent CLJS build is 6-7 minutes!
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.,
Oh yeah, basically I don't to that (yet), its so fast so reloading the pages is fine.
but, Elm support pretty wicked hot reload (and time-travelling debuggers)
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.
CLJS, Reagent, figwheel ofc
don't waste your time on cljs if you're considering Elm
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)
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/
golang doesn't pass the bar for me.
"Beyond Clojure"
have a number of in the pipe
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
looking at; ocaml/reason, haskell, F#, Purescript, rust
don't agree, Elm is very practical
markmandel: oh how does F# compare to clojure in your opinion, i also considered looking at 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 ^^^
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 😄
@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).