canadadu_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has quit [Quit: WeeChat 1.5]
rgrinberg has joined #reasonml
iwan_ has joined #reasonml
<iwan_>
a few weeks ago the parser didn't parse correctly with Bucklescript's ffi like [@@bs.new]
<iwan_>
I'll check it out if it's supported now
jonasen has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<iwan_>
Sweet
<iwan_>
external create_date : unit => 't = "Date" [@@bs.new];
<iwan_>
it works :D
<iwan_>
Chenglou, any plans to switch jsoo to bucklescript with jengaboot?
<chenglou>
Jengaboot currently generates some .cma files, which bs doesn't support
<chenglou>
Also, jsoo has source maps
<iwan_>
k
<iwan_>
No idea how they're doing it but bucklescript's generated js code is plain amazing
<iwan_>
very impressive
<canadaduane>
yes, it's beautiful and easy to understand
<iwan_>
Do you have any idea if it's possible to store records & other user defined types in javascript & get them back out in Reason without manually having to convert them?
<canadaduane>
My understanding is that BuckleScript's FFI is more direct than js_of_ocaml and hence, it should be quite easy to go both directions.
<canadaduane>
I was told by the developer of BSc that they have an FFI solution coming in the next couple of weeks.
<iwan_>
They should be focussing on React bindings ;)
<canadaduane>
that would be awesome
iwan_ has quit [Ping timeout: 250 seconds]
iwan_ has joined #reasonml
rgrinberg has quit [Read error: Connection reset by peer]
iwan_ has quit [Ping timeout: 250 seconds]
rgrinberg has joined #reasonml
canadadu_ has joined #reasonml
canadadu_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
canadadu_ has joined #reasonml
canadadu_ has quit [Client Quit]
<canadaduane>
So this might be a slightly controversial question, but because I'm new, I'm genuinely interested in understanding pros and cons of each. I'm currently considering Elm and/or Reason+BuckleScript as possibly The Language to use at my new startup company. In particular, I will be building a backend in AWS Lambda (which uses node/js) and a front-end (which uses ReactJS or a react-like behavior, such as Elm provides). Why should I choose ReasonML?
<bsansouci>
canadaduane: To me it might not be useful if you're planning on running JS server side anyway. I'd use plain JS + Flow annotations, those should bring you pretty far. If performance is ever a problem, you should consider just running the reason/ocaml code on your back as such and not transpire to JS.
<canadaduane>
is Flow functional? (I know it's typed)
<bsansouci>
canadaduane: Flow is a type checker for JS, it'll check and infer the types of a normal JS program. It aims for correctness as opposed to typescript (which also imposes a bunch of syntax changes I think)
<canadaduane>
Why do you prefer not to code in a functional style if it's server side?
<canadaduane>
(not a criticism, I'm just trying to understand what I may be missing)
<bsansouci>
canadaduane: I'm not sure I understand your question. You choose to write your code however you want?
<canadaduane>
right, sorry, what I heard you say was that transpiling to JS might be a poor choice if the JS is targeted at the backend, i.e. AWS Lambda
<canadaduane>
so, choose Flow instead
<bsansouci>
I'm saying it's a lot for not much? If you're gonna write in an ML language, you might as well use Reason and run the code natively, but if you're attached to JS for the backend, I don't see much advantage to Elm. The reason I mentioned Flow is because you might want typecheking at _some_ point in JS. Hell you could just write vanilla JS, it's so much
<bsansouci>
simpler lol
<canadaduane>
true, yes, but I'm so tired of running in to JS errors that should have been caught by a type checker :)
<canadaduane>
so Flow does make sense in that case
<canadaduane>
I come from a background of Ruby and Javascript
<canadaduane>
both of which are not type checked
<chenglou>
canadaduane: does Lambda have ocaml support?
<canadaduane>
No, it's Javascript and Python only at the moment
<canadaduane>
(I think Python is the 2nd option...)
<chenglou>
Elm's interop with js was still iffy last time I checked (not to blast Elm, I love it)
<chenglou>
jsoo is mature and gives you all the escape hatches you need for your js needs
<chenglou>
example:
<canadaduane>
they have the "port" keyword to give interop I think