Why Bucklescript?

@OvermindDL1 You’re doing great as an evangelist, did you know that? :slight_smile: I’m hooked; installing OCaml and OPAM right now. Will probably try out Bucklescript later.


I hate JS and all it’s “cannot blabla undefined”, but the next thing I’ll look after fpr myself will be OCaml and bucklescript for sure, right after mastering more Elixir. You’re great at evangelization, I have to agree to that :slight_smile:


I like it more after watching some of these:

Hong Zhang seems like a capable and knowledgeable person too :023:

1 Like

It’s not clear to me if you’ve uploaded this somewhere for actual usage or if it’s a one-off. Could you clarify and/or perhaps set up instructions/example projects for 1/2/3 step setup so that one can move straight to using it?

1 Like

Heh, Bucklescript I can see as having staying power, I never saw that with Elm. With Bucklescript people can take the existing substantial OCaml knowledge, libraries, and power, and use it on the front-end.

Yeah the stuff I put is scattered all over, should really put it in a single location…

Lol, probably good, and done I see. ^.^

OCaml is definitely well worth learning even just on its own, fantastic for making native programs that you know will ‘just work’ in addition to learning it will help you in languages elsewhere do to the functional programming it teaches.

I still really badly want an OCaml->Elixir transpiler, that would fix the last bits of annoyances I’d have with Elixir (once my code was ported over). ^.^

Ooo, things to watch! Yep he knows his stuff. He’s been a long time OCaml dev, on the OCaml compiler, lots of projects that used the compiler, etc… He knows his stuff!

Right now it is just in my little bucklescript-testing project on github, you can copy/paste the relevant files into your own project if you want to play with it right now, but I plan to do an actual npm-release with it once Bucklescripts new compiler infrastructure is finished (and I update my bucklescript-brunch module to use it, which is optional for usage but convenient for phoenix-brunch users ^.^). But that is why I do not even have a readme file yet, not wanting to give the impression it is ‘done’, even though it is basically is as it is. I still want to clean up the code as well before release, it has a lot of experimentation in it. :slight_smile:


So whats about a PPX that translates OCaml to Elixir?

This makes it possible to write code in one simple language that compiles into the ErlangVM, native OCaml and Bucklescript JS.

Plus, this idea combines Elixir and Erlang with the strong type checking of OCaml.

OCaml, Reason, Elixir, Erlang and Javascript in one language.

1 Like

Here is, by the way, a full list of differences between Reason and OCaml, pointing out some things which are unnamed in this thread until: https://reasonml.github.io/guide/ocaml/


I’ve considered precisely that, even started a little project to experiment with it. :slight_smile:
In a crunch period at work currently though, so no time to mess with it lately. If someone else wants to do it, please do. ^.^

Precisely my thoughts!!

Oh that would be such bliss… Getting closer to the perfect language for web work…

I have no coding experience and i am still looking after my first language. :wink: [quote=“OvermindDL1, post:19, topic:2319”]
Oh that would be such bliss… Getting closer to the perfect language for web work…

I think even more, since OCaml offers speed, where Elixir is sometimes to slow.

1 Like

If it compiles to elixir there’d be no difference then. ^.^

However making NIF’s and Ports both from OCaml is entirely doable too though, hmm, a unified language for it all, interesting thought…

1 Like

How does it make no difference, when it compiles to Elixir?

Because the bytecode is critical?

So, ErlangVM makes no performance loss?

That would be even more amazing since it combines the speed of OCaml with the concurrency of Elixir? ^-^

1 Like

As in if you compile from OCaml to Elixir then you get the BEAM’s speed regardless. :wink:

Yeah, i thought native OCaml is in much terms faster as BEAM?

1 Like

@OvermindDL1 I’m a bit curious, I see that you like Graphql, so… Did you use Graphql with bluckescript? If yes, how?

1 Like

Native compilation yes, it is faster than the BEAM on anything single-threaded, it is about on par with C in speed. But when you transpile it to execute on the BEAM instead, well it does not matter what assembly it generates since it is generating BEAM at that point. ^.^

Not used it with bucklescript yet, it exists on the layer ‘above’ in my project (it predates my Bucklescript work). I would like to make a GraphQL interface for buckelscript-tea sometime though. ^.^

1 Like

And how is that faster as native OCaml?

1 Like

It’s not, the BEAM is slower on single processing work, like math and such. However the BEAM will run circles around OCaml in terms of any kind of massive asynchronicity, like a web server ^.^.

But with OCaml you could get the best of both worlds, have some of it compile it the BEAM, and some of it compile to NIF’s. :slight_smile:

EDIT: For note, MC-OCaml (when it is finally merged into the mainline) will run circles around the BEAM in about every way possible, but in exchange for less reliability as the BEAM is fairly crashless, but there are ways to work around that too.

Yes, this is exactly what I mean. And how can we achieve this?
Is there any group/person we can hint about this idea?

How challanging is that? What exactly to do, step by step?

1 Like

To do what? Make an Elixir/Core backend for OCaml? Only thing that involves is just someone starting to write a PPX for OCaml that does it. :slight_smile:

Not too challenging overall, easier than a whole compiler for sure, but it necessitates knowing the OCaml compiler a bit (which is probably the easiest to read compiler out, so that is a boon).

1 Like

EDIT: For note, MC-OCaml (when it is finally merged into the mainline) will run
circles around the BEAM in about every way possible,

Every way possible is a bit strong isn’t it? :slight_smile: Unless they are
implementing a good pre-emptive scheduler I bet you the worst-case
latency is going to be worse in OCaml (as in almost every other language
having a non pre-emptive scheduler).

I’ve done some benchmarking comparing java, go and erlang and while java
and go are faster on average they also behave much worse under load
(especially java). Beam seems to give much more stable latency. I think
MC-OCaml will be the same.

Plus, who knows where the beam will be in 2027 when MC-OCaml finally is
released :slight_smile: