hello! i’m looking for a language to use for frontend webdev that’s safe and secure like rust. i think rescript has an option-like enum for null and undefined, but how does it handle errors? how safe is it in that regard? for example in rust it’s impossible not to handle a result, the enum is like Result<Success, Error> as opposed to Option, how do you handle errors/fallible methods in rescript?
1 Like
In this regard, things are pretty much the same. Same result type with the same signature. There is no such thing as the Error trait, though.
3 Likes
ohh thanks for the reply! i couldn’t find it in the docs, also how about the rest of the language features/philosophy is it as safe as rust or how close does it get
ReScript has about 2.5 different ways of handling errors.
First, ReScript has exceptions: Exception | ReScript Language Manual . These work much like JavaScript exceptions, except a bit more type-safe. Throwable exceptions are all values of type exn.
Also, ReScript also supports throwing JavaScript-native exceptions like Error, etc. These are ‘native’ JavaScript exceptions that are understood by standard JavaScript tooling.
Finally, ReScript has a built-in result<'a, 'e> type as Alex mentioned, with Ok(a) and Error(e) constructors.
Which one(s) to use depends on the circumstances and how much you want to guarantee in your codebase. But it’s likely that most codebases will grow into using all of the above.
4 Likes
They are relatively similar (since both languages take roots in the same language, OCaml), but ReScript is more relaxed, I would say.
Here is the list off the top of my head:
- ReScript has escape hatches, such as
Obj.magicand%identity. Sometimes it’s handy, sometimes the other way around. - ReScript doesn’t have ownership/borrowing concepts.
- In ReScript, I deal with FFI way more than in Rust. So there are usually more points of failure in ReScript codebases. That’s not the specificity of the language, though, but the environment.
- ReScript doesn’t have an analog of traits, so defining a shared behavior is not as convenient as in Rust IMO.
- I like working with ReScript variants more than with Rust enums due to the inference capabilities and flexibility. Rust doesn’t have polymorphic variants, which are sometimes handy.
- Both languages have type inference, but in ReScript, it’s kinda all over the place. You don’t need to annotate anything. Though, I prefer to annotate abstract parts b/c it makes errors less confusing. But it’s a personal preference and not recommended if you want to write idiomatic OCaml.
- Modules systems in both languages are pretty nice but different. I like that in ReScript, I don’t have to deal with imports (all modules are available globally), but I wouldn’t mind having more flexible namespacing in the big apps. Also, I wouldn’t say I like interface files in ReScript applications, as opposite to libraries, b/c I have to write and maintain them, but it’s the only way to control scope and privacy. Again, it’s a personal preference.
- ReScript feels more “functional” in that I deal primarily with immutable structures (though I do mutate arrays quite often since it’s JS), and pipes are the default way to apply a function. I do miss pipes in Rust, a little.
- Macros system in ReScrip is light years behind Rust’s, and its future is unclear.
- Cargo is much more advanced as well.
The list is far from complete and might contain opinions 
8 Likes
Beyond whether the result type is available, I would also compare advice on the forums here versus Elm and idiomatic libraries in each community, to see how far you want to go into using result type.
to me it seems like the differences arent big enough to not use rescript, unless there’s a better option for me
the only bit that makes me a bit scared is that its more functional, that was the reason i gave up on elm! but unless i have a better option, safety comes before my paradigm preferences
i’ve tried elm actually, it was really good, but it was purely functional and that threw me off eventually
ReScript isn’t obsessed with purity if that’s what you mean.
thanks! i actually started learning a bit, so i think rescript is more like vanilla js style webdev, whereas elm is standalone programmatic unless i’m missing something, i couldn’t really find a guide on webdev with rescript but ig that’s bc it’s the same as js? i.e
Main.elm
getText = "hi"
div [] [ p [] [ getText ]
rescript:
index.html
<script src="src/Main.bs.js"></script>
<p id="text" onclick="showNewText()">hi</p>
Main.res
let showNewText = () => getById("text").innerHTML = "hi again"
Elm is a programming language that also brings its own architecture — prioritizing purity over compatibility with the existing JS ecosystem. This makes using existing JS libraries very tedious and you can’t just drop in a single Elm file use it in legacy JS code… so if you’ve got an existing codebase already, you either need to rewrite the whole thing in Elm, or embed Elm apps within your existing codebase. That said, if there’s some Elm code / library, it’s almost guaranteed to be runtime error free, and that’s cool.
ReScript on the other hand tries to embrace a philosophy where compiled code looks more like your typical JS that mixes well with existing code… especially with existing React apps (but since it compiles to JS, you could also use it for Node, or even Deno). Its binding layer makes it generally easy to use JS modules, although it’s also the user’s responsibility to find the right balance between runtime safety and performance / API usability.
I consider ReScript to be a trimmed down (typed) version of JS, with a handful of very powerful features that make it easy to write and maintain complex app logic (e.g. pattern matching, pipe operator 100% type coverage at all times). It’s definitely not as expressive as JS or TS, but its simplicity allows us to keep compilation speed up as our codebase grows. It’s also way more pleasant to maintain older ReScript codebases due to the type system’s nature… something really hard to show if you haven’t been using the language on a daily basis though.
At this point I am not even sure what “functional” means… there’s the puristic approach of FP, like in Haskell, Elm or PureScript… ReScript can do some of that stuff too of course, but if you are elbow-deep in some legacy React app (with parts written in ReScript), you will most likely “embrace tradition” and write in a JS like style to get work done and make your customers happy.
1 Like
so to make sure i’m doing the proper design here (couldnt find a guide on frontend webdev with rescript) i basically just do whatever i was with js, but in rescript?
Well something like that. ReScript is still its own language, so you’ll probably run into situations where the type system prevents you from doing certain dynamic JS things. Very early you’d need to learn how ReScript’s type system behaves and how you’d write JS bindings (or use builtin bindings for e.g. Array.map) … for webdev, the beaten path is mainly ReactJS development, so I can’t tell how easy it will be to write bindings for your particular UI framework.
There’s a small guide for Converting from JS by example… maybe this gives a better idea of what I mean.
The forum is usually a good place to ask questions about concrete problems in case you are stuck!
3 Likes
thank you!! i’ll just follow w3 school then! also my ui is nothing that complicated and i’m personally not into react much
If you find React heavy, it sounds like you want to avoid vdom frameworks. In that case, something like alpinejs sounds relevant (I don’t have personal experience with it). If you use alpinejs, then I wouldn’t bother introducing rescript or anything beyond js.