I used OCaml in production for a 2 years and it was a very pleasant experience. Recently I started using ReasonML at my team to implement a Kubernetes configuration tool. It’s surprisingly easy to use ReasonML for backend development with dune and esy.
ReasonML: Strict, powerful and forgiving
21–30 of 60 posts
Re: ReasonML: Strict, powerful and forgiving
#22In the context of developing React webapps, what advantages obtain from ReasonML over TypeScript?
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 very unintuitive JS interop syntax, frequent updates that break your code, etc.
One big advantage is that ReasonML's compiler is lighting fast. As in, it compiles a big project in an instant. I don't know how it works behind the scenes, but the sheer speed changes how you develop. With JS/TS, you hit save, wait a few seconds for the iterative recompilation, refresh your browser, check your work. With Reason, you code, hit save, immediately get a helpful error message, rinse and repeat, and eventually you open up your browser and everything works 100%. It's pretty cool.
Re: ReasonML: Strict, powerful and forgiving
#23I used OCaml in production for a 2 years and it was a very pleasant experience. Recently I started using ReasonML at my team to implement a Kubernetes configuration tool. It’s surprisingly easy to use ReasonML for backend development with dune and esy.
[deleted]
Re: ReasonML: Strict, powerful and forgiving
#24I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers. Those ReasonML has some downsides that need to be addressed: - Bucklescrip…
Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?
In principle it seems like a significant limitation but in practice it is rarely an issue.
ReasonML does support parametric polymorphism so it is still possible to write generic code.
Some language features conveniently help to avoid boilerplate. For example it’s possible to have a `Float` module with arithmetic operators and “open” it like this: `Float.(10.0 + 0.5 / 3.0)`.
There’s also a work in progress project called Modular Implicits that will introduce ad-hoc polymorphism.
Re: ReasonML: Strict, powerful and forgiving
#25Doesn't typescript also have variants and similar variant checking? Maybe not understanding what the big deal here is...
https://www.typescriptlang.org/docs/handbook/advanced-types....
Re: ReasonML: Strict, powerful and forgiving
#26We 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.
> The whole class component story in Reason felt kinda clunky
See bucklescript-tea for goodbye clunky :)
Re: ReasonML: Strict, powerful and forgiving
#27Avoiding reason-cli and just using bs-platform and reason-vscode together is the way to go in this ecosystem. The problem with reason-cli is that it can get out of sync with the bs-platform version and fail in unclear ways. There was quite a bit of pushback against reason at my shop due to the interop between these two packages and trying to do things like have autocompletion fail because of them. It’d be nice if the…
Hi, I work on Reason full time and have been managing the reason-cli releases, and I'm happy to say that we're pretty close to not needing reason-cli anymore because the much better alternative is to _avoid_ global installs and instead model IDE support and as devDependencies of your project. We only have been releasing a global install (reason-cli) because:
1) Until recently we didn't have better alternatives for BuckleScript based projects (but then Reason Language Server came along)
2) We didn't have a good way to quickly install per-project dependencies for the Reason Native workflow. But then we built esy for native workflows which makes it very fast to install large dependencies across multiple projects by using a relocatable immutable package build cache.
Now, there's much less reason to use a global install and global installs will always have the problem of conflicting with project dependencies. I think you're picking up on that fact. Here's to the sandboxed project future!
This kind of stuff is often discussed in the Discord ReasonML channel so if you're ever curious to read the pulse on the direction of dev tools, feel free to join the discussion.
Re: ReasonML: Strict, powerful and forgiving
#28Earlier quoted context omitted.
reason is fully compatible with ocaml. nothing has been bifurcated. it is not even the first alternative syntax - the "revised syntax" had been around forever. https://caml.inria.fr/pub/docs/manual-camlp4/manual007.html
Reason compiles to Ocaml, yes. Does Facebook actually want you to just use Ocaml? Sure doesn't seem that way to me. Facebook is pushing their own tool, and their own libraries to go with it. Interoperability between Reason, Bucklescript, Ocaml native, OPAM libs, and the various build tools in between is confusing and ill-defined. The path of least resistance just seems to be "stay in our garden... there's no walls te…
>>> Does Facebook actually want you to just use Ocaml?
Facebook already uses OCaml.
Re: ReasonML: Strict, powerful and forgiving
#29Like 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 new users familiar with the language constructs (I was very skeptical about this before)
* ReasonReact is very nice and works great out of the box
* Writing bindings is generally pretty easy to do, and we're currently maintaining 4 of these (+ 2 existing binding we've contributed to)
* The language and compiler do a great job at working with you to figure out issues
* Everything feels a million times more structured than normal JS code
* Not sure if this is an up-side, but writing code in Reason is so much smoother than other languages that I feel like it's pushed us to implement more client-side features than server-side ones (unfortunately, this means everything depends on a ton of JS)
* Super readable, I feel like I can skim the code and know exactly what it does instantly
Negatives:
* It's still JS, which means you have to deal with a ton of crap from NPM, WebPack, JS's module system, weirdly written libraries that don't do well with bindings, and things breaking in weird ass ways that you can't easily debug... I think this has been the source of 90% of our bugs so far
* Still no way of getting higher-order components working well, specifically with bindings, which makes it really hard to work with libraries like react-grid-layout
* Polymorphism could still be improved. We occasionally get type signatures that should work in theory but can't because of the object system's limitations, which means we have to give up on the type safety and fiddle with Obj.magic or external JS code
* The JSX syntax is still annoying because you can't use spread syntax with a native element (e.g. div), although eventually I'm gonna get tired enough of doing that that I'll open a PR to fix it
Overall, Reason is by far my favorite way of writing web apps. If that's something you've got to do, give Reason a try. There's still a few pain points but interop with JS is so simple that it hasn't really slowed us down (except when webpack breaks lol)
Re: ReasonML: Strict, powerful and forgiving
#30Earlier quoted context omitted.
Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?
In principle it seems like a significant limitation but in practice it is rarely an issue. ReasonML does support parametric polymorphism so it is still possible to write generic code. Some language features conveniently help to avoid boilerplate. For example it’s possible to have a `Float` module with arithmetic operators and “open” it like this: `Float.(10.0 + 0.5 / 3.0)`. There’s also a work in progress project cal…
Even then, I feel like working with Floats vs. Ints in a web browser is almost never an issue. I'd just open Float if I need it because I can't think of any scenario where I'd use both in one module