Did anybody use Reason with bucklescript-tea, and how was the overall experience?

General Prog (Archived)
, ,
1

In the pursuit of writing front-end in a functional language (to feel at home, while developing the back-end in Elixir which is also functional) I tried Elm 0.18 a bit. Though I liked Elm because it’s functional and have all the batteries included which we will have to add to JavaScript ourselves, like virtual-dom, bundler, static type checking, immutability, state-management etc as shown in the following image.

Screenshot%20from%202018-09-16%2005-01-01
Screenshot%20from%202018-09-16%2005-01-01736×548 82.7 KB

But I have some problems using Elm:

  1. The absence of syntactic code boundaries (like curly braces or do-end), which was the reason I preferred Ruby over Python, when I was new to programming.
    indentation-based-languages

  2. The time some important libraries will take to update for the newest version of the language (0.19) if I’m using the newest version.

  3. Absence of some proper tool to remove dead code safely (a simple Hello World application is composed of almost 8000 lines of code).

I’m inclining towards ReasonML because it has proper code boundaries instead of using indentation, its support for React-Native is also better (in case I needed that in future), and it’s support for dead code elimination hence smaller file size.

Screenshot%20from%202018-09-16%2005-23-20

So this was the story about why I inclined towards ReasonML, but I’m curious if the experience of using Reason with @OvermindDL1’s is as good as using Elm? What are people’s experience with using this combination for some real-world project and what are some learning resources for ReasonML?

@OvermindDL1 @peerreynders @gon782 @ChaseGilliam @bobbypriambodo @ShalokShalom @gon782

1 Like
2

We use OCaml + bucklescript-tea for a few small apps with a base of shared code. All in all it’s something like 3k lines that deal with i18n, Google tag manager support, a type safe interface to localstorage and regular TEA code.

They’re not big apps so I can’t speak to that, but I can tell you that growing them and adding features is very enjoyable. A lot of the code that deals with external things is actually functor code that is there to put type safe interfaces on those external things. In Elm this would take the shape of serialization/deserialization at the border by way of ports, but with OCaml I’ve simply elected to make functors that generate modules that simply cannot be misused instead and so will tell you about it at compile-time, with proper type support. It makes things like interacting with GTM/LocalStorage/everything else in JS so much more controlled.

All in all our OCaml + bucklescript-tea bits are my favorite part of our code base. I wish more of my work was spent on it, actually.

To address some of your issues with Elm more specifically, though:

  1. To each his own.

  2. This is true for any eco-system, really. Elm does move fast, though, so I see your point. We’ve had some issues with bucklescript libraries not keeping up and having to juggle versions for a bit, plus odd build tool changes throughout version changes. It’s not something you will completely avoid, switching to BS.

  3. This can be solved pretty easily via something like rollup, as far as I know. It’s nice that BS already does a lot of this beforehand but I wouldn’t think it was an issue in actual projects.

There are plenty of reasons pertaining to the Elm language to simply want something else and I feel like the above points are very superficial. You might instead want to think about what the language and technologies actually provide in terms of abstractions.

Elm is a half-way Haskell, OCaml is a complete language that although it’s certainly not as ergonomic as Haskell and it’s lacking many of the tools that Haskell provides, it never does anything half-way. It gives you the highest language-construct/power ratio I’ve ever seen and it has kept all of its core values while doing so (compilation speed, no ambiguity, performance, etc.).

I would actually advise you to look further into Elm and see if you have any actual issues with it. There are lots of people who think the tools of abstraction you have in Elm are plenty and you might be one of those people. These peripheral issues that you’ve listed are issues you can see on a web-page presenting the language, not something you’d necessarily consider in an actual project.

Edit:

Just to add as well, we had many build issues with BuckleScript. Both brunch and rollup were actually non-starters as they both had odd build errors together with some of the BS libraries we were using. All in all, fitting BS into our build process wasn’t a walk in the park and it’s unlikely you’d have as many issues with Elm. Fixing these issues was something no one had any real idea about as “it works for them”.

4 Likes
3

Thank you @gon782 for the encouragement and suggesting to look again into Elm. I’ll use it again for some days and see if I’m getting used to the Elm’s indentation based nature (the biggest problem I have with Elm), other two problems I listed (dead code removal and libraries being updated to 0.19) are actually the problems of Elm and its community, so they might be solved at some point.
Right now I’ll use version 0.18 and when the libraries I need are updated for version 0.19, then I’ll try to update it to version 0.19.

Thank you again!

2 Likes
4

You solved a big problem for me. From the last 2 days I looked into Elm, bucklescript, ReasonML, Purescript and Cycle.js, calculated pros and cons of each, read blog posts about each, watched videos (from different conferences) and every blog post / conference video was glorifying their favorite tool. The more I thought, the more I got confused which one to use.

1 Like
5

Is there anybody left who sees an advantage of Elm over OCaml, ReasonML, Bucklescript?

1 Like
6

In my view @gon782 assessment is on target.

I would view none of the reasons you list as show stoppers - really more as nuisances. So really the tradeoff question becomes how much are you willing to put up with to get the benefits that you perceive in the Elm TEA?

Things you haven’t mentioned:

  • Others report that due to the lack of Haskell/OCaml-style type system features you can easily find yourself in a situation were you have to “write and maintain a lot of boilerplate”.
  • If you need to access to some part of the Web API that hasn’t been yet made directly accessible then you are going to have to write your own “anti-corruption façade API” in JavaScript to make any needed functionality available via ports and subscriptions.

With the other choices:

  • ReasonML is largely coupled to ReasonReact, so you better be OK with that. Personally I see React Native as a fools errand because “Hybrid Franken Apps” have a tendency to create entirely new problems leading to solution fragility/rigidity/brittleness.

  • BuckleScript as such has even less learning materials available than ReasonML (ignoring the pure OCaml resources) and I don’t see that changing - it’s likely that educational resources will see better growth in the ReasonML space for some time to come (largely depending on Facebook’s commitment).

2 Likes
7

There is a lot of OCaml resources available though. :slight_smile:

But still, I know of quite a few people using ReasonML with bucklescript-tea, I get questions and comments and thanks and all pretty routinely in a variety of sources along with people linking me various open source uses of it, it is all really cool (this never happened in another language-specific community I was with)! :slight_smile:

But yeah, ReasonML is just a re-syntax on OCaml and you can convert between them freely (reason even comes with a tool for it, since that tool is how it converts to ocaml to use on the ocaml/bs compiler). :slight_smile:

I do need to get around do using it’s syntax extentions as some better features in areas, but that’s all fluff at this point. :slight_smile:

2 Likes
8

What quantifies as “a lot”? From a beginners perspective there are the OCaml tutorials and OCaml from the Very Beginning / More OCaml: Algorithms, Methods & Diversions - I don’t think of Real World OCaml as beginner’s material; you’ve better have made your peace with FP already.

And learning OCaml still leaves a gap about how to use Bucklescript effectively - ultimately something along the lines of Exploring ReasonML would be a bit more useful in lowering the barrier of entry.

Wrapping ones head around the JS FFI (which is also used for ReasonML) isn’t the most straightforward/intuitive thing either.

2 Likes
9

About Face (1995):

The above points were applied to user interfaces but to some degree can apply to programming languages.

Elm has a great feel from a beginner’s point of view. However there comes a point where you want to ditch the training wheels and you can’t. Meanwhile “the others” aren’t that easy to get started with but are preferred by those who are ready to push the envelope. This creates a situation where Elm is ideal for starting out - but for many there comes a point where they need to trade up for a new bike.

3 Likes
10

OCaml is taught in schools (as it is here as the ‘intro to FP’), there are many books, tons and tons of websites, the webpage beginner manual is easy to get started, the reference manual is actually nice to use unlike most languages, etc… etc… :slight_smile:

Eh, only in the nodejs’y aspects of it, but there are other resources for that anyway. BS is not any hard to use than the stock ocaml compiler (you can even use the same calls!), though it’s default build system is nicer (at least until OCaml’s new Dune build system completes), and it’s pretty trivial to use. :slight_smile:

Yeah sadly have to know a bit of javascript to bind with javascript, I hope webassembly fixes up that a lot better soon as it’s module system is so much nicer to use. :slight_smile:

Elm’s build system is not any easier than BS’s (though it is easier than OCaml’s, until Dune comes around at least), and Elm code is already ‘almost’ OCaml code, so it’s already comparable, not seeing any reason to start with Elm. :slight_smile:

1 Like
11

You seem to keep forgetting that not everybody has your affinity/exposure/interest/experience with programming languages and the detailed computer science concepts behind them.

This is bound to get worse before it gets better - there seems to be a growing trend of “skip college (i.e. waste of money) - do bootcamp (or self-study), start making money sooner” out there.

OCaml is taught in schools (as it is here as the ‘intro to FP’), there are many books

Text books are often designed for a structured learning environment where the instructor/teaching assistants are available as mentors and fellow learners are available for collaboration and the exchange of ideas. Text books that are suitable for self-study as needed for continuing education tend to be much rarer and are a cut above. Also text books tend to have much broader and meandering educational objectives compared to what is commonly referred to as a technical book.

1 Like
12

I do see a lot of new people learning programming in person however. Even with OCaml the, for example, objects are never taught ‘as’ objects but rather just as row-typing, and GADT’s aren’t even introduced until near the end, and it remains immutably functional the whole way through. :slight_smile:

I don’t really see that myself, but then I am heavily biased in that as I work at a college that has ever increasing student rates. :slight_smile:

Those other objectives are very useful for a student however, lacking them is a definite detriment. Even then for the pure programming courses the textbooks are not school books but rather are the usual O’Reilly and PragProg books, even the objective project is not always set at the beginning as that is fluid by class vote as long as it is a project that uses all the values being taught.

1 Like
13

OMG Elm for the win!

These threads drive me a bit crazy. I wish I could take the time to explain how amazing Elm is.

We have tens of thousands of lines of Elm (0.18) code in production.

It NEVER breaks. Like, never. Ever.

If are concerned about “extra code”, once you’ve compiled to JS, run it through the Google Closure compiler (which we use for production builds), or just use Elm 0.19.

On that note, Elm 0.18 is bombproof. It’s ironic that they call it 0.18. It should be version 18. It is SUPER solid. We have literally never had a single bug. Not one! Not in the core Elm core, not in any libraries, and not in our own code. Amazing!

Let that sink in for a minute.

I promise you, you will thank me if you go with Elm over the other things.

Best of luck, sorry I can’t write a longer response!

My advice is to start with Elm 0.18 if you need external libraries that haven’t been ported yet. If not, just bite the bullet and jump in with Elm 0.19.

Elm + Elixir + Postgres + Nanobox + Digital Ocean == in my opinion, best production stack today

PS a few months ago, we had a very talented senior dev spend a few weeks with ReasonML & Bucklescript-tea to see if we were “missing out”. I won’t put words in his mouth but basically, he concluded Elm was the way to go and has decided to use Elm exclusive going forward on his own projects (prior to working with us he’d been a big Vue.js fan).

pps If you are writing large-scale apps in Elm, read this:

Hope this helps!

1 Like
14

I also read several times about how awesome Elm is. When I tried to learn it though, it felt a bit hard to sink. What resources did you (or your colleagues) use to learn Elm?

15

While I think your enthusiasm for Elm is great, you should know that OCaml (& Haskell in which you could use miso in order to use the Elm Architecture) have more facilities to catch errors at compile-time than Elm does, so there’s really not much to your mentioning how little Elm crashes. It’s made from the same cloth as the languages mentioned and all I’m really seeing here is that you’re not quite up to date on which language group Elm comes from. (Hint: It’s ML, i.e. OCaml & friends). There are no meaningful updates to compile-time guarantees in Elm vs. Haskell, OCaml & co., so everything you said about Elm on that note is even more applicable to them.

It’s not my intention to rain on your parade or anything, but the thread is about comparing Elm vs. the other choices and so with that in mind it helps if you consider/know the citizens of this particular language branch.

4 Likes
16

Reason/OCaml code also doesn’t break as well. Because the type system works well.
Most people using Reason is using React.
Reason/OCaml is a more general purpose programming language. That can be used to solve problems beyound the client side interface.

1 Like
17

LOL. I am VERY up to date. OCaml, Haskell, etc are general purpose languages, and yes, they are great in their own special way, and really, compete with more Elixir (not Elm) in terms of use-cases.

Also, the idea of saying OCaml & Haskell can catch MORE errors is just plain crazy talk. Elm catches all of the errors at compile time. You can’t catch “more” than 100%. As I said, we have never had a single runtime failure due to do a programming error in Elm.

Elm (which is written in Haskell!) is a language specifically designed for writing reactive UIs that compiles to JS.

The assumption is that (seeing that we’re on an Elixir forum) that you’d be using Elixir on the back end, not Haskell or OCaml.

Really, Elm competes with Vue.js + vuex, React + Redux + etc + etc + etc, Angular, Ember, purescript, JQuery (!!!), etc. Not so much OCaml, Haskell, etc.

So when i say I’m excited about how Elm never crashes, it’s compared to the above JS frameworks, not Haskell and OCaml. That is a big, big deal.

Elm is really, really good if you want to write an amazing UI web front end, e.g. a single page app that never glitches or gets out of sync and is SUPER fast and responsive.

But that’s it, and that’s what it’s designed for. Elm is not a general purpose language.

Again, my response is not theoretical. We have tens of thousands of lines of Elm code in production right now.

If you have a single page app that has 25-50K+ lines of code in bucklescript-tea, ReasonML, purescript, etc. I’d love to hear how it’s going. (Haskell + miso wouldn’t make sense, as we’d no longer be using Elixir on the back end.)

In terms of learning it, it does just take a little time for it to all makes sense. Once you get the functional programming concepts, the main thing that takes a while to sink is the “event loop” nature of Elm.

They did update the guide at https://guide.elm-lang.org/ so for sure I’d start there.

Also, check out:

https://korban.net/posts/elm/2018-07-31-learning-elm-2018-comprehensive-list-resources/

Best of luck! Dive in–the water’s fine!

Again–just my opinion!

18

I gave it a tiny bit time in the past 3 or 4 days, used some videos from a free course, it was making sense but I wanted to be faster, so I bought Pragmatic Studio’s course, and it’s for $35 and with “elixirforum” coupon it became $28 (Korban.net mentioned it was for $65).

I’ll start using this course the day after tomorrow and will share my experience of Elm and this course on the forum once I complete it.

What I realized so far is that @gon782 gave me a good suggestion to stick to Elm. I didn’t like the indentation based nature of Elm and some of its formatting but slowly I’m getting used to it.

19

I’m not sure you are. You seem to fundamentally misunderstand OCaml’s and Haskell’s relationship to JS (that they can compile to JS) and how Elm relates to those languages in terms of power of abstraction. It’s not the end of the world because clearly you’re already invested in an eco-system at this point, but let’s not mistake that for a clear overview of the landscape.

They can, yes, and by way of transpilers they can be used to write JavaScript. BuckleScript very much competes with Elm and GHCJS does as well.

While “more” type guarantees was maybe bad wording, the type of guarantees and how you get those guarantees in OCaml (via functors) is something you simply can’t get in Elm. The alternative in Haskell is type classes and Elm doesn’t have those either. It simply has nothing that could stand in as an analog for the kinds of facilities that in both a type safe and concise way can give you guarantees of correct usage.

Functors work just fine with BuckleScript (compiling OCaml to JS) and type classes work just fine with GHCJS. So with that in mind, in this regard what Elm is competing with isn’t only a bunch of JS frameworks + PureScript; it’s also OCaml & Haskell.

I’m well aware of what Elm is, as I started out with it when I was looking for a functional way to write JS, essentially.

You don’t need to use Haskell or OCaml on the backend in order to use their facilities for transpiling to JS. We use an Elixir backend to interact with our BuckleScript apps and it works just fine. No one’s talking about only using only OCaml/Haskell, but rather their to-JS-compilers (BuckleScript, JS of OCaml, GHCJS, etc.).

I’m not going to harp on about this because I already recommended @DevotionGeo to take a look at Elm again because while I personally think the types of abstractions you get in Elm are just a bit too thin I think it’s a very reasonable choice and I like it in general. It’s just that nothing that you really said about Elm is something that doesn’t apply also to OCaml/Haskell. In the end the thread is about comparisons between Reason/OCaml and Elm, so it really only makes sense to differentiate them clearly, not evangelize for one by stating things the other also has.

4 Likes
20

Even if you change your mind later, I don’t think you’ll feel that you have wasted your time. Elm forces you to work under certain constraints that if you come from a dynamic language background may feel initially like a PITA - but if you work with it long enough you should start to realize that those constraints are for your own good - most of the time.

The trick is to expose yourself to the benefits long enough so that you are willing to impose similar constraints onto yourself whenever you need to drop down to the “core technology level” - despite any short term inconvenience that may cause - simply to steer you away from the usual footguns.

At the same time you’ll already have been sufficiently exposed to something different enough from the “usual” fare to make it easier to adopt something that may not have an ideal “beginner story” but is more flexible in some respect (which usually implies additional complexity on some level).

2 Likes