Monthly Archives: June 2016

Rob,Ayende. .NET

In regard to:

While I find most of Ayende’s┬áposts to be well reasoned, I feel we may end up agreeing to disagree here. I understand completely your argument that good software can be written on the .NET platform. I understand as well that you can build things like RavenDB on the .NET platform including CoreCLR. Myself and our team have also built such software.

Your conclusions however are absolutely wrong. We have been supporting a linux operations story for coming up on four years. We actually prefer to run in linux as opposed to windows (though we are written in C#). This is due to many reasons but the largest is the quality of operations people and the maturity of devops tools on the linux side.

We have experienced where your logic falls apart.

RavenDB nor EventStore should be written in C#.

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.

Maybe you think you will avoid this and include instructions for how to install ravendb for *x* distribution. They want packages. They want things they understand. Most linux admins will flat out refuse to install coreclr (rightly as it is immature) or mono (rightly as its a shitshow)

The costs associated with this are prohibitive. At the end of the day the kinds of code you discuss could likely be implemented by mediocre C/Go developers but you need to hire the very top of the line C# developers. Finding a C developer that understands the concept of a B+tree is far easier than a C# developer. Finding a C developer who has some clue about how memory works and is able to optimize is normal.

When you get into looking at TCO the amount of time spent dicking around optimizing GC and understanding/supporting your underlying abstractions having written in C# becomes negligibly less expensive than writing in a systems programming language in the first place.

Once you start looking at support operations (trust me we have experience on this), having written in a systems programming language will be far cheaper.

TLDR: The fact that you write systems code in C# (or Java!) does not refute Rob. You are in fact writing systems code in C# in spite of being in C#. This is the biggest mistake we have associated to event store, you should recognize the same, we keep things running but recognize that we would have been better off with other decisions. Given our investment we can not easily change but given a chance to start from scratch would make different ones.

Rob,Ayende,.NET

In regard to: https://ayende.com/blog/174433/re-why-you-cant-be-a-good-net-developer which is in regard to http://codeofrob.com/entries/why-you-cant-be-a-good-.net-developer.html

Ayende,

While I find most of your posts to be well reasoned, I feel we may end up agreeing to disagree here. I understand completely your argument that good software can be written on the .NET platform. I understand as well that you can build things like RavenDB on the .NET platform including CoreCLR. Myself and our team have also built such software.

Your conclusions however are absolutely wrong. We have been supporting a linux operations story for coming up on four years. We actually prefer to run in linux as opposed to windows (though we are written in C#). This is due to many reasons but the largest is the quality of operations people and the maturity of devops tools on the linux side.

We have experienced where your logic falls apart.

RavenDB nor EventStore should be written in C#.

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.

Maybe you think you will avoid this and include instructions for how to install ravendb for *x* distribution. They want packages. They want things they understand. Most linux admins will flat out refuse to install coreclr (rightly as it is immature) or mono (rightly as its a shitshow)

The costs associated with this are prohibitive. At the end of the day the kinds of code you discuss could likely be implemented by mediocre C/Go developers but you need to hire the very top of the line C# developers. Finding a C developer that understands the concept of a B+tree is far easier than a C# developer. Finding a C developer who has some clue about how memory works and is able to optimize is normal.

When you get into looking at TCO the amount of time spent dicking around optimizing GC and understanding/supporting your underlying abstractions having written in C# becomes negligibly less expensive than writing in a systems programming language in the first place.

Once you start looking at support operations (trust me we have experience on this), having written in a systems programming language will be far cheaper.

TLDR: The fact that you write systems code in C# does not refute Rob. You are in fact writing systems code in C# in spite of being in C#. This is the biggest mistake we have associated to event store, you should recognize the same.