Live data from Hacker News

ReasonML: Strict, powerful and forgiving

harigopal.in

31–40 of 60 posts

Re: ReasonML: Strict, powerful and forgiving

#31
post #16

So ReasonML is actually a Javascript-like syntax for OCaml, and its tool-chain converts Reason code to OCaml, which then uses a tool called Bucklescript to convert that OCaml to Javascript. All because some people just have to have their curly braces. I will never stop being angry that this exists. There is no reason for it other than pedantic bikeshedding and Facebook’s mission to proprietize web tech. It does nothi…

I know this is getting downvoted a ton, but I certainly felt the same way before using Reason. Even now, I'm sort of undecided about my opinion on it. I love how accessible it makes OCaml (which I think it does, people pay more attention to syntax than they really ought to) but I'm always afraid that it's going to cause native OCaml to be abandoned. Reason can also sometimes make code needlessly complex IMO because it hides some of the really clear aspects of OCaml's syntax. That said, it's improved a ton since it was first released and no longer feels like a weird soup of mixed up languages.

Re: ReasonML: Strict, powerful and forgiving

#32

Doesn't typescript also have variants and similar variant checking? Maybe not understanding what the big deal here is... https://www.typescriptlang.org/docs/handbook/advanced-types....

For me, Reason's type system seems a lot more focused on what it's trying to do. It's much more minimal than TypeScript's, so you don't end up trying to hack it to fit weird JS types. This also means you get full type inference which is huge.

The other nice things are the fact that it's not backwards compatible with JS so a lot of the syntax is a little more convenient and the module system + object system are the same really powerful ones that OCaml has. Plus, the entire paradigm of the language is so different that it totally changes the way you use React (I remember having all kinds of issues my first time trying to use React just because of how weird some functional stuff is to do in JS, whereas in Reason virtually any program that typechecks is 100% valid for React).

Re: ReasonML: Strict, powerful and forgiving

#33
post #13

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…

You can embed raw js in reason/BS easily with [%raw ] iirc. Check the bucklescript documentaton, where the interop docs are located.

But then I don't get the benefit of ReasonML/BS. I can do that, but then I keep having to do that everywhere I interact with that library (which is essentially the core part of my app).

I do the same thing in Elm, but all that code is living in a JS file, and it can be in Typescript/whatever.

Re: ReasonML: Strict, powerful and forgiving

#34
post #20

Earlier quoted context omitted.

Reason compiles to Ocaml, yes. Does Facebook actually want you to just use Ocaml? Sure doesn't seem that way to me. Facebook is pushing their own tool, and their own libraries to go with it. Interoperability between Reason, Bucklescript, Ocaml native, OPAM libs, and the various build tools in between is confusing and ill-defined. The path of least resistance just seems to be "stay in our garden... there's no walls te…

>>> Does Facebook actually want you to just use Ocaml? Facebook already uses OCaml. https://github.com/facebook/infer

They use it for a few different projects:

https://github.com/facebook?language=ocaml

Re: ReasonML: Strict, powerful and forgiving

#36
post #26
post #14

Earlier quoted context omitted.

The whole class component story in Reason felt kinda clunky, but with hooks this will probably not be a problem anymore. Compared to the Rust compiler's performance, BuckleScript is a moloch, but as long as you don't try to run it on a t2.micro it works okay.

> The whole class component story in Reason felt kinda clunky See bucklescript-tea for goodbye clunky :) https://github.com/OvermindDL1/bucklescript-tea

How has Bucklescript-TEA been in your experience? When would you recommend it and how about JS interop?

For those who don't know, TEA stands for The Elm Architecture, so it's like Elm for Bucklescript or Reason. The library's author is also very active in the Elixir community.

Re: ReasonML: Strict, powerful and forgiving

#37
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?

I'm not familiar with Reason, but OCaml does have virtual methods and dynamic dispatch, and therefore ad-hoc polymorphism.

http://dev.realworldocaml.org/classes.html#virtual-classes-a...

Now, you can't downcast or cross-cast or do a runtime typecheck easily, but that doesn't mean it's impossible - you just have to use roundabout ways like variants to do so (which also means that you can control which class hierarchies it is available for, and which ones it's not). A class hierarchy combined with an polymorphic variant type to allow runtime type queries can be made as powerful as a runtime typecheck/cast in Java - if more verbose - for those rare cases where you actually need it.

http://dev.realworldocaml.org/variants.html#polymorphic-vari...

Of course, in practice, most cases where you'd use a downcast or a typecheck in a language like Java, map more naturally to regular variants and matching on them in OCaml.

Re: ReasonML: Strict, powerful and forgiving

#38
post #16

So ReasonML is actually a Javascript-like syntax for OCaml, and its tool-chain converts Reason code to OCaml, which then uses a tool called Bucklescript to convert that OCaml to Javascript. All because some people just have to have their curly braces. I will never stop being angry that this exists. There is no reason for it other than pedantic bikeshedding and Facebook’s mission to proprietize web tech. It does nothi…

It's not just about the curly braces - there are many warts about OCaml's syntax, and some of them go beyond mere niceties, and into the territory of making it too easy to unintentionally write code that doesn't do what the author intended. In Reason, it looks like they specifically went after those, e.g.:

https://reasonml.github.io/docs/en/comparison-to-ocaml#patte...

Re: ReasonML: Strict, powerful and forgiving

#40
post #20
post #18

Earlier quoted context omitted.

reason is fully compatible with ocaml. nothing has been bifurcated. it is not even the first alternative syntax - the "revised syntax" had been around forever. https://caml.inria.fr/pub/docs/manual-camlp4/manual007.html

Reason compiles to Ocaml, yes. Does Facebook actually want you to just use Ocaml? Sure doesn't seem that way to me. Facebook is pushing their own tool, and their own libraries to go with it. Interoperability between Reason, Bucklescript, Ocaml native, OPAM libs, and the various build tools in between is confusing and ill-defined. The path of least resistance just seems to be "stay in our garden... there's no walls te…

> Reason compiles to Ocaml ..

My understanding is that it can be translated both ways with no difference of semantics.

Post reply on HN