Compiler Development: Rust or OCaml?

• book

  18 1,160 2.7 OCaml

  V2 of Real World OCaml (by realworldocaml)

  

• rust-playground

  67 1,168 9.5 Rust

  The Rust Playground

  

I like Rust, but this isn't one of it's strong suits. The code in the article is what Rustfmt outputs (playground link below), so it's syntactically idiomatic.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• esy

  8 840 9.2 Reason

  package.json workflow for native development with Reason/OCaml

  

As someone who wrote a fair amount of Rust and OCaml code, I have to agree with the author.

While working at Routine (YC W21), I was tasked with porting our core library to iOS to minimize code duplication. This was a lucky opportunity to write something resembling a compiler: it took in schemas described with our in-house data exchange library and generated C (for FFI) and Swift code (for the end-users, i.e., iOS developers).

Since Routine uses OCaml for everything (which was a big motivator for joining the company—I wanted to see how that would work out), I wrote it in OCaml. The end result is a 3-5k LOC project. It's by no means a full compiler, but it was lots of fun to write. The language got in the way incredibly rarely. On average, it made my life a lot easier.

We did encounter our fair share of issues, mostly due to the cross-compilation tooling (we initially used esy [1], flirted with Nix, and eventually switched to opam-cross-ios [2]), third-party libraries, and intricacies of FFI. Those do take their toll on sanity.

[1]: https://github.com/esy/esy/

• opam-cross-ios

  1 61 10.0 Shell

  An OCaml cross-toolchain for iOS and several useful libraries

  

• coalton

  84 991 8.4 Common Lisp

  Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.

  

> Lisps can be very flexible, but they usually lack static type safety, opening a wide and horrible door to run-time errors.

People should do basic research before writing something silly like this. Qualifying your statement with 'usually' is just a chicken sh*t approach. Common Lisp and Racket have optional strong typing, leaving the responsibility and choice to the developer. Common Lisp is great for implementing compilers. You also have thing like Typed Racket and Coalton. The latter is comletely statically typed ala MLTON

https://github.com/coalton-lang/coalton

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project