Hacker News new | past | comments | ask | show | jobs | submit login
Programming a space invader in OCaml and OpenGL: lessons learned (marmelab.com)
124 points by juliendemangeon on Feb 21, 2020 | hide | past | favorite | 118 comments



ReasonML is just an alternative syntax for OCaml. Often people use "ReasonML" shorthand for "ReasonML, converted to OCaml, compiled to Javascript with BuckleScript" and "OCaml" for "OCaml compiled natively" but it's perfectly possible (and actually really easy) to use OCaml with BuckleScript and Reason natively.

Also note that despite the "O" in the name, OOP in OCaml is rare (for instance, there isn't any in the code in the article).


> Also note that despite the "O" in the name, OOP in OCaml is rare (for instance, there isn't any in the code in the article).

Which is kinda sad, because it has one of the best OO type systems in the industry, in my opinion. The decoupling of inheritance and subtyping, in particular.


What's the state of using Reason natively? Last time I checked all the documentation and examples where towards the reason/js/react ecosystem. Are there any good native code projects written in Reason to look at for reference?



That looks perfect, thanks!


There are two significant projects for native Reason:

- https://esy.sh/ - a package manager that offers a lockfile, aggressive build caching, and reproducible hermetic builds. So when you come back to a project a few months later, it still builds.

- https://reason-native.com/ - an umbrella for useful Reason-oriented native libraries


Reprocessing is a rewrite of Processing in Reason.

Runs with WebGL and OpenGL.

https://github.com/Schmavery/reprocessing


People don't do it much, but if you're using the most popular build system (dune) you can replace your .ml files with .re ones and it will Just Work. So you can use OCaml projects for reference (I think anyone who's doing Reason should have a vague grasp of OCaml syntax, it's not really that different).


> I think anyone who's doing Reason should have a vague grasp of OCaml syntax, it's not really that different

Especially if you're targeting native, so all your dependencies are written and documented in OCaml syntax.


Aren't the Ocaml and ReasonML syntaxes so similar that you can effectively convert both directions and still end up with clean idiomatic code? That has seemed to be the case when I've played around with the ReasonML, and if it's the case, then which one you choose to write is very much arbitrary. Heck, you could even write one syntax locally and then automatically convert to the repo's preferred syntax when you commit your code.


Yep. This is an especially weird thing for some people to grasp when working with native libraries developed in Reason (like Revery, which most people assume is built on web tech).


You're right! The toolbox is far better too


> it is very complicated to install the base stack to develop in OCaml

I'm not sure why the author decided to use such a complicated setup using Make and Docker.

They could have just ran `opam switch create 4.09.0`, which would have created the compiler, then `opam install ...` for the dependencies.

Still, an interesting article. I wouldn't recommending using OCaml/ReasonML for gamedev since getting it to work with Windows is pretty much impossible.


While I didn't try to use Docker (though we did use the same pxhere image :-p), I also struggled to get a productive setup of OCaml. Getting a switch running wasn't the hard part, it was making the environment suitable for real project work. I had a set of Make targets in mind (test, build, shell), some language dev features I wanted (jump to definition, type of expression under cursor), and some properties of the project (pinned dependencies) such that it took a fair bit of fiddling with dune/opam to get it working https://morepablo.com/2019/08/fresco-jesus-ocaml-setup.html

I find OCaml really enjoyable once I got going, but I do think the initial setup is a major barrier to larger adoption. I think a post on howistart.org might be useful, but it'd probably be polarizing since most functions have two major ways of doing it (Jane Street vs. not, Lwt vs. Async, etc.).


I agree it's quite annoying to set up an OCaml project, and all the Jane Street stuff makes it even more confusing for newcomers. But to be fair, it may be the case with other languages as well. I recently tried to learn some Javascript, and I spent some time understanding the tooling and package management (npm/yarn, bundling, transpiling, node vs browser, difference between javascript versions).


.NET you install either Visual Studio or just the SDK and everything just works. And it's not just the initial setup. It's the best debugging experience available. It has a robust extension system, though honestly, you don't need to engage it and you're still having an amazing experience.

For a while, I grumbled that it had spoiled me for other languages, the "fun" looking stuff that everyone talks about online. But as with all... rustic... experiences, it's only fun for the weekend. I wouldn't want to spend my entire life chopping wood for fuel, either. Even after spending 3 years fully in JavaScript land, getting very comfortable with all of the tools, it never really got "good enough". Years of effort and my dev experience was still worse than a default VS install. So I went back and have been loving life again.


VS installation is also a PITA if you have your C:\ on an SSD. The installer doesn't give you choice of what partition to install to (for most of its huge disk space demands) so you need to fake it with a bunch of symlinks. The VS team recognizes this problem but doesn't do anything about it, as follows from the comments on https://developercommunity.visualstudio.com/content/problem/...


Or just buy a bigger SSD. Makes all kinds of things much nicer.


Difficult when I’m using Bootcamp on a MacBook Pro unfortunately


Well there's your first mistake ;)


Modern JavaScript is a major pain to set up, but the difference with other languages is that for some things it's the only language available.


What's the answer to the confusion around the Jane Street stuff? Do you recommend it for newbies?


Good question. Their libraries are robust and certainly useful if you want to develop real applications. I'm not sure but I'd say no because I think they add an extra level of complexity of a newbie. They are also quite opinionated which some people may dislike.

I talked about "confusion" because I suppose a newbie may quickly be confronted with this question, for intance if they want to follow "Real World OCaml" which is based on Jane Street libraries.

The tooling around OCaml has really improved a lot these last few years (opam, dune, core/async, merlin, ppx...). The downside is that it raises the bar for newcomers.


This seems sort of like comparing the complexities of learning German to a level of fluency with the complexities of learning English, differences between major variant forms of English, with a deep dive into the history of the English Language and its poetics.


It is complicated to figure out a straightforward way to do builds in OCaml. If you're not tapped into the Current Way, you kind of have to read this blog, read that fragment, piece it together. I worked it through for a project of mine, and it was unusually unpleasant vs, say, Haskell.

Docker because, presumably, he didn't want to dink with installing it locally.


> It is complicated to figure out a straightforward way to do builds in OCaml

Sorry, what is not straightforward in building with `dune`?


Some things I ran into:

- How do I run tests? Oh, you can't really dune runtest on executables, only libraries. So how do I run tests on executables? Make a library with the core of the functionality and wrap it, I guess. Wasn't obvious.

- Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere. I wanted my source files in a `src` directory; most of the examples assume your `dune` file is just hanging out with the source in the toplevel.

- Does `dune` handle dependencies (like I would declare them in a rebar.config, mix.exs, or a package.json)? Not really, it plays with opam, requiring one to read a bunch of docs for opam, and its files, and where they should go.

- The syntax of the dune files changed a bit from when I started the project (it was just moving from jbuilder -> dune). Less of an issue now, though I still question the use of s-expressions.

- Can I load an interactive shell with the definitions? There's a command in the documentation for it, but it didn't work quite right when I tried.

- If you look at other projects, you'll see they use opam files differently from one another.

- How do I add a dependency in my current switch (something like npm --save install <library>?) I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.

I understand why it's like this (trying to tie together a ton of use cases) and love developing in it after it's all said and done, but there are a lot of rakes to step on.


> Tree-like heirarchy of dune files confused me since it wasn't really explained anywhere.

It's explained in project layout [1]. And it's not a tree like, it's basically flat, since it doesn't matter how deep in the file system your dune file is buried.

It's like `meson` in its concept.

> Does `dune` handle dependencies

It doesn't, and so neither do `meson`, `cmake` and most other build systems. As you may want to use various ways of installing dependencies: native packages, manual compilation, opam, esy.

> Can I load an interactive shell with the definitions?

Yes, you can run `dune utop ./path`

> If you look at other projects, you'll see they use opam files differently from one another.

Dune is independent of opam, opam file is needed to publish your package to opam. You can specify packages with dune without creating an opam file, see [2]

> I tried `opam install --deps-only`, but it complained sometimes about the state of uncommitted files.

If you use opam, you can do `opam install --deps-only`, or `dune build @install`, which would suggest a command to install missing packages.

[1] https://dune.readthedocs.io/en/stable/overview.html#project-...

[2] https://dune.readthedocs.io/en/stable/concepts.html#package-...


When I was putting together the build about 2? years ago, dune was not the normative standard.


I can't find it complicated at all. I control my OCaml builds mostly from simple, hand-written Makefiles. Reading up on the pertaining compiler and linker options is something you'd have to do for any compiled language. Building with dune isn't that much harder, either.


Agreed, the choice to use obuild was also bizarre. Dune has been standard for the last ~2 years and before that Oasis was the most popular build tool I believe.


As someone who loves OCaml, the “churn” in build systems confused me too. I’m hoping dune remains the standard for the next 10 years!


It's been a few years since I tried opam... When I did it just barfed out some obscure error message and I wasn't encouraged to try ever again. I realize that that's not really helpful towards improving the UX, but maybe it helps as a single data point?

(Just to avoid accusations of <whatever>: I actually discovered FP through OCaml and wrote a few early-ish libraries in the ecosystem, but then discovered Haskell... and the rest is history.)


Opam has gotten quite good. When you set it up, you're being guided through all the steps. Works best on Mac, with Linux a close 2nd. Windoze may pose some extra challenges for setting up a working environment.


Good know, thank you.

Probably never going to use OCaml again (just for business reasons, nothing against it per se), but good info for other readers.

EDIT: I also hope some of the OCaml'ers did get some of use of the things I wrote. I'm not going to doxx myself by naming the exact things, but just wanted to say... I hope you took advantage of them because the stdlib was quite anemic, so you might want to extend it. They were just missing bits of the ecosystem that I wanted to be more convenient... and I implemented a data structure paper or two.


The underlying OCaml naturally.

Having learned ML via Objective Caml's predecessor, Caml Light, ReasonML seems to be just sugar coating for those with aversion to ML classical syntax.


> ReasonML seems to be just sugar coating

That’s exactly what it is, no secret about that, that’s the goal of that project.


Which begs the question why not learn the real deal, instead of adding another layer to debug.

Programing isn't poetry.


Because sometimes the layer on top can express ideas more succinctly. A classic example is CoffeeScript's fat arrow syntax. It expressed a pattern in JavaScript we didn't, at the time, have a shorthand for. Example: https://coffeescript.org/#fat-arrow


And now it is dead, leaving behind a pile of code to rewrite in next cool toy.


In fairness, it's dead because it was shitty and made most things harder, and the things it did improve JS copied. If OCaml fixes its syntax, then we won't have any need for Reason.


There isn't anything to fix.


If you were right OCaml wouldn't be the only language with a popular syntax veneer.


As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.

If OCaml had Erlang's runtime (parallelism and concurrency via actors with message inboxes) it would likely be the most used language.

Its lack of adoption isn't at all related to syntax IMO. Programmers use all sorts of quirky syntaxes and the world hasn't ended yet.


> As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.

I agree that those things are pain points (I said as much upthread), but clearly the language is also part of the problem or else there would be no interest in Reason.

> As a guy who tried to get into OCaml development several times, the language is not the problem at all. It's the several different "standard" libraries, lack of good official agreed upon tutorials and guides, and the fact that it has a GIL and is essentially single-threaded.

A big reason Erlang is similarly unpopular is its syntax as well (many of the most popular languages are dynamically typed, so we know it's not the type system). This theory is supported by the relative popularity of Elixir, which shares Erlang's runtime and which has enjoyed a fair amount of popularity in a relatively short time despite introducing a number of syntax- and non-syntax-related quirks. OCaml on BEAM would certainly appeal to the intersection of FP and static-typing enthusiasts, but it would not remotely be popular.


> OCaml on BEAM would certainly appeal to the intersection of FP and static-typing enthusiasts, but it would not remotely be popular.

I realise what I said is not an undisputable truth and I wouldn't argue about it. I probably should have just said that I am observing an almost global strive for dev teams to be able to catch bugs earlier and to have a bit more guarantees by the mere virtue of the program successfully compiling. But it might be my filter bubble.

This is why I said an OCaml with the BEAM guarantees would likely rise very high; because my observations lead me to the belief that people want more compile-time guarantees. And yeah, that might be a skewed observation.


> I realise what I said is not an undisputable truth and I wouldn't argue about it. I probably should have just said that I am observing an almost global strive for dev teams to be able to catch bugs earlier and to have a bit more guarantees by the mere virtue of the program successfully compiling. But it might be my filter bubble.

I think this is a pretty broad pattern, but:

1. It's not happening in isolation; there's also a move toward greater development velocity

2. There's lots of low-hanging fruit to be had--lots of people can get tremendous safety benefits by moving from languages like JS and Python to Go or TypeScript or typed-Python even if they don't have as elegant a type system as OCaml (and those alternatives don't require the same tradeoffs as OCaml or even an OCaml on BEAM).

> This is why I said an OCaml with the BEAM guarantees would likely rise very high; because my observations lead me to the belief that people want more compile-time guarantees. And yeah, that might be a skewed observation.

Like I said, I don't think it's a skewed observation, it's just that there are other ways of getting most of those compile-time safety benefits with fewer tradeoffs. But I would be a huge fanboy of an OCaml-like type system on BEAM (especially if it can have Go- or Rust-like attentiveness to practical software engineering concerns).


On the other hand, if Reason were such a massive improvement to OCaml syntax, where are the people clamoring for F# to adopt more of Reason's ideas?

(Admittedly, F# already shares a couple Reason ideas like C-style comments instead of OCaml's traditional ones. So the waters are clearly muddy here to begin with, but a lot of the big things like let-binding scopes and ;; versus ; presumably would be big F# requests if Reason was so strongly superior to the inherited OCaml legacy.)


> where are the people clamoring for F# to adopt more of Reason's ideas?

Probably writing C#.


F# already has the main things people like about Reason.


TypeScript says hi.


Typescript makes virtually no changes to JS syntax, except what's necessary to support types.


TypeScript classes, constructors and enums say hi.

Talk about moving the goalposts...


No one is moving the goalposts. TypeScript's raison d'etre is to add static typing to JS. Reason's is to fix the syntax.

(Yes, TS adds new grammatical constructs, but grammatical constructs are about grammar, not syntax, contra Reason).


Maybe I just don't have enough experience, but I use classes in Javascript and TypeScript, as well as constructors, and they look virtually identical to me. What am I missing here?


TypeScript extends the syntax to support type annotations; it's not trying to fundamentally fix JS syntax.


Now enforcing type safety isn't a fundamental part of a language? I get the impression that you'd dismiss Rust as "basically C".

    ¯\_(ツ)_/¯


It is, that's the point. Reason is, as was said upthread, a "veneer". It changes the syntax only, nothing else is different (you can convert back and forth between the syntaxes losslessly). TypeScript makes deep changes to the language by adding type safety.


I have no idea how you got that from my post. I don’t know whether type safety is “a fundamental part of a language” or not, but that’s irrelevant to my point. TS extends the JS syntax to support type safety. Reason changes OCaml’s syntax altogether because it’s broken. Big difference.


Dangling else comes to mind.


Does Not look dead to me. last activity is within the last 30 days or so.

https://github.com/jashkenas/coffeescript/

Its not as popular to be certain, though.


I bet Fortran and Cobol are getting more jobs offers than CoffeeScript.


Whereby you seem to be making the case for "dead" languages.


Except Fortran and Cobol are pretty much alive, with ISO still releasing languages updates, recently LLVM got a Fortran compiler, supported by the likes of ARM and NVidia.

They are just "dead" in that they are specialized programming languages with a domain of their own, that magpie developers don't find attractive to put on their CV.

CoffeeScript in 2020 is just legacy code that one wants to get rid of, because some juniors found it cool to smuggle into the IT infrastructure.


Based on what data is that true exactly?

Opinions are fine, I don’t like CoffeeScript and never have.

It’s no justification to shame someone’s choices when perfectly well working code is usable via what appears to me to be a healthily maintained tool. Less popular? Sure. Would I reach for it to start a new project? no.

Calling it dead though and saying it’s only around because it’s “legacy” and only was used by “cool IT juniors” is shaming a legitimate choice without giving any context or data to back up the assertions


If it works properly there isn't another layer to debug (and anyway, one has to debug OCaml's syntax as it is, so it's more like trading one debug layer for another). I've never had to debug into assembly before, for example. And while syntax is normally just superficial, OCaml goes out of its way to be obscure and I don't have time for that. Especially with all of its other warts (stdlib issues, crappy package management, crappy build tooling, still no multithreading, etc). I eventually just gave up. Which is too bad because the type system (absent the OO stuff) could be useful.


I disagree, code is for and by humans. There are likely very real runtime consequences to having code that is "ugly", because the next human to touch it will value it less and do a suboptimal job.

Of course all of this is highly subjective, but my understanding is that it's important to consider if you want highly successful projects.


> code is for and by humans

I think this is very much domain dependent. Generally the more important efficiency is, the less I find this to be true. And really, code is always for the machine at the end of the day.

Additionally, if an added code layer makes the code more difficult to debug, that's also making the code worse for humans. Note I'm not arguing for or against whether that's happening in the case of OCaml/ReasonML, just making the point.


> code is always for the machine at the end of the day

On the other hand, code is read much more than it is written.

You may also regard efficiency as a necessary evil if the cost is readability.

Ultimately the winning strategy in this regard is achieving "free abstraction", making code that is both readable and efficient. Different languages aim at this. C++ has been best at this for most of history. Haskell and Rust are competing at this now as well.

OCaml isn't exactly efficient because of free abstraction, but because of its extremely simple translation strategies. OCaml's "flambda" compiler extension wasn't released as stable until 4.03 (2016), which means that before that, very little high-level transformation was happening.

My experience is that OCaml programmers care about low-level optimization, for good and for bad.

For example, in this StackOverflow response there are two examples of a function 'partialsums':

https://stackoverflow.com/questions/37694313/make-ocaml-func...

The one that Jeffrey Scofield provides is essentially more efficient because the accumulated value is a list, just like the end result, whereas my solution accumulates a tuple, which means every iteration of the fold involves boxing and unboxing that tuple. An optimizing compiler working at a higher level of abstraction might figure that out and re-use the memory of the tuple, but no sir.


ML syntax is fine.


You could say the same thing about Erlang and Elixir.

Or Java and Kotlin / Scala.

Depending on how well an alternative syntax is requested and adopted by the existing ecosystem surrounding the particular VM, YMMV. Without knowing, I think you get quite different answers in each case.


I not only could, I say so.

Focus on platform languages and you always win long term.


Jordan Walke, the creator of Reason (also the creator of React) said that syntax is unfortunately very important, because psychologically people want something familiar. I think syntax is totally superficial, but I’m also a human who interacts with other humans. And they do not think it’s superficial.

The talk where he says this: https://youtu.be/5fG_lyNuEAw


Because people who know other programming languages, but not ML, might want to read your code, and it's nice if it looks familiar to them.


That is how languages like Go get designed, pour souls not able to spend some time learning.


I wish Go had been a reskin of OCaml.


That is nowhere near their goals.

Maybe if Go didn't start as a hobby project inside Google, then they /might/ even have seen some opportunity in Ocaml / Standard ML, but now that Go exists, and has a quite good toolchain, the incentive is low. Go and its foundations are radically different from a FP language like OCaml though.


Programming is expressing programmer intent to the greatest extent possible given technological constraints. Sometimes, that's moving from machine code to assembly language[1]; sometimes, that's building a declarative language to express some specific logic. Finding new ways to preserve programmer intent in machine-checkable ways (that is, not just by adding comments) is one of the consistent goals of programming language design.

[1] Yes, humans used to write machine code. By hand. Computers were for serious work, not mere clerical tasks such as translating mnemonic order codes to binary and doing address arithmetic.


Programming is delivering a solution that solves someone needs, typing +. or + makes zero difference solving their needs.


Neither one is more real than the other and you really shouldn't need to do any debugging unless there are bugs in the ReasonML parser (and you could just as easily run into a bug with the Ocaml parser, but I suspect both are very unlikely).


reason isn't another layer, it's an alternate syntax. it doesn't compile via translation to ocaml code; both reason syntax and ocaml syntax compile to the same thing.


The "real deal" here is Ocaml. It's not the most complex syntax in existence, but I'd say it's easily the most complex ML language in existence.


There is no layer above, it’s not like coffeescript which compiles to another language. It’s literally an alternative syntax.


Sure it does, unless there is a ReasonML native compiler with its own ecosystem now.


> Programing isn't poetry.

First time I've heard a C-like syntax described as "poetic".


True.

But the accumulation of @-signs, for example, seems to be a bit much.


> ReasonML seems to be just sugar coating for those with aversion to ML classical syntax.

So it's the Elixir to Ocaml's Erlang?


Elixir is a different language for the Erlang VM, but Reason is just a different syntax for the OCaml language. There's a 1:1 correspondence between their ASTs, and even a tool to convert between them.


That's one of the main ideas, certainly. The thesis is that there are a ton of people who would take one look at the ML syntax and go back to their Java/C#/JavaScript, not realizing there's more to it. But with Reason syntax (which btw was designed by the creator of Merlin), they would take another deeper look.

For people like you and me, we like the ML syntax and don't have too much need for a new one. But for many others, this may be the only way they will ever even decide to look at an ML. And hey–if after that they decide that they actually like the ML syntax better–well that's one of the 'secret' goals of Reason.


ReasonML is adversely affected by it's Ocaml base if anything. StandardML would have been a much better base (they went with Ocaml because it was a lower-effort to implement and Facebook has a lot of Ocaml devs).

The first bad part is that Ocaml does not have a language spec. The implementation is the spec. This puts them at the whim of the Ocaml devs with no other options. SML is a standard with several good implementations.

Ocaml requires different operators for float and integer arithmetic. SML assumes an integer type unless you include a decimal. Both need to be replaced with module typeclasses (and both are working in that direction). For SML though, your existing code can continue to just work as it did before while Ocaml will be left with lots of `+.` or `*.` operators everywhere.

Another mistake that bleeds through is mutable strings. This is an outgrowth of all arrays being mutable. Immutable strings allow efficient representation as ropes instead of normal arrays (along with other optimizations that are good for GC'd languages). SML has immutable strings and vectors along with arrays (which you can still use as mutable strings of characters if you need them).

For their React-like goal though, Ocaml's lack of anonymous record types is the absolute worst. In SML, I can just type up a record and pass it in (no type definitions required). When passing in stuff to a component, you have to have all these named arguments. In SML, I'd just pass an anonymous record and destructure it in the function -- Just like in Javascript, but with types behind the scenes to keep everything straight.

Writing a custom parser for Babel like typescript or coffeescript have done would have been better for the language design and independence.


Well there is a language spec [1], it's just designed by the same people who develop the compiler. While there's only 1 de facto implementation (same as Rust, Go, etc.) there's multiple backends and lots of research work happens in different forks of the language. There's usually quite a bit of discussion and work that occurs between proposing a feature and integrating it into the language. There's also various competing forces here such as INRIA, Jane Street, OCamllabs, Reason developers, & other typical OCaml developers each with their own agenda. It's not so simple as the devs just adding something without any input.

>For their React-like goal though, Ocaml's lack of anonymous record types is the absolute worst.

The object system actually allows this to be fair & it does get a little bit of use in some Reason libraries targeting React developers

I get that SML has advantages over OCaml but I don't really get what you're trying to argue for. Clearly if you like SML you'd prefer OCaml to JavaScript...

[1] https://caml.inria.fr/pub/docs/manual-ocaml/language.html


> Another mistake that bleeds through is mutable strings.

OCaml strings are immutable by default since OCaml 4.06.


FYI strings are now immutable in OCaml. It was a compiler option starting with 4.02 and it has become enabled by default since 4.06.


That's nice to know. On the flip side, that's not nice for interaction between older code that wants to mutate and newer code that wants to "copy". If the "copy" code is actually copying all the time behind the scenes (something it has to do if you are compiling with mutable strings for backward compatibility with the rest of your codebase), that's a huge performance hit.


I am confused by this article. It went an entirely different direction based on the question proposed. It was all entertaining, nonetheless, but besides some passing comments to Reason’s documentation being better, the question does not seem to be explored much by this article. It’s a good article and should be renamed to maybe “Getting started with OCaml and OpenGL”


You're absolutely right. I wanted to justify my exploration by way of comparison between ReasonML and Ocaml.

The title ("Programming A Space Invader In OCaml and OpenGL: Lessons Learned") still fits with the content, don't you think?


I see that now, yes I do. I think maybe the headings and subheadings are also throwing me off as well. I wasn't sure if I was reading one of those types of blogs that have a continuous feed of articles on one page.


Marmelab makes the pretty awesome react-admin library for autogenerating admin interfaces:

https://github.com/marmelab/react-admin

I'd love to see an official Marmelab adapter so I can build my admin interfaces with ReasonML.


We already have hard time migrating it to TypeScript :p How such an adapter might work?


> I choose a more undisclosed tool (obuild) because of its simplicity and its brief documentation

> And although some tools exist to make our life easier, they are poorly documented

Seems like author choose something poorly documented. Dune build system [1], opam [2] and esy [3] package managers are very well documented.

[1] https://dune.readthedocs.io/en/stable/

[2] https://opam.ocaml.org/doc/

[3] https://esy.sh/docs/en/what-why.html


This article title and conclusions are misleading. It shows how to write a simple game in OCaml and then proceeds to conclude that ReasonML is better. I would expect the author to have the same game implemented in ReasonML for comparison to show us why. Otherwise, it is not very convincing.


We've changed the title to that of the article, as the site guidelines ask (https://news.ycombinator.com/newsguidelines.html).

Submitted title was "Is ReasonML good by itself or the underlying OCaml the source of awesomeness?"


having done some OCaml and F#, where F#’s syntax is more like reason, i think it is pretty clear that OCaml is a fascinating language but what does impose some weird syntactic work that both reason and f# relieve you of. probably to someone sufficiently used to ocaml it doesn’t matter but it can hurt adoption


I don't see how you can say F#'s syntax is more like Reason. OCaml and F# have nearly identical syntax for the core language, with the few differences being:

1) places features diverged

2) modules

3) F#'s "light" syntax mode

None of these really seem like Reason at all. Do you have any specific places where they're similar?


I always thought ReasonML was just a more JavaScript-ish syntax on top of OCaml, not necessarily better but just different. In what ways is it an actual improvement?


    dnf install ocaml ocaml-lablgl-devel
?

Anyway here's a toy game I wrote in GL + ODE + OCaml years ago: https://github.com/fccm/OCamlODE/blob/master/examples/katama...


Interesting but why talking at the end about F#, Scala and not Haskell (general-purpose, statically typed, purely functional programming language with type inference and lazy evaluation) wish is more old and mature than OCaml and F#: - Haskell: 1990 - F#: 2005 - Scala: 2004


Between reasonml and elm which one should I pick?


If you've not used an ML before, start with Elm.

Once you feel you have that sussed - it shouldn't take too long - pull up ReasonML and give it a go. Use the Bucklscript-Tea library - the architecture will be familiar from Elm.

Then give Reason-React a go.

Once that itch has been scratched move on to PureScript for a whole new rabbit hole to fall down.


I mean I'm familiar with ml and haskell, I'm more interested in what's the best platform for building things. The language itself is only a part of the equation.


I believe Reason is more practical (easier FFI), but as for building things, at this point it's probably Typescript :-)

Reason still hasn't had its async story ironed out, and has poor support for Unicode[0]

[0] "ReasonML strings are encoded as UTF-8 and not compatible with JavaScript’s UTF-16 strings" (from https://2ality.com/2017/12/basic-types-reasonml.html)


> Reason still hasn't had its async story ironed out,

Reason's async story is pretty simple: use promises until the let-syntax (like generalized do-notation) lands, then use that.

> "ReasonML strings are encoded as UTF-8 and not compatible with JavaScript’s UTF-16 strings"

Unfortunately this is inaccurate, and you left out a significant detail from the article. Let's go point by point here:

- Reason strings are not encoded as UTF-8, in fact they aren't encoded at all.

- But, when targeting JavaScript using the BuckleScript compiler, strings can contain Unicode characters and use the JavaScript runtime's support for Unicode.

- This is not a short-term workaround, but the intended solution.


Elm is made for one thing - web apps. It does it well, but it's probably not the only language you would ever use.

ReasonML/Ocaml is a general language. You can use whatever framework and platform you like. There is an Elm framework for Elm like development, there is a React layer for coding against react. But you can also write server apps, command line apps, GTK etc..


If the goal is to learn something in the ML family, I'd start with Standard ML. Ullman wrote a great book on it.

If the goal is some kind of syntax on top of JavaScript, I have no opinion.


Does Purescript also come into the equation? :-)


Purescript isn't essentially for web (frontend)? In that case, it's like Elm


As far as I remember, Elm has a runtime that at the moment requires the browser api. Purescript just compiles to javascript. So you don’t have server-side Elm, but you do have server-side Purescript. Which probably makes it more like Reason than like Elm.

The main difference is, Elm is like a drastically simplified version of Haskell, while Purescript is essentially Haskell with benefits (row polymorphism).


>Even though it is known for its robustness and its large standard library

I thought the ocaml stdlib was relatively small though?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: