Accepting code from the community means accepting full responsibility for all time
Sometimes, we’ll reject a certain pull request from the community, not because it doesn’t meet our standards, or doesn’t do things properly. We’ll reject it because we don’t want to accept the responsibility for this.
This seems obvious, but I got a comment on my recent post saying:
If you e.g. say that you're willing to accept a new F# module within RavenDB that does scripted deploys and automation of various tasks, I bet people would jump in with enthusiasm.
I wouldn’t accept such a PR. Not because there is anything wrong with F#, or because it wouldn’t be valuable. I wouldn’t accept such a PR because none of the core team of RavenDB has great expertise in F#. Oh, we have a few guys that played with it, and would love to do some more. In fact, I’ve got a guy that is pushing hard for allowing RavenDB to run computations via F#. It is a pretty cool feature, and I’ll talk about that in detail in a future post.
But imagine the scenario outline in the comment. A F# module that does some automation, scripted deploys, etc in F#. We go over the code, we are happy with it, we have a need for this feature. And at that point, we would have to make sure that it is written in C#.
Why? What is wrong with F#?
Pretty much nothing, except that any piece of code we ship (yes, even pieces that were contributed) has support requirements. A 2 AM call for one of the support team on that component means that the person answering the phone need to: Figure out the problem, decide if this is a misuse / feature / bug, fix this by either suggesting work around or supplying a hot fix.
And if the component with the issue is written in F#, that means that you need to have all the support group (now just over 20 people) be able to understand and work with that. And to the nitpickers, yes, it doesn’t take a long while to learn a new language, but it takes a good long while before you can be effective with it, especially at 2AM. Now multiple that by 20+ people, and you might see where we are starting to have an issue.
There is also the community angle to consider, code that is written in a language more people know gets more contributors.
Now, I’ve actually have run an real live study on that. In 2005 I wrote a view engine for MonoRail (MVC framework for ASP.Net) written in Boo. (You can read all about that here). Naturally, building a DSL that is based on Boo, I wrote that in Boo. And it was mildly successful. It was a pure OSS project, with multiple contributors. And I was the sole person that would actually modify the Boo code. Boo code looks pretty much like Python, and there isn’t any FP aspect to it. I find it imminently approachable and easy to work with.
The Brail codebase had pretty much zero outside contributions. At that point, I ported the Brail codebase to C#, the post is from 2006. Note the discussion around the reasoning. After that happened, we started getting more outside contributors and people were actually willing to take a look at the code.
For fun, this is actually in a situation where anyone using Brail was actually writing Boo code. It isn’t like they weren’t aware of how it worked. They pretty much had to, because Brail was a very thin DSL over Boo code. But moving the codebase to C# significantly improved the level of involvement.
Something that I think people miss is the fact that this kind of decision has pretty much nothing to do with the language or its merits. It is all about the implications on the project as a whole.
Comments
This is the right decision. sometimes I get the feeling that people are trying to push technologies only because its "cool", and not because this is the right tool to solve the problem.
Take as an example nodejs, why would you want javascript code on the server side? what is it good for? Don't get me wrong, F# is a great language to solve functional programming problems. if I want to solve a Sudoku for instance, yes F# is suitable for this kind of problems. but for a DB ? there are so many optimizations, low level coding, memory management and other bits and bytes you simply don't have the flexibility in F#
Thank you for writing a much more logical argument for reasons to stick with C#, compared to your last post. Indeed, making sure that the product is supportable by a reasonable amount of people is important and this is a good example of pragmatic decision making.
With the nature of the technology landscape changing it's also worth thinking about where the tipping point is for your team; might there be a time when there's significant gains to be had by incorporating a new community (similar to moving from Brail to C#)? How do you quantify the benefit a technology would bring vs. the notional cost of training?
Though I am a big fan of F#, having delivered several complex products using it, I don't think it's a logical choice for your RavenDB product. This is mainly because it's designed for safety and clarity of modelling, rather than for low-level performance optimisations. You're building infrastructure, not business logic, and therefore a language which give a more transparent mapping to IL is probably of higher value than one which makes modelling business cases easier.
Funny that this kind of problem is the problem open source Erlang projects struggle with, but Erlang is not just a language it's a platform plus runtime, and the learning courve and effort is worthwhile for certain types of projects.
F# is a language on top of .Net therefore only a flavor. Yes F# is cool, I've used it and I can see why people would be hyped about it, however it's still a language that is targeted at computational domains and not large componentized applications. Once you start working with components, interfaces, databinding, events and mutability (all common in large applications) F# starts to feel strange and a bit out of place. I perrsonally woudn't write a large sytem in F#, yet it might be a great choice for certain specific computational domains of said large programs.
Side note: Boo is a little programming gem that was too advanced for it's time unfortunatelly, it's a language that has metaprogramming features we will see in mainstream languages in 5 or 10 years from now (with a big maybe).
Thanks for that voice of sanity. Any new language/framework addition means a lot of new maintenance work. I wish everybody understand that!
Do you impose similar limits on language features? For example, would you disallow LINQ if not enough people on your support team understood it?
Ben, Linq usage was a slow process for us. And we still look at that with suspicion in certain places. Not for complexity, for performance (you see the same in Roslyn codebase, frex).
But there is a difference in expectations between langs and in a lang. I expect all my support personnel to have a good grasp of all language features, or the ability to figure them out fast if they are very new.
Comment preview