Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ReasonML: Strict, powerful and forgiving

harigopal.in

Post reply on HN
Print view View original

51–60 of 60 posts

Re: ReasonML: Strict, powerful and forgiving

#51

Post by cies »

malloryerik wrote: post #36
cies wrote: post #26

Earlier quoted context omitted.

> 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.

I've only used Elm. I just know of this project, and think it makes sense to cut out the whole React x-mas tree.

Re: ReasonML: Strict, powerful and forgiving

#52

Post by chickenfries »

ohadrau wrote: post #29

Like a ton of other people here, we've been using ReasonML for about half a year now at Rolltrax [1] and so far I can say I'm ~95% happy with it. I'm a long-time OCaml user but my co-founder had 0 experience in OCaml when we decided to make the switch to Reason. I'll just list off some things we've found using Reason so far: Positives: * Really quick to get productive -- the syntax really does do a great job getting…

All of those pain points sound terrible. I want to like Reason and Elm so much but it seems like the amount of time you have to spend getting these things to work with other libraries is absurd. Writing JS is not so hard that I would be more productive in a safer language (beside maybe the very pragmatic typescript) if you account for all of the extra time spent trying to interop with other JS libraries or browser APIs.

Elm seemed like it was taking a pragmatic approach with ports but then they got rid of all of the JS interop code in their package manager, forcing everyone to write their own glue code.

Re: ReasonML: Strict, powerful and forgiving

#53

Post by Paradigma11 »

int_19h wrote: post #38
jarcane wrote: 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...

"... write code that doesn't do what the author intended."

But this code does not compile. Even if you do not use https://github.com/ocaml/merlin you will always realize it at compile time. What type is y supposed to be to pass compilation?

Re: ReasonML: Strict, powerful and forgiving

#54

Post by yawaramin »

splintercell wrote: post #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 'pl…

Can you point to the feature request where you asked for 'new' on member functions, please? I would like to correct whatever response said it was in 'planning', because it has been doable for a long time now. Here's some sample Reason that outputs pretty much exactly your above code:

    module Web3 = {
      module Eth = {
        module Contract = {
          type t;

          [@bs.module "web3"] [@bs.scope "eth"] [@bs.new]
          external make: (string, string, {. "from": string}) => t = "Contract";
        };
      };
    };

    let contract = Web3.Eth.Contract.make("ABI", "contactAddress", {"from": "from"});
You can try it out in the interactive playground.

Also, regarding 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.

That's exactly how Reason JavaScript bindings work too.

Re: ReasonML: Strict, powerful and forgiving

#55

Post by yawaramin »

k__ wrote: post #14
nouveaux wrote: post #12

We chose ReasonML after a previous project of working with JS, React and Flow. We started using Reason back in May. The plan was to use typescript but after some great experiences with Rust on personal projects, I really wanted a language closer to Rust. Our team loves using Reason and for me, it's been such a breath of fresh air. Working on front end code is a lot more fun because many of the frustrating things with…

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.

I don't understand your second paragraph, are you saying that BuckleScript compiler is slow compared to Rust?

Re: ReasonML: Strict, powerful and forgiving

#56

Post by int_19h »

jarcane wrote: post #48
int_19h wrote: post #46

Earlier quoted context omitted.

> Yes, such a massive improvement to clarity. Given that === is not a standard operator in OCaml, I fail to see the problem with clarity. > Certainly nothing that justifies forking an entire alternate syntax. You do realize that this is very much a subjective judgment, do you? Syntax does matter. You can argue that it doesn't matter enough to bother, but that's down to personal taste. Given the popularity that Reason…

Nobody is forcing you to use them, and you can still use a library written in Reason from OCaml, and vice versa. You really should go read up about this, because the actual answer is far more complicated than advertised. Hell, the Ocaml interop section in the official docs isn't even finished yet.

Most of the complexity seems to be stemming from the JS backend, so far as I can see, which is not really Reason's fault. What are the OCaml interop issues when using Reason with the native backend?

Re: ReasonML: Strict, powerful and forgiving

#57

Post by splintercell »

yawaramin wrote: post #54
splintercell wrote: post #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 'pl…

Can you point to the feature request where you asked for 'new' on member functions, please? I would like to correct whatever response said it was in 'planning', because it has been doable for a long time now. Here's some sample Reason that outputs pretty much exactly your above code: module Web3 = { module Eth = { module Contract = { type t; [@bs.module "web3"] [@bs.scope "eth"] [@bs.new] external make: (string, stri…

Just to be clear (and I now remember more details), I wanted to do bs.new with bs.send, but it wouldn't work.

I am going to try what you suggested, but keep in mind I did go to the slack channel and tried asking this, none of their solutions looked like yours. Either way, intuitively @bs.new and @bs.send should be able to work together.

https://github.com/BuckleScript/bucklescript/issues/2659

Re: ReasonML: Strict, powerful and forgiving

#58

Post by yawaramin »

splintercell wrote: post #57
yawaramin wrote: post #54

Earlier quoted context omitted.

Can you point to the feature request where you asked for 'new' on member functions, please? I would like to correct whatever response said it was in 'planning', because it has been doable for a long time now. Here's some sample Reason that outputs pretty much exactly your above code: module Web3 = { module Eth = { module Contract = { type t; [@bs.module "web3"] [@bs.scope "eth"] [@bs.new] external make: (string, stri…

Just to be clear (and I now remember more details), I wanted to do bs.new with bs.send, but it wouldn't work. I am going to try what you suggested, but keep in mind I did go to the slack channel and tried asking this, none of their solutions looked like yours. Either way, intuitively @bs.new and @bs.send should be able to work together. https://github.com/BuckleScript/bucklescript/issues/2659

I see your problem (which is btw quite different from your original comment ;-) ). In a statically-typed language like Reason it's difficult to model dynamically-generated types like `hello_proto.Greeter`. One way is to use a functor ( https://v1.realworldocaml.org/v1/en/html/functors.html ) but they have their limitations. This is why we have things like graphql_ppx which is a compiler extension to generate types from GraphQL schemas at compile-time. You'd need something like this (or, easier, a ReasonML-targeting gRPC/Protobuf client generator) to solve the issue brought up in GitHub.

Re: ReasonML: Strict, powerful and forgiving

#59

Post by ohadrau »

chickenfries wrote: post #52
ohadrau wrote: post #29

Like a ton of other people here, we've been using ReasonML for about half a year now at Rolltrax [1] and so far I can say I'm ~95% happy with it. I'm a long-time OCaml user but my co-founder had 0 experience in OCaml when we decided to make the switch to Reason. I'll just list off some things we've found using Reason so far: Positives: * Really quick to get productive -- the syntax really does do a great job getting…

All of those pain points sound terrible. I want to like Reason and Elm so much but it seems like the amount of time you have to spend getting these things to work with other libraries is absurd. Writing JS is not so hard that I would be more productive in a safer language (beside maybe the very pragmatic typescript) if you account for all of the extra time spent trying to interop with other JS libraries or browser AP…

To be fair, issues with bindings have really not been too common and when they appear the fix is just opting out of the strong type checking. 9 times out of 10 when we have a bug the issue is actually something not specific to Reason, like Webpack making 2 copies of React in the output,

Re: ReasonML: Strict, powerful and forgiving

#60

Post by chrisweekly »

h1d wrote: post #43
skosch wrote: post #22

Earlier quoted context omitted.

I've worked with both. Typescript is (and feels) bolted-on, and can fail in dozens of ways. ReasonML's type checker is 100% airtight. It also has pattern matching and piping, to help make your code more concise. Typescript is easy: it's just ES6. ReasonML is (and feels) very much unpolished. Conflicts and overlaps between ReasonML's and Bucklescript's and JS's standard libraries, poor documentation, very flexible but…

What could be the fastest way to recompile TypeScript that also monitors for file addition and deletion? So far I'm having a decent experience with pm2 monitoring for any changes or additions of files to restart a ts-node instance but it does make you wait a few seconds or else nginx throws a 502 when the ts-node is still restarting.

Some projects use Babel for everything, including ts->js transpilation. If you go that route (vs using tsc), it may make it more straightfwd to leverage watch, along w/ the rest of the robust babel and webpack tooling that's available. /$0.02
Post reply on HN