D vs Ruby
A while ago I posted an article describing my quest for the right language to develop one of my projects (a development platform in itself). The conclusion was indecisive as I could not make a definite choice at that point about which one I would choose between D and Ruby.
I know, I know many would jump on my back and say that I’m crazy for even considering a comparison with Ruby, but I don’t think so. In fact after a while I actually realized that D was better for me rather than Ruby1 .
I considered some aspects of both platforms when comparing although I detailed a bit more on D since I did not discuss it at all until now (I graded each one from 1 to 10 depending on how important it was to the project or how powerful it was in general):
D Programming Language:
- [10] SPEED: the D language is compiled and in some cases it even yields higher performances than C++. It is immensly faster than Ruby (it’s normal that a compiled language is faster than an interpreted one but the difference between these two is unnatural), amazingly hundreds of times faster, even when comparing with Ruby YARV(which is the newest and much better optimized Ruby interpreter). I think this is (more or less) as fast as one can get with a language that offers both architecture and high productivity.
- [7] ARCHITECTURE: D is very similar with Java in that it removes or alters many C++ concepts for practical productivity reasons (e.g. removing the need for .h files). These modifications allow a much easier approach in constructing high level, complex architectures. Plus it provides a few things that Ruby does not and which I think are necessary (e.g. interface classes - I know this can be done in Ruby but it’s such an ugly hack that I cannot even understand how ruby people in general accept it - in fact I don’t think they do).
- [7] PRODUCTIVITY: There are many aspects in D which make it very productive when compared with it’s predecessors (even with Java actually). For example strings (which are completely integrated in the language) are similar to those implemented by web-related platforms (like PHP); associative arrays are also present (an excellent functionality) and much more.
- [9] CONNECTIVITY TO C/C++ CODE: By creating a new language I need to create a scanner/parser, a compiler or interpreter and many other sub-systems that are essential for such an architecture, also many libraries which are very important to this project(and not only) are written in C/C++ (like FreeType or CairoGraphics) and thus I think that being able to access their code from mine is vital. Being much closer to C/C++ than an interpreted language D provides very good connectivity to code written in C or even compiled .dll/.so libraries. It does lack a bit because C++ connectivity is still very limited but transparency between codes is much better than that of RubyInline and ease of use is much better than that of Ruby extensions. Also in D, declarations can be exported to be accesible from C which is also very useful.
- [9] EXTENSIBILITY: What kind of support does one have when implementing extensibility support for a piece of software (like plugins or drivers). This is vital to modularize the entire project so that if a section is fixed/updated/upgraded/changed it is done independently of the entire system. The DDL project for D is a wonderful extension that enables one to create a dynamic plugin architecture for D. It is easy to use though you still have to compile your plugins (as pure D code on a specific OS) and it has the amazing advantage that the plugins themselves can be completely ignorant about the system (no extra work is required within the plugin itself to make this work). Also there are a few D projects which provide excellent implementations of scripted sub-languages like DMDScript (ECMAScript implementation), Walnut (open source ECMAScript implementation), MiniD (interpreted language running in D) [edited thanks to Jarrett Billingsley].
- [7] LICENSING FREEDOM: Being a development platform, I think it should be open source (mine will be) and this is where the D compiler provided by Walter Bright (DMD) falls short in my view (the back-end of the DMD compiler is proprietary). The day is saved, however, by the GDC project wich recently became a very viable alternative to DMD and it uses GCC as a backend (before DMD 1.0, one could only benefit from latest changes in D language structure by using DMD and not GDC). GDC is GPL licensed. The libraries are vey loosely licensed (mostly LGPL or BSD style licenses).
- [6] LIBRARIES AND SUPPORT: D is rather poorly equiped in the libraries department; also support and documentation are scarce. The standard libraries come in a few various flavours but mainly Phobos (default) or Tango, and more implementations are in development (like Deimos or Dool). Also there are many bindings and libraries for database connectivity, graphics, network programming and many other major topics (see the DSource projects)
- [7] CROSS-PLATFORM COMPATIBILITY: This is a weak point for D since it is a compiled language. However there are compilers for both Linux and Windows; plus the GDC project also provides versions for Mac, PowerPC and x86_64.
- TOTAL: 62
Ruby Programming Language:
- [1] SPEED: see this point for D language above.
- [7] ARCHITECTURE: Ruby is a great platform for architectural development, even though in my opinion it is too loose. Some strictness and consistency is very helpful for large architectures.
- [9] PRODUCTIVITY: Ruby is a very productive language mainly due to it’s metaprogramming concepts.
- [5] CONNECTIVITY TO C/C++ CODE: This is a weak point for Ruby; it does allow extensions (similar to PHP extensions) but these are cumbersome at best, and almost completely designed to extend the language itself and not the application (which is the point). Writing part of your code as a C extension while the rest is in Ruby is VERY unnatural as well as disconnected (or fragmented). A very attractive alternative is RubyInLine which solves many problems at the cost of a very restrictive programming context; transparency between codes is low. C++ is supported.
- [9] EXTENSIBILITY: Being a scripting language Ruby is VERY extensible and without much headache. Still, it does not provide any specialized means of dealing with application extensions (i.e. versioning or other data - although this can be implemented by the user).
- [9] LICENSING FREEDOM: Ruby is MIT licensed (though some small parts of the code may have different licenses) and related software usually adopts the Ruby licensing terms. Use in commercial projects is permitted without any kind of charges. [edited thanks to pico]
- [6] LIBRARIES AND SUPPORT: While still much smaller than that of PHP, the Ruby community is better than that of D. Libraries and bindings are more common though support is not as widespread. Documentation is harder to use than for other languages and it’s either too technical or too poetic in some cases.
- [9] CROSS-PLATFORM COMPATIBILITY: The Ruby language is based on a virtual machine which runs almost identically everywhere without requiring you to recompile your code (naturally).
- TOTAL: 55
So, at least for my purposes, this is the result: D beats Ruby by 7 points. There is also the issue that even though Ruby is meant to be an all-purpose programming language, it is not and I think it will never be, because it is interpreted. The performance drawbacks of such a language at the present, I think, restricts it’s ability to be all-purpose as claimed.
Ok so that’s all for now.
- This is not to say that I’m doing a generic and universal comparison of the two; far from it; this is merely a research study for my project (which also happened to change consistently during this research). The project I’m speaking of is now meant to be a new interpreted programming language. ⇑
Enjoyed this post?, why not subscribe to the RSS feed!
August 17th, 2007 at 9:40 am
A couple of disagreements with your Ruby data, in the interest of fairness…
Architecture: The comment about Ruby and interfaces. I don’t know any Ruby developers who use interfaces, or any kind of hackish restrictions on class implementations like you mention. Ruby developers use “duck typing”, i.e. if it walks like a duck and talks like a duck, it must be a duck. It’s more classes by contract: I expect this class to implement this method. If it doesn’t, I’m going to throw an exception. Not sure what Ruby developers you’re talking to, but they’re not hard-core Ruby coders if they’re using interfaces. Interfaces are irrelevant in a dynamic language.
Extensibility: It’s pretty easy and very well documented how to write a C-library interface in Ruby or use SWIG to wrap C libraries. Check out RMagick and Ferret as examples.
Licensing: Not sure where you’re getting your information about Ruby… Ruby is licensed under the MIT license, and Rails and most other Ruby libraries under the Ruby License, which is fairly close to the MIT license. Both allow you to use both the language and the libraries in a closed-source commercial application with no penalty or licensing fee.
Libraries: Most Ruby developers use the rubygems packaging system, which supports library versioning.
Cross-platform: D is miserable at cross-platform. GDC still feels very rough compared to the D compiler.
That said, I like D a lot, but I found the point about libraries to be a huge drawback. There were some seriously necessary libraries I needed in D, such as database drivers, that just weren’t there, were buggy, or would compile differently on OS X and Linux under GDC versus Windows D compiler if at all. Kind of outweighed the others enough that I used C and Python instead of D for the project I was looking at.
Ruby is an awesome language for its metaprogramming/DSL ability. Rails is a great example of translating your business needs into a language to simplify the repetitive work (like creating DB model APIs). There is some serious power there.
August 17th, 2007 at 10:11 am
Hi,
Nice blog here, comparing D with Ruby.
Ruby has now matured as Jruby (Version -1) and IronRuby (pre-alpha) and both have taken measures to make Ruby As faster as they can.
The performance problem is solved now at least in IronRuby. Now IronRuby gets the touch of DotNet Platform with many newly added advantages.
You should compare this in future with Jruby and IronRuby.
Just my Opinion.
August 17th, 2007 at 10:29 am
Ok, first of all, please keep in mind that I do not want to turn this thread into a flame-war about which is a better language: D or Ruby! (see the footnote of the post). I think such an endeavour is pointless especially considering the project at hand! You can think of this post as another perspective on the issue.
However, that being said I still *do* stand behind what I said (mostly).
> “…I don’t know any Ruby developers who use interfaces, or any kind of hackish restrictions on class implementations like you mention. Ruby developers use “duck typing”, i.e. if it walks like a duck and talks like a duck, it must be a duck. It’s more classes by contract: I expect this class to implement this method. If it doesn’t, I’m going to throw an exception…”
Here’s a discussion about implementing interfaces in Ruby http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/60616.
So, my argument was that in *large* architectures (especially, although not only) interfaces (or any kind of pure virtual prototypes) are a *very* useful feature that helps a lot when a bunch of programmers have to extend / improve / debug / etc. the software at hand. It is true that duck typing is characteristic to dynamic languages but that does *not* mean that it is an entirely better solution than interfaces and that it could replace interfaces.
Also, at least to me, it seems unfeasible to rely on the fact that your host source code calls the right methods and the guest source implements the right methods all that being let at the hands of exceptions being thrown (although, as I said, this could turn into a productive benefit, but only if working on smaller scale projects).
Having a common denominator (an interface) between the host and guest source codes is a huge benefit when the application architecture grows considerably (at the cost of one being required to write the interfaces). This leads to more harmonious code interactions, and it is less error prone.
> “It’s pretty easy and very well documented how to write a C-library interface in Ruby or use SWIG to wrap C libraries. Check out RMagick and Ferret as examples.”
I’m not sure how *easy* it is since you yourself said that one needs to *wrap* C libraries with SWIG and such or to write interfaces to C libraries. Of course Ruby can be extended through C, but that does not mean it’s *anything* like what D does. Also, the entire issue of connecting from D/Ruby to C/C++ libraries is much broader and (I repeat) writing C extensions for Ruby in a way disconnects your C code from your Ruby code in your application, because Ruby extensions were essentially designed to extend *the Ruby language* and *not* your applications (even though this can be done).
> “Not sure where you’re getting your information about Ruby… Ruby is licensed under the MIT license, and Rails and most other Ruby libraries under the Ruby License, which is fairly close to the MIT license. Both allow you to use both the language and the libraries in a closed-source commercial application with no penalty or licensing fee.”
I have to agree with you here. You are totally correct. I don’t know what was wrong with me, but I know I was really tired. I mixed up some licenses and didn’t realize it. Thanks for correcting this, I’ll do an edit of the post.
> “Most Ruby developers use the rubygems packaging system, which supports library versioning.”
True, but what I was hoping for was a way to add C extensions to Ruby and have them versioned (and possibly attach other information as well).
> “D is miserable at cross-platform. GDC still feels very rough compared to the D compiler.”
> “There were some seriously necessary libraries I needed in D, such as database drivers, that just weren’t there, were buggy, or would compile differently on OS X and Linux under GDC versus Windows D compiler if at all.”
I agree that D is lower on tha scale of cross-platform-ness than Ruby but as I said there are compilers for the major operating systems and I have to say that I didn’t run into the problems you talk about. the DBI database interaction layer worked very well for me. Also the GDC compiler has made great improvements, especially since the DMD compiler reached version 1.0 which marked the end of significant changes in language design. GDC is pretty cool.
Also I agree that the D community and library collection is rather limited at the moment (hence the grade). I would also like to see an ORM implementation for D (I *have* seen one project that begun this but I can’t remember the name).
> “Ruby is an awesome language for its metaprogramming/DSL ability. Rails is a great example of translating your business needs into a language to simplify the repetitive work (like creating DB model APIs). There is some serious power there.”
Of course that’s true, but that’s not what I’m after here. Remember, the target is a new (4th generation) programming language.
Cheers! :)
August 17th, 2007 at 10:50 am
> “You should compare this in future with Jruby and IronRuby.”
Nice suggestion. However, I dont think that I am the right person for such a comparison mainly because I’m not familiar with these implementations since I was not interested in a Java or .NET implementation in the first place. I will not go into my reasoning now since it is beside the point (although I think it is very good that the Ruby language is ported into as many programming “circles” as possible - everyone can benefit).
Still, I would love to see someone else try this (and maybe post a link here, on this blog). Really!, that would be a very cool thing to study.
August 17th, 2007 at 2:35 pm
I’m a Ruby and JavaScript programmer, but I once gave D a look as well. I didn’t like it as much as I like Ruby, so D never had a chance with me. At the time I took a look at some GUI libraries for D, and I even came across the “D SourceForge-like” site. Cool stuff! I could see that D had some momentum, some well deserved momentum perhaps. But for the things I was doing, Ruby had become much better for me than most languages, so other languages never had a choice with me.
This year I started using JavaScript for pragmatic purposes, and now I am a little less enthusiast about Ruby than before as I have to work with both languages which made me more confident in Ruby and in myself.
BTW, if the difference is mostly speed, the 7 points of the difference are pretty irrelevant if the person finds Ruby fast enough, which is the case many times. For example, I have my own Web Framework which uses Mongrel and Nginx for the server and with careful algorithms and architecture, I’m happy with the performance I get. And I am happy that Ruby is being supported in Java and .NET so in the future, should I need something else, I will be able to keep current by using Ruby. :-)
Cheers.
August 17th, 2007 at 6:16 pm
In your article you mention that MiniD is “interpreted D”; this isn’t quite right. It’s an entirely separate language, based more on Lua than anything else.
But I’m still very happy that you saw my language :D
August 17th, 2007 at 6:25 pm
Remember that Ruby has to be ported to every platform that you want to run it on. I think there’s very little difference between D / Ruby when it comes to cross-platform compatibility, unless all of Ruby is written in ANSI C like Lua.
August 17th, 2007 at 7:09 pm
> “In your article you mention that MiniD is “interpreted D”; this isn’t quite right. It’s an entirely separate language, based more on Lua than anything else.”
You’re quite right. I’m glad you took the time to correct this. I’ll edit the post so that others won’t be induced in error. Anyway, keep up the very good work. :)
August 17th, 2007 at 7:21 pm
In reply to Joao Pedrosa:
I agree, but the final conclusion is heavily weighted on what you need. If you are involved in projects that rely on dynamic script-like programming (maybe web oriented) then Ruby is very hard to beat (even considering its speed issues). I also admit that the mind-boggling speed of web-servers like Nginx somewhat compensates for Ruby’s drawbacks.
A propos, I would *very* much like to see some simple speed tests between Ruby and D against Nginx and see the results (regardless of the fact that benchmarks are generally inaccurate and more subjective than anyone might whish).
August 17th, 2007 at 7:50 pm
Btw, Ares (from sean_k, a low level D standard library replacement) is the predecessor to Tango (together with Mango from Kris, a general purpose library), not something seperate or new to come. The only other stdlib I know is being developed is libd (very low level, from maide I think).
To nginx performance, that only helps when used as a proxy + static file serving with several backends. Watch out for Swiftiply for ‘almost exclusivly dynamic’-webapps.
Oh btw, you can even bridge D to Ruby, I did that as an exercise, works like a charm and you get the best of two worlds. Now, if coding C once in a while wouldn’t make so much fun. :P
August 17th, 2007 at 9:13 pm
On standard libraries; Ares is no longer developed as it is now the core in Tango (together with large parts of the old Mango, although it still has features not in Tango).
August 18th, 2007 at 7:15 am
I think you left out a reasonable candidate language in your initial comparison: OCaml. It isn’t as well-known outside of language research circles, but the ML family of languages were made to assist in algorithm provability: as an indirect result, they optimize well and catch a lot of errors at compile time - many more than C-style languages, including D.
OCaml allows C function calls and has mature libraries in several categories - better than the D ones the last time I checked. It’s the most popular ML right now, and has been used on a few commercial projects as well as in academia. It is considered a good choice for new compilers; the haXe language, for example, uses OCaml for its compiler. (also see: http://compilers.iecc.com/comparch/article/98-07-220 )
It has type inference, which means that in a lot of situations the syntax can look breezy like Ruby or Python code, but the compiler can still tell you when something looks wrong. This, along with the functional programming features, gives it a fairly large subset of the things that are mostly associated with interpreted languages.
If nothing else, this will give you something to chew on.
August 18th, 2007 at 7:48 am
Quite an interesting point, I agree. Thanks for the insight jh.
I have to admit that I am not at all familiarized with OCaml (although I seem to hear about it quite a bit lately).
I’m intrigued… I’ll have a look.
August 18th, 2007 at 3:48 pm
I think the biggest problem is comparing static code to interpreted one. You know that people who choose ruby dont do so because of the speed, right? :)
And ruby code is still a lot easier to read and understand than any of the has-to-compile versions, be it java c# c++ or D
August 18th, 2007 at 6:03 pm
[…] useless to compare compiled and interpreted programming languages. The target of his wrath is this comparison of D and Ruby, with it claimed that it is “comparing apples to […] (read the rest)
August 18th, 2007 at 6:31 pm
Well put!, Thanks.
I would also like to add that there are many languages that make use of compiled or interpreted code and all are still called “all-purpose”. Moreover there are languages that further dissipate the separation line between these two concepts by actually using a mixture of them (like Java uses precompiled bytecode).
So I agree with the concept that this all a matter of perspective.
Also, I think *any* comparison between two (or more) languages *has* to be made in the relative context of a certain goal (some type of project). This would give meaning to the comparison, since most languages were created in a certain (different) way, to achieve a certain something that others can not (or can but with difficulties).
Cheers :)
August 18th, 2007 at 8:30 pm
In terms of improving Ruby speed you could also throw a look at rocaml, see http://www.rubyinside.com/rocaml-write-ruby-extensions-in-ocaml-544.html for more information.
August 19th, 2007 at 8:38 am
I have been using both programming language.
D was developed aimed to system programming, but Ruby was aimed to joy of programming.
they have difffenent aim, so it’s difficult to compare.
I think, It’s important to think of your aim what you programming for.
System programming or Web Programming?
August 19th, 2007 at 11:55 am
You forgot about dynamic code updates in Ruby. In Ruby you can replace any class/module/method implementation on the fly. It means that you can fix bugs or upload new features into 24×7 systems without stopping it.
Ruby is very mature language. Even with development 1.9 which introduces some incompatible language changes Ruby 1.8 remains stable and widespreaded platform. D in not mature, even more -- D2.0 is not compatible with D1.0 and D1.0 has no significant addoption.
August 19th, 2007 at 12:38 pm
> “I think, It’s important to think of your aim what you programming for.”
I agree.
August 19th, 2007 at 12:45 pm
> “In Ruby you can replace any class/module/method implementation on the fly.”
I agree this is a major plus for Ruby (hence the higher grade for ruby architecture), however, I did not forget it! It just seemed to me that this feature is more appropriate for use when dealing with enterprise or web oriented applications (the end result) and not my project.
As far as being able to replace/update/improve the software without stopping it, that can be done beautifully with D by using DDL plugin architecture. In fact this very concept is something that I really want in my code: the ability to upgrade pieces of the program on the fly.
August 19th, 2007 at 8:47 pm
Some interesting points, and I would like to point out to some people that it was afterall just 7 little points that let D when for your project. Hardly a landslide. :)
I count myself both a D developer and a Ruby developer, going through trains of thought much like your own when deciding what to use for something. There are just some times when Ruby has inescapable advantages -- in one case I needed a simple program to do a task, and needed it very fast… it ended up being all of two lines in Ruby. (Granted, they were two convoluted lines.)
One last thing: in the area of scripting, don’t forget PyD, the Python binding. Its been a highly inspirational project at the least.
August 20th, 2007 at 5:45 am
> “…it was afterall just 7 little points that let D when for your project. Hardly a landslide. :)”
Correct! However, (as I already stated somewhere else) depending on what are the priorities of your project and your personal preferences those 7 points may weigh more or less (weird I know, but real!). In my case, in the end, the speed benefits of D weighted more.
> “There are just some times when Ruby has inescapable advantages.”
Of course!, and I tried to show this through the grades, especially for productivity! I was close to giving Ruby a full 10 at this point.
> “…don’t forget PyD, the Python binding. Its been a highly inspirational project at the least.”
I am very glad when other people recommend different software implementations on the side of the subject.
Here’s a link to PyD for the interested.
This is great, thanks!
August 24th, 2007 at 12:01 pm
I think you’ll find OCaml or F# beat both D and Ruby hands down in almost every respect. Particularly, OCaml for performance and F# for web programming.
August 24th, 2007 at 12:20 pm
> “OCaml or F# beat both D and Ruby hands down in almost every respect.”
That’s insane! I don’t understand how you can say that F# is better than Ruby for web programming: think about the cross-platform compatibility implications, the architectural advantages of Ruby (like advanced meta-programming), and there are so many other things to say here.
Also, what were they thinking when they made a language where you can still see something like the “let” statement? Now, I have no doubt that F#, being a functional language has its advantages but even so, it would be impossible to beat Ruby “in every respect”. Again, I don’t think two languages should be compared out of the context of a target project.
As for the OCaml part, I still don’t see how it could beat D for sheer speed, what I think that OCaml truly has got over D is its maturity level (which in time becomes relative)!
PS: Also, F# and OCaml syntaxes are not as naturally intuitive for C/C++/Java/PHP progammers as D’s or even Ruby’s syntax.
September 9th, 2007 at 12:30 am
I haven’t been using D programming language that much, i know little about it, but i have been playing around with Ruby.
I just think that the support of the Ruby/D comunity matters much more, in wich case ruby wins.
And as your project grows you could use alot the help of the open comunity.
PS: Great blog!
November 15th, 2007 at 12:25 am
Version 2.0 of the D language has better support for interfacing with C++: extern(C++) assume C++ vtable layouts and mangling.
Nice writeup!
September 2nd, 2008 at 10:37 am
ruby + postgres = headache