We’ve merged the NextJS / ReScript / Tailwind codebase to the backend server that serves the package documentation. This has allowed us to consolidate our technology stack and simplify our continuous deployment story, but also to directly serve the website from a pure OCaml stack (using packages from our own community such as Dream and ocaml-tls). We’re deeply grateful to the ReScript team for the technology that let us prototype the new revision of the website so quickly, and to implement the templates we’re now using.
Looks like the site is now fully server-side, served by Dream. Dream itself is a very promising Sinatra-like lightweight framework, the Mirage people also seem to be using it. It’s getting lots of attention and dev work.
I am a NodeJS developer and I was looking for any library that helps me to write NestJS app in rescript. I see the rescript-express and I was hopeful to find something like that. And also some wrapper or binder for Prisma. But until now I couldn’t find it.
So I’m not so sure ReScript makes sense for nest since nest is really just a wrapper around express in a sense but is pretty object oriented in it’s structuring (which I like). I’m thinking that this might feel a bit unnatural if you were to build the same server in ReScript.
My thinking here is either the express binding would be good or maybe some fastify bindings, however, another interesting idea is to write a simple framework in ReScript fresh and trying to leverage a more ReScript / functional style in the architecture and semantics of that framework. Dream seems like a pretty good inspiration for that and then you maintain the access to the vast node ecosystem and third party vendor SDKs etc.
I agree with everyones’ sentiments along these lines. At one point, I had to choose between a long refactoring of a very bizarre Haskell codebase or working with a greenfield golang rewrite that was half way done, and I chose to clean up the Haskell codebase because I found golang so limiting.
For now, I think I have reached a point where I think an engineer can have a limited number of passions. When an engineer is drawn to Haskell, the far end of the FP spectrum, I don’t usually detect much interest left in the actual product domain. Some of the Rescript contribs have mentioned similar sentiments about pure FP focus versus thinking about design, product, ux, etc. My small, scattered past experience may be too biased. Probably engineers at Ahrefs and Hasura have a mixture of passion for elegant code and great product requirements, I just haven’t worked with them.
I definitely support folks who go after the FP passion and I do think it yields very clean, easy to refactor code. I would just try to balance it out with having very good product owners and requirements analysts.
There’s been some exciting exploration[1][2] into running ReScript on Deno[3].
For the uninitiated, Deno is a project started by Ryan Dahl, the creator of Node.js, to “fix a long list of inherent problems in Node.js.”[4]
I’m personally very excited about this possibility. Deno’s JavaScript paradigm seems much closer to that of frontend JS. If you think isomorphic applications are the future, and a lot of big players seem to think this, ReScript-on-Deno + ReScript-on-Browser seems like an ideal setup.
I think Dream is awesome, but I wouldn’t bet my startup or consulting agency on ocaml until ocaml foundations invest serious money into implementing thorough bindings for AWS, GCP, and Azure, to fill in the gaps that led darklang to jump ship for f#.
Have you checked out the AWS bindings? Personally I think you can go pretty far with a web stack, Postgres, Redis, and a couple of other basic mainstream pieces to build great products. I don’t see the appeal of putting all your eggs in your cloud provider’s basket, but if you need to it’s definitely possible to call their HTTP endpoints. In fact that’s exactly what Dark was doing before they switched:
We’ve worked around other missing vendor SDKs by calling their HTTP endpoints directly and that’s been mostly fine.
But sure, if you absolutely can’t afford to take chances on any missing pieces, OCaml native is perhaps not a good idea. At least F# is a great language as well as being backed by a great ecosystem. And with a microservices strategy, having two target stacks (OCaml native and Node.js) is pretty doable too.
I like the idea of Deno compilation too. That being said, I also don’t think I really mind being stuck with Nodejs. As a runtime for web servers and applications I actually think its pretty dam good plus the ecosystem has early support for most third party services. There are definitely worse places to be than the Node ecosystem for building products. I imagine Deno is going to be just as good one day as well.
I second this. I don’t get the irrational hate against the JS runtime… I’d understand that ppl despise JS as a language… but from a productivity perspective a JS VM is way more useful than trying to get your arbitrary binaries compiled and running. Not everyone has business requirements to run unikernels
And if you are scared by third party JS libraries, there’s still the option to maintain your own library written in ReScript. The same thing you’d probably be forced to do in OCaml, because the ecosystem is way smaller in the web development space… at least I have options to fall back to in case hell breaks loose and managers breath down my neck.
The quality of the ecosystem is exactly the issue. In JS, you can face complete crap with 10+K stars on GH. You need to read sources every single time. Personally, I don’t want to maintain one more thing. It is a productivity killer. JS runtime doesn’t worth it. I do this in FE code a lot because I have no choice. But on the BE, there are much better options in all respects.
I don’t either, I prefer to (and the product I work on is generally forced to) build everything custom, but having the option there as a short-term technical debt fallback is handy. It’s certainly better than having to delay a project to rebuild some critical piece.
JS is not the only ecosystem that has a large registry though. I’ve been working with Rust mainly for the last 4 or 5 years, and it’s better than Node in pretty much everything. The quality of the ecosystem is incomparable. I guess Scala/Kotlin/F# and such can serve similarly well, or maybe even better.
I’ve been working with Rust mainly for the last 4 or 5 years, and it’s better than Node in pretty much everything.
So I have been learning rust on and off for the last few years and as much as everyone raves about the ecosystem, of which I have no complaints, its still a very hard language to learn and onboard engineers into. I do feel that you really really learn a language when you finally start building a real product in it and I’ve just never gotten the guts to take money from someone and build their product in rust. The one exception here would be that if I were building a project that absolutely needed rust for the features of low-level and not garbage collected language or perhaps WASM. Otherwise the reality is that most of the practical use cases I would work on, I would be using rust because I wanted to and not because it was what was best for the project. It’s a wonderful language don’t get me wrong but from the standpoint of a web server I really don’t think its the best option.
One other point of clarity I want to make is when we talk about packages on npm. Most of the time I’m really not using a lot of npm packages for things I could write myself. Really the big value I find from node is that lots of third party vendors build SDKs for node and when building projects for profit, a third party vendor can save you valuable time and therefore a customers wallet. In that regard @dangdennis really hits it with business first, Go is starting to see a lot of support from vendors now on par with node, python, ruby, etc. which is why it is a valid consideration on top of it being much easier to pick up than rust.
I guess Scala/Kotlin/F# and such can serve similarly well, or maybe even better.
I did consider Scala and F# as well since the JVM and .net platforms often have these third party SDKs as well with vendors. I think the main issue with JVM and .net is in the context of serverless computing I think they tend to under perform. Not that everything is serverless of course but with node and python and go you can go into both arenas without much of the performance issues. This leaves you with options. Serverless is one area I could see OCaml doing very well in and being competitive with go, save the third party SDK issues. That being said looks like ReScript bindings for AWS Lambda is a great option as well there.
Ultimately I like the idea of leaving these options open because once a real project starts it allows me to delay decisions or preserve the agility to change approaches. Node for all its shortcomings does give you a lot of options for configuration, for deployment, compile to js langs (clojurescript, purescript, rescript, typescript, …). And in recent years the platform has been very stable and have not run into tons of bugs and issues myself using it.
Most of the services are covered, AFAIK all the important ones, bar some where I had trouble with the recursive shape definitions. They use the Smithy definitions from the AWS SDK and bind to the SDK itself.
I’d love to do it for OCaml as well, but that is a whole lot more work as it means building out the clients themselves for the various protocols AWS uses in their services.
I’ve seen these and they look really useful, but some critical services (such as SNS, EventBridge, S3, DynamoDB, IAM) are not present, so I wonder if API generation using the Smithy definitions would be valuable, especially given the other services it would open up.
. I totally skipped that entire section of the post.
