Bugzilla:Languages

This is a basic overview of various possible languages that we could move to, for Bugzilla.

Of all of the ones I (mkanat) have used, I'm most in favor of Ruby, because I think it'd be the fastest to write code in and it seems well-designed for writing large applications.

In addition to looking at the languages themselves, we should also investigate various tookits available for the languages that would make our development easier. For example, Python has Pylons and lots of other frameworks, and Ruby has Rails and Nitro. If one particular language has a framework that would be perfect for us, that could swing the decision.

Primary Considerations in Picking a Language

1. Ease of Development: We want to rapidly create new features and not have to wory about little details.

2. Ease of Modification: We want to be able to change the code without too much work. The more "abstraction" opportunities a language or framework offers, the better off we are.

3. Performance: It shouldn't perform significantly worse than current Bugzilla code.

4. Available libraries: We don't want to have to re-write the things that we're using now from CPAN. We also want libraries generally available or built-in to the language that we can use in the future.

5. i18n and l10n: We want to be able to easily localize Bugzilla in different languages without people having to re-write the templates like they do now. Anything supporting GNU Gettext in an easy way would be great.

6. Security: Perl has a Taint mode, which encourages security. We want a language that has good security-oriented features, and that has a community with a history of paying attention to security issues.

7. Enforcement of Good Code: One place where Perl falls down is that it doesn't enforce any good coding standards. A language that does would be welcome.

Frameworks Under Investigation

This lists the particular frameworks that we're actually considering.

• Perl with Catalyst
• Ruby with Rails
  • Also investigate Hobo.
  • Want to look at Globalize for i18n.
• Python with Pylons
  • Using SQLAlchemy
  • Different templating systems are available:
    • Elements
    • Mako (like HTML::Mason)
    • Kid
    • Genshi
• PHP with CakePHP
  • The "serious PHP framework" space it boiling down to one of two these days - Symfony, which yahoo! have used or Zend's Framework which has serious backers like IBM (financially and contributing manpower I believe)

Pros/Cons of Individual Languages

This section goes over the various advantages and disadvantages of the languages themselves, from Bugzilla's perspective.

Perl

Pros

• Lots of modules available in CPAN.
• Relatively fast.
• mod_perl is very mature and extremely fast.
• Not porting would avoid 2nd system syndrome
• Not porting would allow improvements to be gradual and available to users much sooner.
• MVC Frameworks such as Maypole, Jifty and Catalyst
• Simple ORM like Class::DBI, or more powerful ORM like DBIx::Class, etc
• Mature and experienced developer user base, with well documented good practice, local user groups, etc.

Cons

See The Problems of Perl.

Perl6

Pros

• Implements many features we'd like to have that Perl5 doesn't have.
• Would be the easiest language to port our current code to, since it's so similar to Perl5.

Cons

• Essentially vaporware. There is an interpreter written for it, but it's in Haskell and it's not shipped by any distro.

Python

Pros

• Extremely popular.
• Stable.
• Actively developed.
• Lots of modules.
• Will attract ueber hackers

Cons

• Deployment choice can be a bad thing (i.e. mod_python, mod_wsgi etc.) - harder to install
• Not having curly-braces on "if" statements and other blocks makes long blocks hard to read.
  • (added comment) subjective - could it be you're trying to write Perl in Python? I.e. python is really trying to discourage you from writing those long blocks and investigating stuff like list comprehensions
• Poor Unicode handling--strings are ASCII by default, and are Unicode only if you prepend them with u, like u"string".
  • (added comment) subjective - once you know how it works and how to use it, it's actually really well implemented IMO - see All About Python and Unicode
• No standard way of installing modules like CPAN.
• Python has no equivalent to Perl's "taint" mode.
  • ...but python is a strongly typed language e.g. newstr = "hello" + 1.2 is an exception

Ruby

Pros

• Extremely modern language, lots of great features built-in to the language.
• RubyGems, a CPAN-like method of installing modules.
• Becoming more and more popular.
• Very easy to learn, development is very natural and very fast.
• Very actively developed.
• Has a taint mode, just like Perl.

Cons

• Not yet as well-known as Python.
• Good Unicode handling isn't coming out until 1.9, but that's the next release.
• Performance is apparently orders of magnitude slower than Python (something like 2-3x).
• Question marks over Ruby runtime
• 24x7 Ruby web apps = FastCgi plus writing scripts to monitor fastcgi daemons (and restart them) + getting up at 7am on Sunday to manually restart
• 24x7 Ruby web apps at higher traffic = 24 * mongrels + 4 * mod_proxy + lots of code tuning + dedicated sysadmins + verbal abuse

Java

Pros

• Excellent "design by contract" features (compared to the other languages in this listing).
• Very stable.
• Fast.
• Allows for easy web application installation.

Cons

• Much slower to write in than scripting languages.
• The Java Classpath is not FOSS.
• Nothing like CPAN's client-side module installer.

PHP 5 or 6

May be worth investigating PHP::Interpreter]

Pros

• Extremely popular
• Easy to setup / get hosting
• Basically fast
• mod_php is basically intrinsically as fast as mod_perl
  • ... but it prevents scripts from storing data on the heap (like globals) beyond the lifetime of a single request - some information on that here or my dumbed version here - i.e. no more killing / restarting Apache processes - the PHP runtime is effectively stateless
• Decent object-oriented features
• For this type of project, that PHP isn't a "clever language" could be a feature (no "Higher Order PHP" that only the ueber hackers can understand)

Cons

• Lacks strict (variables) mode
  • (Added comment) enabling PHP E_NOTICE error messages (e.g. in php.ini) does something similar. But PHP security is an issue (many gotchas for the inexperienced) - a framework could help a lot here
• Lacks a taint mode.
• Not historically designed for applications in the classic sense, but rather focused on scripting.
• Charset encoding is not yet well supported (PHP6 should solve this)
• The "PHP Sucks" factor will discourage the ueber-hackers
• PHP is not a general purpose programming language - it's best at web pages, period (e.g. run that script for more than 30 seconds on the command line and you might start noticing how PHP's garbage collector sucks).
  • In other words you'll probably need another language to for anything not directly related to servicing HTTP requests

C#

I hear lots of good things about C#, but I've never actually worked with it. Maybe somebody else could fill this in? I'm be slightly wary of it, since the Windows .NET stack will probably always be ahead of Mono (the *nix .NET stack), and thus the language is essentially controlled by Microsoft.