[deleted]
25 Days of ReasonML
21–30 of 44 posts
Re: 25 Days of ReasonML
#22A weak point of ReasonML for me, last time I tried it, were the Promises; you have to remember to resolve them, with the compiler not providing any help. It's very easy to miss/forget to resolve them. While it is definitely improvement over JS, it's a step back from the sense of safety you get with TS.
I would say it's the other way round. In ReasonML, if you forget to resolve a promise, the compiler tells you the types don't match up. This is better and more reliable than the best linting rules you can get today for JavaScript. With TS, to be honest I'm not sure how safe it can be since it must play nice with the JavaScript rules that promises can be automagically resolved.
[deleted]
Re: 25 Days of ReasonML
#23Earlier quoted context omitted.
It's fully compatible with nodejs, so super feasible to do backend dev
Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
I ran all of my Advent of Code[0] solutions in Node.js - there's nothing specific really about running a ReasonML app in Node.js vs the browser. Except you don't need a module bundler for the former. :)
I've also been slowly working on a small CLI app using ReasonML, ReasonReact and react-blessed.
There definitely is a dearth of ReasonML server-side examples, libraries and frameworks, though - especially compared to all the front-end chatter. bs-express[1] is actually quite nice, but hasn't seen much attention from the larger community. I would highly recommend it if it's something you're interested in pursuing.
Re: 25 Days of ReasonML
#24I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?
Many devs don't really care for the MS ecosystem. Whether this is old illogical bias or based in reality, IDK, but most of the major tech stacks that that work across ecosystems are further along on the JVM, so people go there.
Re: 25 Days of ReasonML
#25I like the idea of Reason, but I currently do much more server coding than front end. The native compiler is currently classified as work-in-progress ( https://reasonml.github.io/docs/en/native.html ). I also wonder about how the community evolves if javascript-targeted reason libraries aren't compatible with native reason libraries. For instance, would a wrapper for a js promise library be able to work in server cod…
The standard OCaml native compile toolchain supports Reason: http://jbuilder.readthedocs.io/en/latest/overview.html?highl...
You can write in Reason syntax and deploy native binaries with Docker: https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-...
JS and native differences will probable be resolved just like with any other language that supports both: packages for common code, with specialised packages targeting specific platforms and having dependencies on the common packages.
Re: 25 Days of ReasonML
#26I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?
It's nor that hard of a sell I think... does F# compile down to javascript?
Re: 25 Days of ReasonML
#27I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?
F# is great for sure. You should definitely use whatever fits your needs best. I'm sure all of us will be happy just to see ML-style languages gaining greater adoption.
Re: 25 Days of ReasonML
#28I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could get people onboard with an ML, why wouldn't I use F# with it's massive backing ecosystem and fantastic server side runtime(node has come a long way, but it's no CLR)?
It's nor that hard of a sell I think... does F# compile down to javascript?
It does, there have been a couple options for a while but that had some catches but somewhat recently the Fable project came along and appears to be gaining tons of traction(for F# ecosystem) and killing it.
Re: 25 Days of ReasonML
#29Earlier quoted context omitted.
It's fully compatible with nodejs, so super feasible to do backend dev
Has anyone actually done this in a real app? The last time I looked for nodejs examples, I could only find small POCs. The vast majority of ReasonML material seems focused on the front-end.
There's definitely activity on the backend, especially with GraphQL, but we don't have any large success stories to report yet. Here's a very cool native-OCaml GraphQL server you can try out today though: https://github.com/andreas/ocaml-graphql-server
Re: 25 Days of ReasonML
#30I've been learning ReasonML for React Native these past few weeks. I love the static typing. I can work on my editor for minutes at a time, and when things compile I see it "just work" on my phone. This is important since reloading a native app is not nearly as fast as reloading a web page. The best part is how FAST the compiler is! It blows me away how fast the reason/ocaml compiler is, considering it spits out Java…
How are you handling navigation?