[baq]

on one hand, it's very cool to see such projects.

on the other hand, writing anything that's supposed to reliably store data in C in 2018 raises eyebrows.

[jnurmine]

But but but... every day, many people use implementations written in C to reliably store data. Just look at, say, Linux. The drivers, filesystems and networking stack are all written in C (and maybe some assembler). And once the data reaches the firmware controllers of the mass storage device... Well, the firmware is done in C or assembler.

It is not like implementing a rather thin layer for reliable data storage on the userspace in language x somehow invalidates the contribution of the C language, which the underlying system, all the way from the OS to the device firmware is likely written with.

That said, I do understand the arguments of e.g. Rust being superior in preventing memory bugs, and so on, but whatever gets implemented on the userspace is simply not the whole story regarding reliable data storage. Without system services no data will get replicated, distributed, stored and so on...

[CamperBob2]

If you intend to export the API to the widest possible variety of other languages, C is a good way to go for the initial implementation. The lack of a universally accepted, language-independent "Rosetta stone" ABI means that this is the one job that C still does better than anything else.

Nothing wrong with writing targeted, specialized components in C. It can be done properly, it just frequently isn't.

[vortico]

It's a tradeoff between adoptability, readability, portability, ease of embedding, average familiarity of toolsets, ABI managability, and strictness of rules to access arrays and references in the implementation. C likely wins in all of the above except the last, with C++ in second place, and virtually the only other options are Rust and Go, which only wins in the last point.