Live data from Hacker News

ReasonML: Strict, powerful and forgiving

harigopal.in

1–10 of 60 posts

Re: ReasonML: Strict, powerful and forgiving

#2
I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescript constantly releases patch version that breaks stuff, or removing deprecated functions in a minor version. I believe for a crucial piece of the ecosystem like Bucklescript, it needs to have a beta channel so we can test them before official release - Also, there should be more communications between core team and developers, I'm scared for the longevity of the ecosystem. There are no details roadmap of what's coming next or priority of the open issues. There are many important issues (to me) that could increase ReasonML like a lot but never get addressed. An example of such issue would be shipping compiled stdlib in a separate package or have a way that would allow users to integrate ReasonML to their current node.js toolchain without waiting for building the compiler on every build (which could takes more than 3 minutes on slow CI machines)

That been said, I love ReasonML and will continue to invest in its ecosystem. Shamelessly plug, I built https://sketch.sh as a quick playground for ReasonML and OCaml, check it out if you're interested in trying ReasonML

Re: ReasonML: Strict, powerful and forgiving

#3

I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescrip…

Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?

Re: ReasonML: Strict, powerful and forgiving

#5
post #3

I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescrip…

Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?

Actually I like the lacks of it. I know exactly what an operator does without digging deep into the source code. Everything is explicit

Re: ReasonML: Strict, powerful and forgiving

#6
I tried using ReasonML for a blockchain project, and I just couldn't get past being able to express this logic of interacting with a third party library:

``` const contract = new web3.eth.Contract(ABI, contractAddress, {from}) ```

in ReasonML easily, despite spending hours on trying to figure it out. At the end I finally reached to a feature request asking to be able to do 'new' on member functions, and it was in 'planning'.

On the other hand Elm's approach to JS interop seemed to be far superior for quirks like these. Javascript code lives on the other side of the border, and Elm code on this. You don't have to create a type for the whole class of the third party library, just the data you want Elm to manage.

Re: ReasonML: Strict, powerful and forgiving

#8

I tried using ReasonML for a blockchain project, and I just couldn't get past being able to express this logic of interacting with a third party library: ``` const contract = new web3.eth.Contract(ABI, contractAddress, {from}) ``` in ReasonML easily, despite spending hours on trying to figure it out. At the end I finally reached to a feature request asking to be able to do 'new' on member functions, and it was in 'pl…

Elm has its own infelicities with JS interop. Everything has to be done through ports, which means you have to contort your control flow to work with JS (which is extremely cumbersome if your JS is just pure functions).

For those not familiar with Elm it means you basically have to interact with all JS code through a pub-sub model and can't ever directly call JS code.

Elm's creator has his reasons for why he does this (https://guide.elm-lang.org/interop/ports.html), but it can make calling JS from Elm quite a pain.

Re: ReasonML: Strict, powerful and forgiving

#9
Built a small demo project in ReasonML. It was an enjoyable experience.

The generated JS is readable and well-commented when for instance a record is transformed into an array. Just opening up the generated JS and reading it made for a nice self-check mechanism when I was starting out with the proof of concept.

Post reply on HN