Was checking out reason, basically let’s you type ocaml to generate readable statically typed js using bucklescript. Was interested to see some familiar elixir terms like pattern matching and tuples. Plus elements of closurescript etc
That said, my main dislikes of Reason is the documentation side of things. Elixir devs are fortunate to have a built-in documentation generator, hexdocs.pm, and hex.pm that links to hexdocs. All parts of Elixir (The compiler, the syntax, etc) are all in one place and documentation is in one place. Reason has none of this.
There’s ODoc, but it’s nowhere near HexDoc. There isn’t community standard way of doing documentation like hexdoc is. The reason syntax documentation is separate from BuckleScript’s documentation (the OCaml -> JS compiler), the native compiler’s package manager documentation is separate, etc etc. Lots of things are separate documentation-wise.
Fortunately, all of that is fixable and is being attempted, but at the moment I’ve been spoiled by Elixir and I want generated docs for all of my modules/functions in Reason as well
Bucklescript was the interesting part to me, the elixir pattern matching and tuples is similar to reasons ocaml implementation, just suggested a bucklescript style elixir/Phx to js compiler. No idea what or why I would want it. But maybe be interesting as it’s designed to help build out react code. Maybe a Phx gen to create a ui js view model that matches the struct.
I do tend to just imagine what would happen if you lift and shift the paradigms between stacks
Not sure if I imagined it but I seem to remember a podcast with some guy using asts to do some type of compiler with elixir and js???
I fought long and hard with ReasonML, I find it rather messy, especially because of BuckleScript, the way it interacts with JS, the documentation, and so on. I was constantly guessing. Somehow I felt also like I was learning not one but three languages (Reason, BuckleScript, and OCaml) - it just didn’t seem practical.
I initially liked elm because it has nice Haskell-isms like partial application while feeling a lot like elixir, but I ultimately ended up being boxed in by it enforcing its own view what every application must conform to - this Model-View-Controller-like central framework. The elm project, IIRC, kind of said they preferred to box elm in and limit the interaction with other libs and JS code even if that took longer to grow organically. Only problem - I did not find the box they had built so useful I would subscribe to that line of thought. YMMV. It certainly did not help to integrate this into my project. I ended up liking elm a lot initially, then using it the least.
(I basically reimplemented a basic version of my project in ReasonML, tried in elm but discarded that, then did another implementation of the basic version in purescript which ended up becoming the most feature-rich.)
I liked purescript the most out of the three. It is no doubt a tall order to learn, but I like their take on the Haskell language. I learned a lot, like using “lenses” to replicate what I do with
update_in/2. It did not require me to leave the purescript world needlessly (like ReasonML), nor did it box me in (like elm), it was sufficiently documented to learn, etc.
In the end, however, using either is just plain unproductive because the price paid for the enhanced type systems is much higher than what I get for it. Yes, sometimes some clever-written code can infer a lot of stuff from types for you - especially in purescript. But the degree of freedom and productivity I enjoy in elixir or Clojure (or any Lisp or Scheme) wins hands down over these type-heavies. I simply love coding in elixir and Lisp-likes because it brings me to a sweet spot between functional programming, productivity, and fun in a way that a more puristic approach does not.
What I got out of the whole endeavor is some code I can show at interviews.
elixirscript seems to have evolved further since I last checked (at the time), and clojurescript seems to be hot stuff right now.