Why we chose the D Language and vibe.d

Our main language at Tripaneer is the D language. We also use python in areas related with Google Adwords and some data analysis, but the bulk of our software is written in D. A lot of people ask us why we chose it. That’s a good question! Here are the main reasons:

• Maintainability
• Development speed
• Performance
• Hiring friendly

Let me delve a bit deeper:

Maintainability and development speed

The D language is strongly typed and that, contrary to popular belief, helps our developers. With dynamically typed languages you are only sure the code path you tested is working nicely. This is fine for simple scripts, however, when the code complexity starts getting bigger it starts to become a maintenance nightmare.

Before the D language I used to work with Perl. Don’t get me wrong, Perl is a great language for quick and dirty scripts. It has a great community, a ton of modules, etc… however, when code complexity starts increasing, things start getting complicated to maintain. The same goes largely for all dynamically typed languages. Allow me to give an example of what I mean: the first time I had to do a refactor using D I was super impressed: I basically just had to solve all compiler errors and in the end, stuff was working 😮. This was a completely different experience for me. Normally I would test stuff a lot after my changes, pray a lot, put the code live and wait for it to blow up; rollback; fix the problem, and repeat the same process until it got great again™. Stressful! And users would be the ones having a terrible experience. This difficulty in maintenance also promotes reluctance to refactor as you add new features which further contribute to make code even harder to maintain.

Some people might argue that if you have a good test suite, this maintenance problem is largely mitigated. Well, sure, but do you have a great test suite? A well maintained up to date test suite? How much time are you taking to maintain that test suite? Well, if you are spending all that time maintaining the test suite for such a simple thing as to guarantee that the code doesn’t have obvious compilation errors, why don’t you use a tool that already does that for you? Typed languages take more time to develop in! Really? But on the other hand you need to maintain all that test suite and you’re never really sure if you are covering all possible cases. Something changes, ups, gotta update the tests.

This is not to say that we don’t test. We do. But not to the extreme level you need to test if you’re using a dynamically typed language.

Given all this, are the dynamically typed languages really more productive for complex projects? Remember, you will only spend around 20 to 30% of the time writing the code… the rest will go into maintenance. So, optimizing the writing phase feels like the wrong approach to me.

The right level of verbosity, compilation speed and flexibility

We wanted a strongly typed language for maintainability reasons but there are a lot of strongly typed languages out there. So why D? C++? Not flexible enough and big compilation times. Java? Hmm, too verbose. Go? Great compilation speeds but no support for templates.

D felt like the right compromise between verbosity, compilation speeds and flexibility. Wanna quickly filter all elements of an array greater than 4?

auto filtered = originalArray.filter!(a => a > 4).array();

This is just a simple example to illustrate a bit the power and flexibility D provides you. In terms of verbosity, compare that to Perl which is well known for its expressiveness and flexibility:

my @filtered = grep {$_ > 4} @originalArray;

Adding to this, D also compiles down to native machine code allowing for a runtime performance at the level of C++.

Hiring considerations

Another factor that plays in favor of D is the fact that it’s a C based language. This means that, although there are not a lot of D developers out there, any person with a background of Java, C#, C++… any C based language really, will pick up D very quickly. Add to that the fact that it’s a modern language and not that well known yet, and you get a great combination to tickle developers curiosity.

Vibe.d

Vibe.d is the biggest web framework for D. Like node.js it also uses Asynchronous I/O but contrary to node.js, this is transparent to the user. This prevents the old callback hell from node.js while allowing for easy debugging and keeping the top notch performance. It’s actually very similar to the new async/await but without the extra syntax boilerplate. You can check the advantages of Vibe.d here. It’s very well explained there.

Drawbacks

Of course, D is not a silver bullet and it also has it’s drawbacks:

• Small community: this translates in few modules and drivers available. This is probably the biggest limitation so far.
• Not a lot of development tools: unlike C++ or Java for example, which have tons and tons of dev tools available, D still lacks a lot of these. We found out a very nice setup though, using Visual Studio Code plus the code-d extension and it’s working very nicely for us.
• Not as flexible as dynamically typed languages: for a typed language, D is pretty flexible. But it’s not as flexible as Perl or Javascript for example. This was a bit annoying for me in the beginning, given my Perl background.
• Compilation times: D is known for its super fast compilation times but it still has to compile and if you start using a lot of compile time Regexes, for example, you will start seeing your compile times increasing. To minimize this we try to avoid compile time features as much as possible since we prefer faster compilation times to a faster runtime performance. I mean, non compile time regexes are already fast enough.

Conclusion

In general the D in combination with Vibe.d has been working very nicely for us. Like all the tools it has it’s drawbacks but all in all, we’re pretty satisfied.

Give it a go if you have the time. I think you will get positively surprised.