Is there a Unix module in rescript? If not, why does it not exist? Would there be an equivalent process in Node.js?
Thanks.
Hi, the Unix module specifically exposes operating-system level functionality and is not cross-platform portable, hence it is not available in ReScript. For Node.js equivalents, check the bindings here https://github.com/sikanhe/reason-nodejs
@yawaramin thank you, sir. That is what I have been exploring randomly. Thank you for the important details about the scope of the module.
It seems to me that ReScript bindings to the Deno runtime library (or a suitable subset) would be a great way to promote the language, one that would give, I believe, a good tradeoff for the cost in resources.
The Deno engine is written in Rust, and should have a sizeable proportion of users/developers familiar with that language. This is just a hunch, I don’t have statistics. My point is that Rustaceans are very much aware of the advantages of a type safe, strongly typed language for productivity, and that the apparent strictures are not a hindrance, but guidelines for writing better code. And they would rather use variants (tagged enums) instead of C enums or union types, and benefit from pattern matching. And they don’t want to go back to using undefined values when they have Option types. These are points that keep popping up on the users forum and reddit. Rust’s debt to OCaml is also well known, although people will often invoke Haskell for some construct that actually originated in ML or OCaml.
Moreover Deno people think something should be done to improve the speed of the Typecript compiler.
3 Likes
I agree that deno or customised js runtimes for rescript makes sense, so that we don’t need jump the hoops to type nodejs and it should be more efficient.
The main challenge is that we still need wait the community to grow to have more manpower to work on that.
2 Likes
AFAIK Deno is mostly a thin layer of Rust and TypeScript libraries on top of the V8 engine, which Node.js also uses. It’s a cool project but, for realistic production use, Node is still the go-to. Of course, this is not to say that people shouldn’t try to integrate Deno and ReScript–that would be very cool–but if our philosophy is focused on shipping production software today, then Node is the option I would recommend.
2 Likes
Just as an aside, I have played around with Deno and ReScript, and setting up a working program was pretty straightforward. You just have to use the correct configuration for imports (I think it’s ‘ES6’).
ReScript will generate code for module imports with the full path, instead of just the module name (which is also allowed by Node), so it works with Deno right out of the box. You just have to write bindings for Deno’s API. The only issue here is that ReScript could easily change the way it generates import code in the future, which might not break programs in Node, but might break them in Deno. So I would proceed with caution if the program is important.
Honestly I would love to see Deno used more. I think its API is far more reasonable than Node’s. But the ecosystem does need to catch up a bit before it’s worth it for most companies to switch.
Edit:
I should add that Deno’s API is WAY more friendly to ReScript’s way of thinking about types and interfaces. The bindings are much more straightforward for Deno.
2 Likes
@austindd Do you have a sample repo that I can peek/poke? I am just starting to have a look at deno and indeed the bindings could be easier since its API is already type annotated.
@bikallem I’ll dig around in my repos and see if I can find it. I remember writing a bunch of bindings for the Deno API, but it might be on a different PC, and I’m not sure it’s on my GH yet.