According to Wikipedia[1], SQLightning -- a port of Sqlite using LMDB -- was 20x faster than original sqllight. It could thus be interesting to compare LiteTree with SQLightning.

[1] https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...

Indeed. But the last version of SQLightning is using SQLite 3.7. It would be useful to have an updated version. I was going to update it but then I decided to implement LiteTree in another way, using pages instead of rows. This is because our customers at Blocko/Aergo prefer higher performance over small storage.

Shameless plug: ocaml-vdom[1] is another implementation of TEA in OCaml (with js_of_ocaml)

[1]: https://github.com/LexiFi/ocaml-vdom

Well, OCaml is indeed rather popular for implementing compilers for new languages (sometimes later bootstrapped), including ones which became rather popular. I can think of F#, Rust, Elm, Haxe, FlowType for instance.

Was Elm originally implemented in OCaml? I thought it was Haskell.

Another two relatively popular languages implemented in Haskell are Idris and Agda.

They might have meant ReasonML, both it and Elm interop w/ JS

https://github.com/facebook/reason

I could have added reasonml to the list indeed, but reasonml really is (a different syntax for) ocaml.

Elm is still implemented in Haskell. Self-hosting isn't a goal.

Yes sorry, Elm is indeed implemented in Haskell.

There's also a project for implementing a prolog like interpreter for doing type checking and other logic for Rust, I think it works on the MIR level, but could be wrong on that.

What's the value of the bitcoin network itself (its computing power?), and how does the holding of bitcoins give any right on this value?

That's like asking, "what's the value of TCP/IP?"

Well, the value isn't really TCP/IP, it's the network (i.e. the internet).

Bitcoin isn't the valuable bit. It's the network of millions of nodes that has value.

Value is subjective. But you could say that the Bitcoin network has a price: the sum of the price of the miner hardware and electricity usage.

Yes, well, I can imagine that under the assumption that people loose "faith" in Bitcoin, it's still possible to assign a "value" to the Bitcoin network, e.g. the hardware that makes it (miners and nodes) -- I wouldn't count the electricity usage as part of its value, though. But the point is that holding units of Bitcoin, i.e. knowing the secrets that allow spending them, does not give any rights on those hardware assets, so the value of the network cannot provide a lower bound to the value of Bitcoin units, in the same way that industrial or jewelry usages of gold does give it a lower valuation bound.

Many files are taken from the OCaml compiler and then adapted, but changes seems a bit deeper than just a different syntax. It would indeed seem fair for the authors to at least make it clear in the toplevel README that the front-end (parsetree representation and type-checking) is indeed / started as a fork of the OCaml code base.

Considering ongoing efforts to create a WebAssembly backend for OCaml (and thus Reason), I wonder what would be the selling point of Grain.

Even syntactically, this looks a lot like if you took ReasonML, disallowed type annotations, did away with its ecosystem, and compiled to WebAssembly.

Aside from the wasm compilation, I don't see why this exists.

That was my question only having recently started looking into ReasonML seriously. Sounds like I'll just stick to Reason!

> Many files are taken from the OCaml compiler and then adapted [...]

I went back and checked, and Grain not only takes OCaml's code without clear attribution but redistributes that code under GPLv3 where the original code is under LGPLv2.1. That's bad.

Of course it feels less native than with F#, but we have created and used CSML (https://github.com/LexiFi/csml) specifically to allow our OCaml code base to interact with .NET.

I don't think so. Both bytecode and native evaluate right-to-left.

I swear that I remember having programs that could behave differently in the bytecode and native compiler. Perhaps I'm remembering an older version of the compiler or another order-of-evaluation issue other than function parameters?

Here is an obviously incomplete list: http://ocaml.org/learn/companies.html

OCaml now uses Github as its official repo and accepts PRs.

I guess Bucklescript aims at a smoother integration with the JS ecosystem, which means binding to existing frameworks rather than creating new ones (such as tyxml or Eliom). These are different approaches which make sense for different target audiences.

That said, it is also quite easy to bind to the JS world with js_of_ocaml and nothing forces you to rely on tyxml or Eliom. You can use either the FFI which comes with js_of_ocaml, or gen_js_api ( https://github.com/LexiFi/gen_js_api ) which we have created to abstract OCaml/JS bindings from the underlying OCaml->JS compilation technology (we hope that Buckescript will support gen_js_api). The web client-side frontend of my company is using exclusively gen_js_api + the js_of_ocaml compiler (but not its FFI nor its standard library), which should make it straightforward to port to Buckescript at some point if the need arise.