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.

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.

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! :)

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.

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.

But I’m still very happy that you saw my language :D

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. :)

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).

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

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.

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.

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

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 :)

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?

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.

I agree.

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.

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.

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!

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.

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!

Nice writeup!