On Why RavenDB Is Written in C#
On Why RavenDB Is Written in C#
Should databases like RavenDB be written in C#? Read on for a continuing debate about just that.
Join the DZone community and get the full member experience.Join For Free
Read the 2019 State of Database DevOps Report for the very latest insights
Greg Young has an interesting reply to my post here. I'm going to reply to it here.
RavenDB nor EventStore should be written in C#.
That may be true for the EventStore, but it isn't true for RavenDB. Being able to work with the .NET framework makes a lot of things a lot simpler. Let us take a simple example: every day, I have to clear the unused auto indexes, but only if there has been queries to the collection in question. In C#, here is the code to give me the last query time for all collections in the database:
Now, if we wanted to do this in C, as the go-to example for system level programming, I would need to select which hash function to use. RavenDB being a non-trivial project, I'll probably have one, for simplicity's sake. I selected this one, which gives us the following:
I've excluded all error handling code, and I've introduced a silent potential "use after free" memory issue.
This is something that runs once a day, but the amount of code, effort and potential things to manage is quite a lot, compared to the simplicity we get in C#.
Now, this is somewhat of a straw man's argument — the code would be much simpler in C++ or in Go (no idea about Rust, I’m afraid) — but it demonstrates the disparity between the two options.
But Greg isn't actually talking about code.
A different environment such as C/C++/Go/Rust would be far superior to haven been written in C#. Cross compiling C# is a pain in the ass to say the least whether we talk about supporting linux via mono or .netcore, both are very immature solutions compared to the alternatives. The amount of time saved by writing C# code is lost on the debugging of issues and having unusual viewpoints of them. The amount of time saved by writing in C# is completely lost from an operational perspective of having something that is not-so-standard. We have not yet talked about the amount of time spent in dealing with things like packaging for 5+ package managers and making things idiomatic for varying distributions.
I have one statement in response to this. Mono sucks.
I suspect that a lot of Greg's pain has been involved directly with Mono. And while I have some frustrations with .NET Core, I don't agree with lumping it together with Mono. And Greg's very market was primarily Linux admins. While I would love to that be a major market for us, we see a lot more usage in Windows and Enterprise shops. The rules seem to be simpler there. I can deploy the .NET Core along with my application, no separate install necessary, so that makes it easier. What we have found customers want is Docker instances so they can just throw RavenDB up there and be happy.
A lot of the pain Greg has experienced isn't relevant any longer.
What is more, he keeps considering just the core product. There are quite a lot of additional things that need to happen to take a project to a product. Some of this is external (documentation, for example) and some of this is internal (high-level of management studio, good monitoring and debugging, etc). I have seen what "system level guys" typically consider sufficient unto itself in those regards. Thank you, but no.
A lot of our time is actually invested in making sure the whole thing is better, spreading oil over the machinery, and the more lightweight and easy we can make it, the better.
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.