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

General Prog (Archived)
, ,
21

For note, I ran Elm at work from 0.16 to 0.17, I’ve experienced a LOT of bugs in Elm (and I’m not talking about the changeover, which understandably has changed), from typing related bugs to the javascript output crashing because of it misnaming things to all manner of things (I have a large list of github issues here of the issues that others reported). Many of those issues still exist even up to 0.19. It is not a stable language.

I’m curious how that has happened, because I never had a week where a bug in the elm compiler alone didn’t happen, as well as immeasurable bugs among a variety of libraries (admittedly most were logic bugs, but still bugs).

/me is thinking that post sounds a whole lot like a sales pitch, I could never ever say that a language is bugless, no matter what language…

Especially this, Elm was based on OCaml and Haskell do remember, except Elm is not inhereting the rock solid compilers of those, though it easily could. I don’t know why Elm has it’s own compiler as it easily could have been a syntax plugin to the OCaml compiler (like ReasonML is to on OCaml, among others), then it would get far far more safety, a couple of decades of stability testing everywhere, much better and tighter and more efficient code generation, much faster compiling, etc…

Well, other than the number type comparison bugs, the auto-conversion to strings and NaN’s in some cases for integer types, etc… etc… etc… of course yes?

Aaaand this is a troll… I think I’m out… ^.^;

Well, one more thing as this is pretty useful, sec…

╰─➤ find . -iname '*.ml' -exec cat {} \; | wc -l
15013

And remember that OCaml can end up being a lot shorter than Elm for big projects due to it’s PPX functions and higher typed modules. Since changing from Elm I’ve had no compiler bugs, no language bugs, and as I try to encode my logic into the type system as much as possible (an area where Elm lacks in) I’ve had very few logic bugs. That also doesn’t take in to account the other libraries I’ve written and pull in either for it to use, this is purely just for the local project at work (it used to be bigger until I pulled out some reuseable parts).

Well Elm does have some built-in type classes like number and comparable, however those have bugs (still to 0.19) and you cannot user-define new type classes or instances there-of.

Yep same, I’m only using OCaml for the front-end code at work, it’s not used in the backend at all (though I do use it on the backend ‘with’ elixir via ports for some personal projects).

Yeah definitely this! Going to Elm from javascript is still going to static typing from dynamic typing and that experience alone will make one a better programmer over all. :slight_smile:

4 Likes
22

Yeah, I’m aware of the built-in type classes. Let’s be honest; it’s hard to say Elm really “has typeclasses” when they’re not available to the programmer in any meaningful way.

1 Like
23

There’s nothing wrong with selling the idea of a language :stuck_out_tongue: it shows you’re passionate about it - and I find that when people are that passionate about something (like a programming language or framework) it’s usually worth investigating to see why that might be.

Of course it’s also ok to point out anything you think is incorrect - but I don’t think we need to remark on the style of post (otherwise people could easily flip that and say some anti-Elm posts are akin to negative fanboyism/bashing)

@madasebrof, your post certainly made me want to look at Elm again :slight_smile:

3 Likes
24

I wish someone had “sold me” on Elm sooner! LOL–I am not getting any compensation to says this! It’s all open source! Use F# for all I care! Or JQuery! Or write vanilla JS! Or do what @OvermindDL1 did and roll your own version of Elm! Or skip JS and just use Phoenix templates! It’s all good!

We just use Elm very successfully in a real production environment, and I know that I would have saved many, many hours had I started with Elm. Also, I really can’t imagine what it would be like if we didn’t have Elm.

Again, in my experience, Elm and Elixir are a fantastic combination.

When I can, I try to post the benefits of Elixir on the Elm boards (who all seem to use rails–so crazy!), and I try to post the benefits of Elm on the Elixir boards.

What I have observed is that people who seem to love Elm are folks who have experience with writing large-scale UIs in JS framework like Vue, React, Ember, Angular, etc. and think Elm is a godsend (me!).

People who don’t seem to love Elm are folks that love Lisp/ML languages like Clojure, Haskell, OCaml, or PureScript and think Elm is a feature-incomplete version of those languages (not me!).

Much love,

ps To say that Elm is buggy is like saying Phoenix is too slow. @OvermindDL1 has said that before on this forum, and I find it baffling. I have literally never had a bug with 0.18, and I’ve never heard of anyone having a bug. (I didn’t use Elm prior to 0.18) People do moan and complain in the Elm forums about this and that, but not about actual language bugs! I guess it must be possible to produce a bug, it’s just that I code in Elm daily, and it never happens. If it compiles, you can ship it. Elm has limitations, yes. But bugs, as in things that generate mysterious runtime errors? Not one time, in my experience of writing & shipping Elm code over the last 18 months.

1 Like
25

Weren’t you guys having trouble with, phoenix channels, file uploads and forms with Elm 0.19? What did you end up doing for these problems?

Personally I’ve done one client project with Elm + Elixir and now im working on a new one with Reason (React) + Elixir. I can say I will continue to use Reason instead of Elm. I’ve had enough of the holier than though attitude of the Elm community. It’s super cultish, no one is allowed to question Evan, discussions are always locked and shutdown and everything seems to happen behind closed doors. I prefer the friendly and more open elixir and reason / react communities.

Also I found reason provides me with much of the advantages of elm (type safe, good compiler, easy refactoring) while still being able to leverage the react/react-native ecosystems. So far my experience with reason has also been if it compiles it works, just like in elm. However, I’m much more productive in it.

With all the being said I am really glad I tried elm. I learned a lot, it made me think different™. And I am applying a lot of the lessons learned from elm to my reason code.

P.S -
find src -name '*.re' | xargs wc -l => 2998
find src -name '*.elm' | xargs wc -l => 13,313

P.P.S - LOC is a very silly metric, especially when it comes to elm since you have to write so damn much.

8 Likes
26

Awesome! Glad you are super-psyched with Reason! I’m sure I’ll look at again at some point–nice to hear it’s bug-free and working well for you!

I get what you are talking about with Elm, but on the other hand, at a certain point, I’m sure Evan gets tired of people complaining about things he a) knows about and b) has designed on purpose to behave that way. E.g. He could have just used Haskell/OCaml/Etc. in its entirety directly but chose instead to write a compiler in Haskell that compiles a language (Elm) to another language (JS).

To each his or her own!

I’ll check out Reason again at some point. So amazing that there are so many choices like this out there these days!

We are still with 0.18, will tackle that probably next year. As much as it would be cool to upgrade to 0.19, 0.18 is so stable and works so well that, for us, there isn’t a big, compelling need at this point! We use the google closure compiler which does a pretty good job at dead code elimination anyway.

RE loc metric, yes true but at least gets you in the ballpark! E.g. 1,000 vs 10,000 vs 50,000 etc.

1 Like
27

Are you using a global state manager with Reason/React? Reductive seems like its a toy and it actively discourages you from using global state in its own readme, plus it renders the full tree on every change…avoiding this is half the point of a state manager.

For me personally I’m not going to use any solution that doesn’t have first-class support for both component state and global state. This rules out many of the options discussed here.

2 Likes
28

I’m doing something very similar to this: https://gist.github.com/jsiebern/ac9a3ce507ad047f7c1d594446cd7b4e

So far its working out very well.

Other options: https://github.com/Hehk/reason-react-context

Further discussion: https://reasonml.chat/t/whats-the-best-way-to-handle-global-state-in-reasonreact/208/15

29

I’m sorry but this is very misleading. Elm does still have a lot of bugs. And the web API is very incomplete. You yourself are using an “unsanctioned” package because of the bugs and the incompleteness of websocket support in elm. (A package you can no longer use in elm 0.19).

I’m glad you like elm but its misleading to oversell the “stability” of elm. Elm is a great language. But in my opinion it is not “production ready”. It hasn’t hit 1.0 for a reason. I think we have to be careful about overselling it.

Also, you seem to be confusing “bugs in elm” and “bugs in MY elm code”. Not to mention its still very possible to make logic bugs in elm.

1 Like
30

I’ve not had any interaction with Elm via any of their community platforms, and so my comment is mostly general. I do know that Evan is quite young, and so may just not have the experience of being at the helm of a community? It’s also possible that others may lack such experience or be a little over-protective because of that too? If you look at Elixir, Rust, Crystal etc, they are created by experienced developers (and if you look at this forum in particular, I have 15 years experience in managing them) so it’s probably fair to say we have an advantage in this particular area.

I would hope that anyone who likes Elm would perhaps cut them/Evan a little slack, and if they believe the project or discussion platforms are being managed in a way that is hurting the community, to perhaps have a private word with the senior members of the community in an effort to rectify and minimise such issues moving forward.

You generally have to strike a balance - allow people to voice their opinion vs allow them to burden the community by (what might seem as) constant (or unfair or insincere) criticism. The way we measure it here is quite simple - does the thread/post add something of value (and perhaps not do the opposite) to the topic/forum/community/Elixir. The goal, imo, should always be progress :slight_smile:

3 Likes
31

All I can do is recount my own experience in Elm! To me, it is nothing short of a miracle compared to other languages I have worked in (e.g. C, JS, Python, etc.) to have bug-free, stable code that I can refactor to my heart’s content knowing that if it compiles, it won’t break. I have not worked in other ML language before Elm, so I can’t compare it to Haskell, ReasonML, etc. Maybe they are even better! :slight_smile:

In my mind, I am underselling Elm, it’s that good.

Saying Elm is not production ready is just plain odd. It is for sure production ready. We have it in production. It works beautifully. It never breaks. Our interface is super responsive and never gets out of sync. We have been able to work-around every limitation of the language–file uploads, phoenix websocket, etc. We have been able to replace D3 with the elm-visualization package. Yay! What more could you ask for?

Yes, it isn’t feature complete. That is true. But again, when I’m talking about “bugs”, I mean runtime errors like the dreaded Uncaught TypeError: Cannot read property of undefined. That’s a bug you will get when using React or Vue, and they are a nightmare to track down, to the point that folks sell software to help with this!

Also, I have never had a “logic bug”, where I thought the code was going to do one thing, but it did something fundamentally different. The compiler has really good guard rails.

Again, just my experience.

Anyway, moving on! I hope some find my words helpful!

:peace_symbol:

32

FYI:

Elm in Action MEAP

A note from the author:

I have some revised chapters for you! As you may have heard, Elm 0.19 was recently released (https://elm-lang.org/blog/small-assets-without-the-headache). I’ve been going through and updating Elm in Action to use it.

I just released the updated Chapters 1-3, which also include some minor fixes and changes based on your comments in the Author Forum. (Thank you for all the feedback there!)

I’m in the process of updating Chapters 4 and 5, which are getting a bit more in the way of changes than just 0.19 updates! In the meantime, the updated code samples for Chapters 1-3 can be found on the 0.19 branch of the GitHub repo (https://github.com/rtfeldman/elm-in-action/tree/0.19).

Enjoy!
Richard Feldman

What’s next?
Revisions to Chapters 4 and 5.

33

It’s interesting how this seems to happen to many languages (and how most of them have leaders that ended up being referred to only by their first name in the community, as if people knew them). Most people seem to think the issue is the creator of the language himself and that it’s a failure as a leader. This kind of behavior is usually not somehow sanctioned by the leaders of the community, but rather tolerated by the silent majority and unnoticed by key players.

I think it’s much more about the people who choose, as a group, to take these positions. If you come from a community that idolizes their key figures and pats themselves on the back for their impeccable taste all the time via vague-isms usually centered on form instead of function you’re likely to just bring that behavior to your new community.

The result, of course, is a community that devolves into only having a bunch of yes-men in it and a language that doesn’t evolve at all or evolves in bad directions because of said yes-men.

2 Likes
34

I use Elm for non-production (or little production) project since 0.17.
And yes, it makes me a better developper, and event if it was such a pain to learn coming from php-js world (don’t laugh), it opens me the gate of functional languages and I like them so much by now.
But to be fair, I’ll soon have to tackle a big project and for it, I don’t see Elm as a good choice, because:

  • types: Elm type system is great but you don’t have the possibility to derive types from others and sometimes, that’s just a massive load of code (almost duplicates). I felt very annoyed when it happens: hundreds of lines of code to do almost the same just because one little thing differs…
  • ports: I hate ports/decoders. I understand why they are here but what a lot of code for just making the app understand what’s given to it! And yes, Elm has few compile time errors but this is the realm of runtime errors… (because i’m a bad dev?)
  • ecosystem: I’m a lazy dev. I don’t want to recode the earth if it’s already coded, and there’s a lot of useful JS libs that have no counterparts in Elm. But oh yes, you have ports…
  • slow evolution: Not to much changes between 0.17 and 0.18. And almost no changes for the language itself in 0.19. That’s not very appealing, especially when there is known issues / requests / etc. So Evan knows where he’s heading but the slow pace is frustrating…

That’s why for the next project, I will give a try to bucklescript-tea or fable. I need a strong language, good JS interop and the TEA, because TEA is marvelous.

3 Likes
35

I don’t know about his age, but even Evan is not the big issue, but rather some of his coworkers as they are incredibly aggressive, not aggressive ‘for’ elm or anything like that, but just aggressive in general, I hate to use the word ‘hateful’ but that is really how it comes across as. The one time I pointed it out and that it would help the community to keep a softer tone I had a half-dozen people join the thread in support of my point (in addition I got over 20 different people emailing me thanking me for pointing it out but that they were too scared to say anything) because those couple of people came in, again, very aggressively, locked, and deleted it (though I might still have the emails from the mailing list of it). It felt very reminiscent of how the Haskell community used to be (though they have gotten a lot better lately in general!), which makes sense since that is where they are from.

Logic bugs are just conceptually doing something wrong right down to accidentally using > instead of >= or so, those are not things that any language can really help you with (well, except languages with dependent typing, like Idris, which consequently also has a javascript backend, so slow to compile but that is a language worth learning for the way it helps make you think).

Exactly this. As stated above the issue is not even Evan, it’s his coworkers and other such ‘higher ups’.

This is what I fully see happening with Elm, it’s one of the reasons I did not stay with it (that and the community). That’s a great description of what I see happen with a lot of libraries (and a few languages). The best languages and libraries seem to be the ones that instead of shutting down criticism of designs they instead work through the ideas of why the current method was chosen and changing it if it is indeed shown to be insufficient. Elm does not remotely follow that, again because of those few higher ups.

Elm doesn’t have higher typing of any form, but you ‘can’ actually do a lot of that kind of thing in Elm by using the witness pattern (a bit more wordy compared to doing witnesses in OCaml, but still fully capable).

Honestly I wish Elm went the direction of sending/receiving DOM events instead of using Ports. It is ‘standard’ (literally part of the standard), easily emulateable on servers, fully event driven like ports, and it could even look like normal Cmds/Subs. This is what I’m planning to do on my bucklescript-tea enhancement modules.

As long as the JS libs don’t touch DOM then you are fine, else you have a lot of synchronization issues to deal with. My CustomNode handler type (still in development, I need to finish it) in bucklescript-tea will solve that issue in a very Standards-style way. :slight_smile:

It would help if Elm were fully open developed, but it’s not, it’s developed closed at his place of work with occasional syncs to github, this is a big issue with it’s development I do think.

Honestly I think the observer model is better than the TEA model, but it’s only a slight change from TEA anyway (will be supported by my tea extension modules once I get around to finishing them, feel free to ping me for any needed features or help).

2 Likes
36

as in Observable or (the withdrawn) Object.observe() (… the former gets my vote).

37

Not either, but rather just the observer conceptual model. It would really only change the view function of bucklescript-tea (which I already designed to be pluggable and replaceable as I was thinking to do this at this time) from being declarative as it is now to each part stating what part of the model they will access and transformers would transform it in to the new view type. What this would mean is that instead of an even causing a full call of the ‘view’ (which is pretty fast in most cases but is pretty bad in some) then it could instead just focus on updating the parts it already knows. The nice bit of the design update is that existing code would still work and my VDom already supports it via its Lazy node type (which if anyone has noticed, is much more generic than just for simple lazy stuff) so then you could mix and match. A full api redesign could mix that all together to only inform of the lazy node updates for the parts of the model they access and such updating would be faster.

The reason I’ve not made it yet is that the normal view style is ‘fast enough’ that I’ve never needed the need as of yet, nor has anyone ever complained about the speed of my whole VDom framework (which even outperformed Elm’s in my last benchmarks, and outperformed basically every other one I tested it against except an observer-based vdom).

38

I don’t know if this will help in your specific scenario, but Elm does support “extensible records”. Just do a search on that page for the word “extensible”. It may help you. Though, I was just told on the elm slack that it may not always be supported. So maybe don’t use it and do something more like

type alias Position = {x : Int, y : Int}

type alias Person = { name : String, position : Position }

I think I will be staying away from Elm for the time being. I wrote something super simple in it for production at work and it was just not a good experience, at least for how I used it. I’m only going to name a few things here.

One of my biggest issues with using Elm was dealing with Pheonix Channels. The symptom is that only “core” Elm folk are allowed to upload Effect Manager modules to the package manager. This leads to one of three solutions

  1. Use the unofficial package manager to be able to pull dependencies from GitHub
  2. Write own module to deal with channels
  3. use git submodules (or something similar) to bring one into your project

None of these are real solutions to me.

Another issue (which is technically workable, but really annoying to me) is how to deal with JSON. There really should be some way of deriving a JSON encoder and decoder for a given type. It would cut down on a lot of code, and if you needed to manually write an encoder and decoder for whatever reason, you still could.

This last one may seem silly but, it is a non-trivial task to get a Date from some JSON. You have to write a custom decoder for it. Apparently a type being part of the standard library does not mean it is well supported through official packages.

keep in mind this was all for 0.18.

My current plan is to write the next part of the application in bucklescript and see how that goes. Though, I do remember trying it at one point and having a runtime issue, but I don’t fully remember the details. I guess we will see what happens.

2 Likes
39

OCaml has a PPX library for that to automatically generate a json decoder/encoder (very configureable and safely, I’m thinking of integrating it into bucklescript-tea). ^.^

Submit an example on the issue tracker! If you want to use React instead of TEA then ReasonReact is a great library (that you can use from ocaml or reasonml, whichever you prefer, since they are interchangeable after all).

1 Like
40

Yup. I had all of those issues as well.

Sounds like you’ve moved on from Elm, but just an FYI, here how I solved each one:

  1. date parsing JSON in Elm - just import Json.Decode.Extra, e.g.
import Json.Decode as Decode exposing (Decoder, float, string)
import Json.Decode.Extra exposing (date)

type alias DateFloatStringThing
    { date : Date
    , value : Float
    , name : String
    }

decodeDateFloatStringThing : Decoder DateFloatStringThing
decodeDateFloatStringThing =
    Decode.map3 DateFloatStringThing
        (field "date" date)
        (field "value" Decode.float)
        (field "name" Decode.string)

  1. Use https://github.com/saschatimme/elm-phoenix It works flawlessly. Who cares that it’s not “officially supported”? Not me! We are using it in production.

  2. JSON - if you are using Atom (which I do), just install the Elmjutsu package. If you have made the type alias already, it will automagically build an Encoder or Decoder for you as you (e.g. it will derive the JSON encoder from the type–exactly what you are looking to do!)! Or just paste here to auto-create one: http://eeue56.github.io/json-to-elm/

Namaste.

1 Like