Usage of Scala at Twitter

Here is a nice presentation about the use of the Scala language at Twitter:  

Besides the counless features of Scala (type interfence, Traits, Pattern Matching, ...), I found the reasons interessing the speaker gave against Ruby (Twitter was once a major landmark project for Ruby and Rails) : "Ruby's poor VM performance, monkeypatching and cultural issues, questionable for large systems". I found Monkeypatching terrible. Is there an equivalent to Liskovs principle for monkeypatching?

Ein paar ungeordnete Gedanken zu Ruby on Rails

Ich entwickele - quasi als privates "20% Projekt" - mein erstes größeres Projekt im Ruby on Rails.

Insgesamt bin ich wesentlich produktiver als ich es mit JSP/Servlets oder ASP.NET jemals war. Aber irgendwie bleibt ein ungutes Gefühl im Magen. Deshalb hier mal ein paar ungeordnete ziemlich ketzerische Gedanken zu Ruby und Ruby on Rails, die ich aber einfach mal los werden muss.

• Ich hasse solchen Code:

  
  >>s = "Hallo"
  >>s2 = s
  >>[....]
  >>s << " Welt"
  >>[...]
  >>s2 == "Hallo" => false
  >>s2 == "Hallo Welt" => true
  

  
  

  Änderbare Stringklassen haben ihren Zweck (deshalb gibt es in Java StringBuilder zusätzlich zu java.lang.String), aber sie sollten nicht die Standardklasse für Zeichenketten sein. Die Argumentation über Korrektheit wird die Hölle, wenn jederzeit von Hinten den Zustand zerschossen werden kann. Dafür das Ruby eigentlich so funktional angehauchte Sprache ist (sein soll), ist die Stringklasse (eine der zentralsten Klassen überhaupt) eine Katastrophe. In Bezug auf Zeichenketten ist Java funktionaler als Ruby.

  Mit string_name[0..-1] eine entkoppelten Clone einer Zeichenkette machen, was man auch dringend an entsprechenden Stellen auch machen sollte, wenn man keine Lust hat den Zustand zerschossen zu bekommen (z.B. immer wenn man eine Invariante bezüglich des Inhaltes einer Zeichenkette testet)

• In Ruby on Rails hinter Fehlern herzusuchen ist die Hölle. Such mal Fehler in dynamisch generiertem Code also Code ohne Entsprechung im Quelltext. Ich hab 3 Abende hinter einer nur manchmal auftretenden Endlosschleife in einer benannten Route von einer REST-Ressource in Rails hinterhergesucht. Grausam. (Ok, auf die Idee die Route normal, also mit :controller => x, :action => y, anzugeben hätte ich schneller kommen können). Woher die Endlosschleife kommt, habe ich bis heute nicht verstanden.
  
• So richtig wohl fühle ich mich bei Ruby noch nicht. Ich verstehe die Syntax und die Möglichkeiten z.B. dynamisch Klasse zu erweitern und Code zu generieren, aber für mich ist es zu viel Magie. Ich habe noch die Befürchtung, dass die Entwicklung nur solange wirklich richtig produktiv ist wie alles klappt, aber wehe man bekommt Probleme. Ich hoffe Rails ist keine Sackgasse sobald man anspruchsvolle Dinge probiert oder man sonst auf Probleme und komische Bugs stößt.
  
• Ruby on Rails macht auf mich eher dein Eindruck einer Sprache zum Schreiben von Code anstatt zum Lesen und Verstehen von Code. Zu viel implizit zu machen (Magie) macht es manchmal nicht einfacher zu verstehen.
  
• Python ist einfach eher meine Sprache. Scala würde ich gerne mal für etwas richtiges Ausprobieren. Ich hab das neue Buch "Programming in Scala" von Martin Odersky gelesen und will es unbedingt mal ausprobieren.
  
• Eines der Killerfeatures von Rails und warum ich noch nicht nach Pylons (Pythlon) oder Lift (Scala) gewechselt bin, ist die gute Integration von AJAX, insbesondere mit RJS. Wow. Ich fühle mich eher im Backend zu Hause, aber was ich in wirklich wenig Zeit an schicken AJAX-Sachen machen konnte, ist beeindruckend.
  

  Das Two-way-Matching von Url-Pfaden auf Controller (Routes) war mein erster Wow-Moment bei Rails (und ich finde es immer noch gut gelöst, wenn man mal von gewissen Endlosschleifen absieht (s.o.)). Allerdings hat Pylons das Konzept ziemlich direkt übernommen.

  Auch das fließende Zusammenspiel von Controller und View hat schon einiges für sich. Wie gesagt, ich habe viel in kurzer Zeit geschafft. Rails hat schon gute Konzepte.

• Alle Ruby und Ruby von Rails-Bücher in der Bibo sind auf Monate verliehen und vorgemerkt.
  
• 
  Hibernate ist Rails ActiveRecord um mindestens 3 - 5 Jahre voraus. ActiveRecord ist nett und man kann gut mitarbeiten, aber diesen großen Hype um Rails ActiveRecord verstehe ich nicht. Einen Vergleich aus 2005 zwischen Hibernate und ActiveRecord ist auf ServerSide.com zu finden. Nur als Beispiel: N:N-Beziehungen können meines Wissens nach nicht transparent umgesetzt werden. Man sieht immer die Mittlerklasse/Mittlertabelle wie hier dargestellt. Es ist eine Umsetzung des Active Record Musters von Martin Fowler, deshalb muß quasi schon jede Tabelle 1:1 abgebildet werden, aber das Optimum zum Arbeiten ist für mich eine ORM, die die Objekte näher an die Domain bringt.
  

  Wenn man Hibernate gewöhnt ist, fühlt man sich bei ActiveRecord fast als würde man wieder auf dem blanken Metall arbeiten.

• Hochdynamische Sprachen wie Ruby stellen viel höhere Anforderungen an die Dokumentation als statische Sprachen wie Java. Dort hat man wenigstens mal den Compiler um den größten Unfug zu entdecken. Dafür ist die Dokumentation von Rails ist in meinen Augen nicht ein Auszeichnungsmerkmal von Rails. Kann mir mal jemand z.B. die Dokumentation für die Methoden zeigen, die 1.hour usw. ermöglichen? Ich konnte es wirklich nicht finden.

Vielleicht wird der nächste Ruby on Rails Artikel hier etwas positiver, aber dieses Problem mit der benannten Route hat mich echt genervt.

Skalierbarkeit und "Ruby on Rails"

Twitter ist eine stark wachsende Web 2.0-Anwendung, die mit Rails entwickelt wurde.

Ich möchte mich hier gar nicht mit dem Sinn und Unsinn von Twitter beschäftigen, sondern ich möchte mich auf ein aufschlussreiches Interview mit dem Twitter-Entwickler Alex Payne verweisen in dem es auch um die Skalierbarkeit von Rails geht.
In dem Interview heisst es:

Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time.

The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

Dies hat mit der (Grundsatz-)Entscheidung des Ruby Entwicklers David Heinemeier zu tun, sich um Skalierbarkeit und Performance wenig Gedanken zu machen. Er gibt Entwicklern den Rat "Don’t scale".

Ein (in der extremen Form wie ihn David Heinemeier gibt) riskanter Rat wie Greg Linden in diesem Posting von 2005 argumentiert.

Ruby-Präsentation in der Google Talk-Reihe

Google hat innerhalb seiner Google Talk-Reihe eine Speaker Series über Ruby On Rails gestartet, die sie über ihre Videoplattform öffentlich verfügbar machen.

Am 8. März haben die Entwickler des Webdienstleisters Competitious (TechCrunch) ihre Erfahrungen mit Ruby On Rails dargestellt (Video).

Die Präsentation und vor allem die sehr interessante Diskussion danach beleuchtet die Vorteile von RoR, aber auch die (momentanen oder konzeptionellen) Schwächen. Auch die Frage, wann man vielleicht nicht Rails einsetzten würde werden gestellt und beantwortet.
Einige Beispiele (z.B. das Activity Logging) zeigen sehr schön die eleganten "Tricks", die man mit der Ruby-Programmiersprache machen kann.

Die Slides sind im Entwicklerblog von Competitious verfügbar.

P.S. Schön zu sehen, dass ich offensichtlich nicht der einzige bin der a) manchmal Ruby sagt, wenn er Rails meint und b) der Versuchung einer Framework-Debatte kaum widerstehen kann.

Fazit vom 1. Webmontag

Gestern fand der erste Webmontag in Paderborn statt und ich glaube es war (für einen ersten Versuch) auch eine gelungene Veranstaltung. Klar, manche Dinge müssen sich einspielen, es war nicht klar wie viel Zuspruch die Veranstaltung bekommt und welche Zielgruppe anwesend ist. Ich bin sicher beim zweiten Mal (schon in Planung!) wird es etwas weniger chaotisch ablaufen, aber es war auch so interessant.

Wer sich nochmal den Vortrag von Frederik und mir über Ruby On Rails ansehen möchte und die Folien noch mal langsam durchgehen will, kann sich die Folien bei Frederik herunterladen.