Was würde sich anbieten?

Hi,

ich arbeite seit längerer Zeit an einem Konzept für eine Applikation. Worüber ich mir nicht ganz sicher bin, ist die Technologie (ich bin kein Fanatiker einer bestimmten Sprache. Ich habe einen riesigen Pool an Zeit, folglich kann ich mich mit jeder Sprache und entsprechenden Technologien genügend beschäftigen).

Eckdaten der Requirements:
- Cross-Platform
- Real-Time Notifications (also kein Polling und ähnliche Dinge, die mir irgendwann den Server in die Knie zwingen)
- Webapplikation; bestenfalls liefert man einen Installer aus, knallt sich das Teil auf nen Server und jeder Zugriff übers Netzwerk. Was ich vermeiden will, ist eine komplizierte Installation.
- Performant. Das Ding hat sogut wie keine komplizierten Rechnungen, aber es nützt mir nix, wenn ich bei 5 Clients den Server schon zur Hälfte ausgelastet hab.

Was mir so in den Sinn gekommen wäre:
Java: wäre eine Möglichkeit. TomCat könnte man direkt mitliefern.
PHP: Wäre theoreitsch auch möglich, aber bei Real-Time Notifications bin ich mir etwas unsicher, da ich mit WebSockets noch nichts gemacht hab.
Ruby: noch nichts drin geschrieben, sieht aber zumindest brauchbar aus. Nachdem GitLab/GitHub drin geschrieben ist, und das vom "Applikationstyp" dem was ich vor hab recht ähnlich ist, hab ichs auch mal in Betracht gezogen. Ggf. wohl Rails.
Python: keine Webapplikationen damit geschrieben, aber die Kleinigkeiten die ich damit gebastelt hab, waren eigentlich alle ganz ok.

Jemand Ideen, Meinungen?

Mechanics

Im Grunde wäre jede Sprache mehr oder weniger geeignet und deine Bedenken gegenüber PHP wegen den Notifications versteh ich nicht. Das gilt genauso für die anderen Sprachen und umgekehrt könntest du in PHP auch was anderes nutzen, was du auch in den anderen Sprachen nutzen würdest.
Ich persönlich würde für sowas Java nehmen. Ich würde kein größeres Projekt in einer Scriptsprache schreiben wollen. Das ist aber mehr meine persönliche Abneigung und mir ist durchaus klar, dass es etliche erfolgreiche große Projekte in allen möglichen Scriptsprachen gibt.

Dobi

Geht bestimmt mit allem von den angegebenen, und vieles ist ja auch Geschmackssache. Also schreib ich auch mal meinen Geschmack dazu.

Java würd ich nicht nehmen, dann eher Scala.
PHP auch nicht.
Ruby und Python mag ich beide, und die tun sich gegenseitig auch nicht viel.

Da du ja genug Zeit hast, könntest du das auch nutzen, um etwas neues dafür zu lernen, wie z.B Clojure, Haskell, Go, Javascript (node.js).

Mechanics

Ja, Scala wär übrigens auch eine gute Idee. Hab das in paar Projekten mit Java gemischt. Die IDE Unterstützung für gemischte Projekte ist aber leider nicht sehr ausgereift (oder war noch nicht ausgereift vor paar Jahren und ich fürchte, es ist nicht wesentlich besser geworden).

hustbaer

@floomi
Für realtime Notification brauchst du keine WebSockets.
Du kannst z.B. einfach über JavaScript nen Request "get event" machen, und der Server beantwortet diesen Request einfach erst wenn's was zu melden gibt. Bzw. kann der Server natürlich auch nach einer bestimmten Zeit (Grössenordnung paar Minuten) eine "gibt nix zu melden" Antwort zurückschicken.

Was nicht heissen soll dass ich dir empfehle das so zu machen - ich meine nur es geht auch anders.

Ich an deiner Stelle würde mich aber auf jeden Fall erstmal nach RAD Toolkits für Webentwicklung umsehen. Ich hätte keine Lust den ganzen Clientseitigen Javascript Code und das HTML-DOM-Gefummel mit Hand zu schreiben.
Und ich würde erwarten dass es da mittlerweile vernünftige Tools gibt. Wobei ich keine Webentwicklung mache und daher keinen Überblick habe -- kann also sein dass ich mich da sehr täusche

Meine Empfehlung:
- Framework: Play. Gibt es als Scala-Version als auch als Java-Version
- Sprache: Bevorzugt Scala. Java geht aber auch.
- Weitere Frameworks: Akka für parallele Abarbeitungen. Ist schon in Scala bzw. Play eingebaut.
- Weitere Technologien: WebSockets, LessCSS, Dart (kann in JS konvertiert werden).

Gruß,
IBV

Warum empfehlen hier so viele Scala, statt Java?

Dobi

Ich habs empfohlen, weil es halt auch auf der JVM läuft, man auf Java-Kram zugreifen kann, aber nicht zu OOP gezwungen wird, sondern auch funktionale Sachen benutzen kann. Und man kann sich etwas biolerplate code einsparen.

edit: http://steve-yegge.blogspot.de/2006/03/execution-in-kingdom-of-nouns.html

Why Scala?

volkard

likefirewood schrieb:

Warum empfehlen hier so viele Scala, statt Java?

Weil:
"Smart developers and development managers are learning that Scala does offer real business benefits."
"In a world where software is notoriously unreliable, Scala's advanced type system provides code verification which makes software more dependable and adaptable."
"A rich set of features gives Scala a very dynamic syntax which allows developers to embed domain-specific languages within Scala code, allowing them to express themselves effectively in the code they write."
"Migrating an existing development environment to Scala might seem daunting, but the language is right at home in a mixed environment, smoothing the migration process."
Das überzeugt mich total.

Erstmal Danke.

Ich würde kein größeres Projekt in einer Scriptsprache schreiben wollen

Sagen wir so: für die Größe wäre PHP eigentlich geeignet. Hauptsache arbeitet die Applikation sehr intensiv mit der Datenbank zusammen, die Sprache selbst würde performancetechnisch aber ausreichen. Lediglich die Notifications machen mir etwas Kopfweh.

Für realtime Notification brauchst du keine WebSockets.
Du kannst z.B. einfach über JavaScript nen Request "get event" machen, und der Server beantwortet diesen Request einfach erst wenn's was zu melden gibt

Ist das nicht Long Polling? D.h. ich hätte für jeden Request eine Instanz des Interpreters laufen - laut diversen Quellen braucht mir dann ein so ein Request ewta 15 MB an Speicher. Bei 100 Benutzern bräuchte die Applikation schon 1.5 GB Speicher, was irgendwo doch viel ist.

Scale muss ich mir mal näher anschauen, dass hatte ich bisher nicht in Anbetracht gezogen.

volkard schrieb:

likefirewood schrieb:

Warum empfehlen hier so viele Scala, statt Java?

Weil:
"Smart developers and development managers are learning that Scala does offer real business benefits."
"In a world where software is notoriously unreliable, Scala's advanced type system provides code verification which makes software more dependable and adaptable."
"A rich set of features gives Scala a very dynamic syntax which allows developers to embed domain-specific languages within Scala code, allowing them to express themselves effectively in the code they write."
"Migrating an existing development environment to Scala might seem daunting, but the language is right at home in a mixed environment, smoothing the migration process."
Das überzeugt mich total.

Ach Volkard... Du kannst damit funktional programmieren und dessen Vorteile nutzen. Aber selbst OO mit Scala ist eleganter, kürzer und lesbarer. Außerdem stehen dir auch unter OO typische funktionale, ausdrucksstarke Funktionen zur Verfügung.

Mechanics

floomi schrieb:

Ich würde kein größeres Projekt in einer Scriptsprache schreiben wollen

Sagen wir so: für die Größe wäre PHP eigentlich geeignet. Hauptsache arbeitet die Applikation sehr intensiv mit der Datenbank zusammen, die Sprache selbst würde performancetechnisch aber ausreichen.

Mir gehts nicht um Performance. Ich will einfach nicht auf die zusätzlichen Vorteile verzichten, die ein Compiler bietet. Keine Lust, ewig nach irgendwelchen Bugs zu suchen, die einfach durch Tippfehler reingekommen sind, oder weil man nicht genau wusste, was man an der Hand hat, und die dann erst sehr viel später im laufenden Betrieb auffallen, weil der Code sehr selten durchlaufen wird. Alles schon erlebt. Außerdem kann man (oder kann ich) saubere objektorientierte Programmierung mit Sprachen wie Java oder C++ besser durchziehen, als mit einer Scriptsprache, erst recht einer wie PHP.

Dobi

Sachen wie Python kann man auch kompilieren und Haskell kann man auch interpretieren lassen. Interpreter können auch schon beim Laden vom Modul Fehler verraten.
Oder gehts dir eher um statische vs. dynamische Typisierung? Hört sich so ein Bischen für mich danach an.

OOP-mäßig sind halt viele GoF-Patterns in Sprachen wie Ruby und co. gar nicht mehr nötig. Das kann sich bestimmt dann auch erstmal unsauber anfühlen. Ich denke, das meiste ist einfach Gewohnheit.
Quelle: Ich bin schlecht in Java und Ruby.

hustbaer

floomi schrieb:

Für realtime Notification brauchst du keine WebSockets.
Du kannst z.B. einfach über JavaScript nen Request "get event" machen, und der Server beantwortet diesen Request einfach erst wenn's was zu melden gibt

Ist das nicht Long Polling?

Ah, es gibt einen schönen Namen dafür
Wusste ich gar nicht. Und ja, genau das meine ich.

D.h. ich hätte für jeden Request eine Instanz des Interpreters laufen - laut diversen Quellen braucht mir dann ein so ein Request ewta 15 MB an Speicher. Bei 100 Benutzern bräuchte die Applikation schon 1.5 GB Speicher, was irgendwo doch viel ist.

Ob pro Request ein eigener Interpreter läuft, und wie viel Speicher das braucht ist ganz von der verwendeten Sprache/Technologie abhängig.
Bei PHP halte ich es für leicht möglich dass es so ist wie du schreibst - damit hab' ich keine Erfahrung. Das wäre dann natürlich ungünstig.

Mit anderen Technologien sieht es allerdings schon wesentlich günstiger aus. Da bewegen wir uns pro Request im Bereich von ein paar KB bis vielleicht ein paar zig KB.

Mechanics

Dobi schrieb:

Oder gehts dir eher um statische vs. dynamische Typisierung?

Ja.

Dobi schrieb:

OOP-mäßig sind halt viele GoF-Patterns in Sprachen wie Ruby und co. gar nicht mehr nötig. Das kann sich bestimmt dann auch erstmal unsauber anfühlen. Ich denke, das meiste ist einfach Gewohnheit.

Mir gings nicht unbedingt um die GoF Patterns, wobei ich auch einige davon öfter verwende, sondern eher um eine sauber durchgezogene und einheitliche Gesamtarchitektur. Und ja, "nicht nötig" kann sich unsauber anfühlen Bei einem Script mit weniger als 1000 Zeilen ist es super, da will ich auch keinen Boilerplate haben. Aber bei Projekten mit hundert tausenden oder Millionen Zeilen Code finde ich sauber definierte Schnittstellen und Vorgehensweisen (oder von mir aus Patterns) viel wichtiger als "braucht man nicht, kann man einfach irgendwas eintippen und es funktioniert". Dieses "irgendwas" funktioniert, ohne dass man genau weiß, was man hat und was man damit machen kann und ob sich das nicht irgendwann ändert, ohne dass man es merkt, mag ich überhaupt nicht. Und bei Scriptsprachen kann man das sehr schwer automatisch testen.
Dass es Gewohnheitssache ist, hab ich ja gleich gesagt. Mir ist schon klar, dass es viele Entwickler gibt, denen dynamisch typisierte Sprachen viel lieber sind und die damit auch erfolgreich sind.

Dobi

OK, mir persönlich gefällt static typing auch besser, vorallem wenn es so wie in Haskell oder Elm ist, und nicht wie in C++ oder Java.

Ich hab mir jetzt Ruby etwas genauer angesehen - gibt es da irgendwas besonderes? Irgendwie siehts interessant aus.

Dobi

Da du Python schon kennst, kannst du dir ja das hier mal durchlesen: https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/
Aber wenn schon so Kleinigkeiten wie "It’s elsif instead of elif." darin Platz finden, kannst du dir ja Denken, dass es nicht so ein großer Unterschied ist wie z.B. Ruby<->Java, C++<->Haskell, IO<->Prolog usw.

Gestern Abend hatte ich mich ein wenig mit Notifications beschäftigt - und irgendwie stellt sich mir inzwischen die Frage, wie die eigentlich in der Realität umgesetzt werden.

Ob WebSockets, Polling oder was auch immer - im Endeffekt kommen die Daten aus einer Datenbank und müssen folglich abgefragt werden. D.h. unabhängig der Technik die dem Client Bescheid gibt, müsste eigentlich die Datenbank "reden" können - sonst kommt man nicht mehr an Realtime, oder?

Immerhin: (Long) Polling oder WebSockets laufen in einer Endlosschleife und benachrichtigen dann irgendwann den Client. Man kann aber wohl schwer innerhalb der Schleife ganze Zeit Datenbankabfragen machen - das würde der Datenbank wohl nicht gefallen. Folglich müsste man ein wait/sleep einbauen, wodurch "Realtime" wieder hinfällig wäre.

Wie wird denn sowas wirklich gemacht?