Not all key-value stores are the same, take a more in-depth look at FoundationDB to see why so many people are excited about adding it to their infrastructure.
I just looked at Arakoon, itâs unmaintained, and even if it was still under development, the underlying store (tokyocabinet) is unmaintained because I used it at a previous job a very long time ago and we had to migrate away from it.
HTTP/2 is a big missing piece to OCaml to enable certain libraries like gRPC.
Iâve been thinking also that there should be a GCP library, Iâd be happy to start working on one, despite the fact that itâd be my first OCaml program (outside of school)
HTTP/2 support would be definitely nice to have. Iâm not very familiar with the new protocol internals, and iâve only been using OCaml for a relatively short amount of time, but iâd be happy to contribute towards an effort to work towards this.
That being said, in my opinion what will help is an effort to split a single task of âImplement HTTP/2â into smaller more managable items. So far I can think about the following points as a start:
- Define the types (error types, settings, frame etc)
- Serializing/Deserialized the binary codec (Angstrom/Faraday might help here? )
- HPACK
HTTP/2 support is really a painfully missing piece indeed, and grpc too. And itâs a big chunk of work.
That being said, if you just need to send http/2 requests you can just use curl.
Server side is more problematic though. Iâve been willing to try binding another language server with lwt, but that seems hard to do.
If it is production ready, ships with Debian and was used heavily in production in several places, it means tokyocabinetâs code base is stable and mature.
I do not care so much if it is unmaintained: this is open source in C.
Many people can have a look at it and change something if needed.
We migrated away because we had problems with tokyocabinet at scale and we lost data. That was a long time ago, but I donât think the issues were fixed since the author started working on kyotocabinet as a replacement when we abandoned it.
Again, not all key value are the same. TokyoCabinet isan old read-optimized btree based keyvalue engine. I donât know about FoundationDB internals, but you might want write optimized LSM based db for your use-case.
More importantly it does not look like a good idea to rely on dead unmaintained technology with no commit in the past few years to store your data while you can just use techs everyone else is using and debugging like rocksdb based distributed kv store or foundationdb
I agree. One step towards this is that we would need to track all these points. Perhaps a wiki post on this Discourse or on OCamlverse (cc: @bluddy)?
For instance, Iâm currently working on implementing ALPN support which is required for negotiating http2 protocol over TLS on both ocaml-ssl and ocaml-tls. After (and if) this is merged, the next step is changing ocaml-conduit to take advantage of this, which in turn will enable cohttp servers and clients to negotiate âh2â protocol via TLS. Iâm not sure about httpaf as it doesnât seem to use these libraries.
But as has been said, this is unfortunately still a tiny piece of what enables HTTP/2, hopefully other efforts can be done in parallel.
(Btw this thread is getting a bit off-topic from Rust and deeper into missing OCaml libraries, I believe moderators can fork posts to a new topic, e.g. HTTP/2 supportâor merge with this one?)
We definitely should change threads. Feel free to start one on HTTP/2 support. Also, feel free to add to the missing pieces on ocamlverse detailing progress and links with regard to getting http2 going. Once a section on this page gets too limiting, we can branch it off to another page.
Let me just say that I think itâs hugely in the communityâs interest to switch to httpaf rather than keep using cohttp. cohttp is just not optimized enough at a low level to serve as the foundation for OCamlâs web services, while httpaf is designed from the ground up for performance.
âArakoon is unmaintainedâ. Are you sure youâre looking at the correct repo?
There were some nasty bugs in tokyo-cabinet that were fixed, and these fixes have been incorporated in Arakoon.
Fwiw, the powers that be forced the creation of a private arakoon-ee repo, that replaced tc with rocksdb (complete with upgrade from tc to rocksdb). So itâs not unmaintained, itâs just that most of the current effort goes into the ee version.
Interesting discussion related to this thread: https://www.reddit.com/r/rust/comments/abm6hy/why_rust_is_successful_compared_with/
Ocaml will always be perferred over the Rust as It Encourages functional style
It steers you towards a functional style, but doesnât bother you with purity and âmonads everywhereâ like other languages, such as Haskell and OPAM is a package manager for OCaml, which is really easy to use, just like npm. It creates a .opam folder in home directory.
The documentation is great as well, and you can switch between multiple versions of OCaml for each project. You can also package your project and publish it on OPAM repositories, even if the dependencies do not exists on OPAM.
Regards,
Adrian Gates
Admin - CloudDesktopOnline
OCaml can serialize/deserialize things to/from disk.
Thanks to the Marshal module from the stdlib; no need for an external library.
I donât know if Rust can do that (I mean, without people having to write by hand serializing/deserializing code).
If not, then that would be one more advantage for OCaml over Rust (and thatâs definitely one for OCaml over Python).
I have not used it myself but I heard that https://serde.rs/ for Rust is very good for that.
Rust ad-hoc polymorphism and macros make it likely better than OCaml for that specific problem.
Note that in practice Marshal
is not a very good tool to rely on except in very limited cases: 1) Itâs not type safe, read backs can make your program segfault 2) The data format depends on the compiler version.
The reason I favor OCaml over Rust is simple succintness .
OCaml is a small language, once you have a grasp of the functional way writing OCaml code is simple.
Rust on the other hand is more complex (arc,box, borrowshipâŚ) all these things are great for low level code but they make the language harder to use, I think the reason Rust is successful is mostly an ecosystem reason and a matter of hype cycles.
I am a fan of small languages such as Lisp, Golang , C, OCaml .
Thatâs clearly wrong. Rust does things no other language does, like providing fully safe concurrent programming. Rust also has a system for ad hoc polymorphism, which OCaml really needs. Donât underestimate Rust. OCaml is nicer in many ways, less nice in others.
To alleviate the heat of the discussion - there is also an interesting emerging language, based on the experience of Rust and C++. While Rust is an awesome language, and I enjoy writing it, it still pretty hard to learn due to many different concepts and complexity. Zig language addressing a lot of C/C++ problems, while keeping things simple. I recommend to check it out, even if it didnât reach 1.0 version yet.
Given that you need to manually manage memory in Zig Iâve not been able to understand what itâs major selling point is. Sure it may have nice clean syntax and compile time evaluation but is that reason enough?