Auf den Spuren der russischen Scala-Bewegung. Teil 3

Dies ist der letzte Teil der Untersuchung der Scala-Bewegung in Russland. Im ersten Teil erfuhr ich von Roman Grebennikov von Voronezh beau monde, C ++ und Erlang und von Roman Timushev von der ersten Akka und der Geburt der Moskauer Treffen. Im zweiten Teil habe ich mit Alexander Podkhaluzin und Mikhail Mutsyanko gesprochen : Scala kennenlernen, 2007, Scala Days, Scala Native, nach Kotlin ziehen, dann ist Scala gut für Banken, die ersten Events in St. Petersburg, Eclipse, Jason Zaugg, IDE und Scala Plugin.



Während der Vorbereitung des zweiten Teils verwies mich Vladimir Uspensky ( vuspenskiy ) an Alexander Podkhalyuzin , mit dem wir ein umfangreiches Interview aufgenommen haben. Am nächsten Tag erhielt ich eine Nachricht von Vladimir, aber jetzt mit seiner persönlichen Geschichte: Qiwi, Scala in Tinkoff, erste Treffen, Links zu alten Blogs (besonderer Dank dafür) und Funktionalismus von 2008 aus Rúnar, der auf Java läuft, - Das ist immer noch Blut aus den Augen, zumindest ungewöhnlich. Darüber hinaus - die Geschichten von Roman Elizarov , Alexei Fomkin und Nikolai Tatarinov . Eigenschaften der Einstellung von Scala-Entwicklern, Kurse zu Coursera, "perfekter Code", "dämonische" Kompilierung, Design in Kotlin, 10.000 Codezeilen, Tinkoff-Internetbanking, erneut Tinkoff, Play Framework, verstorbenes Flash, "Sunrise" und St. Petersburg-Meetings - darüber im letzten teil der trilogie unter dem schnitt.

Vladimir Uspensky: Coursera, Tinkoff und Einstellungen für Scala

Vladimir : Damals habe ich bei Qiwi gearbeitet und viel Java-Code überarbeitet, aber ich habe immer noch viel Wasser und ein Boilerplate. Ich wurde gequält, aber irgendwie demütigte ich mich.

Nach einiger Zeit ging ich zu den Blogs von Alexander Temerev und Vlad Patryshev . So wie ich es verstehe, war Vlad an vorderster Front bei der Implementierung von Java. Ich las mit ihnen über Scala und bemerkte, dass mir damals fremde Konstruktionen wie Java-Optionen aufgefallen waren . Ich habe diese Option sogar irgendwo in der Produktion eingeführt. Es gab exotischere Lazy Error Handling in Java und Higher-Order Java Parallelism von Rúnar Bjarnason . All das hat das Gehirn höllisch in die Luft gesprengt und sich gefragt, wie man das alles anwendet.

Als ich bestimmte Beispiele studierte, zum Beispiel von Daniel Spiewak : Scala für Java-Flüchtlinge , fehlte mir genau dies. All das Wasser und seltsame Inkonsistenzen wie `_` vs `*` vs `?` Aus dem Java-Code sind `_` vs `*` vs `?` und die Essenz bleibt.

Es war Scala 2.7 und, gelinde gesagt, nicht stabil. Viele Projekte haben es für Komponententests oder Fallklassen ausprobiert. Um Scala zu einem Java-Projekt hinzuzufügen, mussten Sie die gemeinsame Kompilierung in Maven konfigurieren. Aber ich habe beschlossen, ein unkritisches Projekt in Qiwi zu unterstützen. Alles hat geklappt - ich war sehr glücklich, aber dort endete es.

Arbeiten bei der Implementierung von Tinkoff und Scala

Plötzlich wurde ich nach Tinkoff eingeladen, um die Entwicklung einer neuen Internetbank zu leiten, die innerhalb des Unternehmens vollständig entwickelt wurde. Zuerst habe ich die aktuellen Aufgaben herausgefunden, aber als ich im Backend ankam, wurde mir klar, dass es Zeit war, Scala zu implementieren.

Gerade kam Scala 2.9 mit moderner Syntax heraus. Trendige Parallelkollektionen waren perfekt geeignet, um etwas schnell parallel laufen zu lassen, wenn die Details nicht wichtig sind. Ja, und Groovy-Schöpfer James Strachan sagte: "Ich kann ehrlich sagen, wenn mir jemand das Programming Scala-Buch von Martin Odersky, Lex Spoon und Bill Venners aus dem Jahr 2003 gezeigt hätte, hätte ich Groovy wahrscheinlich nie geschaffen."

Ein weiterer Grund, warum Sie sich für Scala entschieden haben, ist, dass alle Leute, die damals an Werkzeugen, Sprachen, Bibliotheken gearbeitet oder über Scala geschrieben haben, sehr intelligent und tatkräftig waren. Daher bestand die Zuversicht, dass dies die richtige Wahl für die Zukunft war.

Gerade als ich bei der Bank gearbeitet habe, habe ich angefangen, Konferenzen im Ausland zu besuchen. Die ersten Scala Days 2012, die geeky flatMap in Oslo. Zu dieser Zeit traf ich Zhenya Burmako . Jetzt spazieren wir schon mal hier in Kalifornien am Meer entlang.

Scala-Entwickler einstellen

Allmählich schrieb eine Online-Bank. 2012 wurde er laut Global Finance der beste in Russland. Für mich ist dies eine Bestätigung der Aussage „Mach es normal, es wird normal sein“ und nichts Außergewöhnliches.

Oleg Tinkov hat das Thema der Bank beworben, was lustig war. Vielleicht hat uns das geholfen, gute Entwickler einzustellen - Leute waren im Team, aber ich wollte expandieren. Zuerst haben wir in der Stelle "Java-Programmierer, Scala - plus" geschrieben. Wenn Sie Java in Jobs für Scala-Entwickler erwähnen, werden Sie jedoch von Leuten abgeschnitten, die nichts mit Java zu tun haben möchten. Aus diesem Grund haben wir das Stellenangebot in Scala Senior Developer geändert. Dadurch konnte ich ein paar Leute einstellen, mit denen ich eines Tages sehr gerne arbeiten würde.

Facebook-Gruppe

Ich wollte verstehen, wer im Allgemeinen in Russland und Moskau auch unabhängig an Scala interessiert ist und welche Gedanken die Gemeinde hat. Es gab keine Meetings oder Chats und die Idee war, alle zu sammeln. Er hat eine Gruppe auf Facebook gegründet , in der wir die ersten Treffen geplant haben. Was ist ein Meeting ohne Gruppe bei Meetup ? Ich wollte etwas erschaffen, aber die Gruppe existiert bereits - Roman Timushev hat es erschaffen. Wir beschlossen, uns zusammenzuschließen, und fügten Mischa Aksarin hinzu.



Das erste Treffen wurde unter dem Vorwand eines Scala-Kurses über reaktives Programmieren auf Coursera abgehalten . Viele blickten, aber ungefähr 20 Leute kamen: Sie trafen sich, sagten, wen sie taten und interessierten, diskutierten die Übungen aus dem Kurs und einigten sich auf ein Wiedersehen.

Also fing es an.

Roman Elizarov: 10.000 Zeilen über Scala, Perfektionismus und gnadenlose Zusammenstellung

Roman Elizarov ( elizarov ) - Leiter der JetBrains-Gruppe, nahm an der Arbeit an Koroutinen und Bibliotheken in Kotlin teil.

Anmerkung des Autors . Bevor ich das Interview aufzeichnete, dachte ich, dass es eine Katastrophe wäre, wenn ich sie nur von Leuten nehmen würde, die an Scala beteiligt sind. Kontinuierliche "Anbetung" oder, schlimmer noch, "Fehler des Überlebenden". Aus diesem Grund habe ich beschlossen, der Salbe definitiv eine Fliege hinzuzufügen.

Dies ist schwieriger - Menschen mit wirklicher Erfahrung, die aus irgendeinem Grund nicht in die Sprache eingegangen sind, sind eine Größenordnung kleiner als Hasser mit null Erfahrung in Scala. Aber dann erinnerte ich mich an den Posten von Roman Elizarov ( elizarov ) - dem Anführer der JetBrains-Gruppe -, in dem er zwischen den Fällen auf die Scala kritzelte, was mehrere Burnouts verursachte, darunter auch meinen. Trotz des Negativen ist es unwahrscheinlich, dass Roman einen Beitrag zu Gerüchten über die Sprache verfasst hat. Es muss einen Grund geben, eine Art negative Erfahrung aus dem Gebrauch - es stellte sich heraus, dass dies so war. Im folgenden Interview mit ihm geht es nur um diese und einige Diskussionen über das Design und die Verbindung der Coroutine mit dem Scala CPS Plugin.

Fall im Jahr 2010

Roman Elizarov : Um das Jahr 2000 herum habe ich alle Arten von Eingaben in Java programmiert. Daher folgte ich JVM-Sprachen, einschließlich Scala. Es scheint, dass ich das erste Mal um 2005-2006 über die Sprache gelesen habe.

Wenn Sie abstrakt lesen, ist die Syntax ziemlich cool. Ich erinnere mich, die Beschreibung gelesen und herumgespielt zu haben, und mir hat wirklich alles gefallen. Viele Dinge in Java, die detailliert sind und mit denen man nur schwer arbeiten kann, sind in Scala einfach zu tun. Das alles hat mich schon damals interessiert, nicht aus der Sicht von FP, sondern aus der pragmatischen - wie wir den Code schreiben. Da die Java-Codebasis jedoch bereits sehr umfangreich ist, eine Reihe aktueller Klassen, konnte sie erst 2010 in der Praxis verwendet werden.

Im Jahr 2010 langweilten sich unsere Partner aus den USA, aus dem Unternehmen. Sie wollten eine Neuheit und schrieben ein neues Subsystem, das ausschließlich auf Scala basiert. Er hatte eine Art Webinterface, er machte etwas Einfaches. Dabei handelt es sich nicht um das Play Framework, sondern nur um einen Webdienst, der Anfragen von Benutzern erhält und als Java-API bezeichnet wird. Eine normale Website zum Ausführen einer Art von internen interaktiven Funktionen. Partner gash it, es hat erfolgreich funktioniert, alles ist in Ordnung.

Zu dieser Zeit waren wir ihre Auftragnehmer. Die Entwickler des Subsystems haben genug gespielt und beschlossen, andere Dinge zu tun. Unsere Kunden kommen zu uns und sagen: „Leute, nehmen Sie dieses Ding zur Unterstützung? Sie benutzt sowieso Ihre API. “ Großartig, hier ist es - eine echte Möglichkeit, es mit Scala zu versuchen. Niemand würde uns erlauben, in Scala zu programmieren, da alles schwierig ist. Da es aber bereits ein Projekt gibt, ist dies der Grund. Dies ist in der Tat die erste Produktionserfahrung mit Scala.

Der erste Eindruck von Scala ist, wie kompakt der Code ist als in Java . Mit Scala können Sie komplexe Dinge kompakt schreiben. Das Subsystem benötigte ungefähr 10.000 Codezeilen, aber in Java würde es aufgrund der Klassen doppelt so viel benötigen. Die Syntax, alle internen Objekte für die Datenübertragung, auch die gesamte Anpassung der Java-API sind kompakt.

Erste und letzte 10.000 Zeilen auf der Scala

Als die Entwickler gingen, ließen sie den Code unzusammengesetzt - in dem Sinne, dass es nur Code war . Wir haben versucht, es als Unterstützung zu nutzen, aber es gab ein Problem - die Kompilierung.

Das Kompilieren von Scala-Code ist eine Aufgabe. Der Code wird nur mit einer bestimmten Version von Scala Compiler kompiliert - auf die Punkteversion, auf die Patch-Version genau. Eine Version größer oder kleiner wird nicht mehr kompiliert .

Dies entschied für mich 2010 das Schicksal von Scala in Enterprise, wo es Millionen von Codezeilen gibt. Es ist beängstigend, sich vorzustellen, wie man lebt, wenn Sie die Nebenversion des Compilers ändern und dies nicht tun.

"Du erinnerst dich nicht genau warum?"

Roman Elizarov : Warum es auseinanderfiel, weiß ich natürlich nicht mehr. Etwas änderte sich ständig von Version zu Version. Vielleicht waren wir zur falschen Zeit?

Aber ich habe die Entwicklung von Scala weiter beobachtet, obwohl wir dies nur im Unternehmen nicht implementiert haben. Infolgedessen wurde die Funktionalität auf andere Java-Anwendungen übertragen. An dieser Stelle hörte Scala in dieser Firma auf zu existieren.

Diese 10.000 Zeilen waren die ersten und einzigen. Der Code hat lange in der Produktion funktioniert, wurde dann aber von anderen Diensten analysiert und entfernt.

Speziell für meine berufliche Tätigkeit hat diese Erfahrung einen bleibenden Eindruck hinterlassen, in dem Sinne, dass dennoch die Vereinbarkeit all dessen erforderlich ist. Jetzt mache ich Kotlin. Es ist nicht verwunderlich, dass wir unrealistisch viel Zeit und zusätzliche Kräfte aufwenden, um die Kompatibilität von allem und jedem zu gewährleisten. Manchmal geht eine wilde Menge an Zeit nicht in die Funktionalität, sondern nur damit alles kompatibel ist. Dies betrifft insbesondere meine bisherigen Erfahrungen.

Erinnere mich immer noch an Python. In Bezug auf die Kompatibilität haben wir zwei Fehler: Scala und Python. Wenn es um Kompatibilität geht, möchte niemand den Übergang von 2 zu 3 Python wiederholen, und niemand möchte so sein wie Scala.

"Perfekter Code"

- Oft möchten Sie etwas wiederholen, damit alles „Schokolade“ ist?

Roman Elizarov : Ich beschäftige mich mit Design und möchte ständig alles wiederholen . Mir gefällt nie, was ich getan habe. Während ich etwas für die Veröffentlichung vorbereite, finde ich ein paar Dinge, die ich ändern möchte. Sobald ich etwas unveröffentlicht habe, sehe ich bereits die Fehler darin: Es ist noch nicht abgeschlossen. Hier müssen wir es von Grund auf neu schreiben. Aber das ist der Weg ins Nirgendwo. Es gibt nur zwei Ansätze: Entweder werde ich den Code auf unbestimmte Zeit verbessern und nie zur Veröffentlichung gelangen, oder ich werde die Veröffentlichung starten und es wird Legacy. Sie können den perfekten Code nicht freigeben .

Dann verbringe ich die Hälfte der Zeit mit der Verbesserung des Produkts und die zweite Zeit mit der Kompatibilität mit dem, was ich bereits veröffentlicht habe. Erfahrung hilft, im Voraus „Strohhalme abzulegen“. Ich sehe, dass ich es bald wiederholen muss und viel Zeit zum Zeitpunkt der Veröffentlichung auf dem Sicherheitsnetz verbringen muss, um zukünftige Änderungen vorwegzunehmen. Natürlich ist es viel einfacher, etwas von Grund auf neu zu machen und sich nicht um Kompatibilität zu sorgen. Aber der Kompromiss ist, dass Sie es entweder perfekt machen oder dass sie Ihr Produkt verwenden. Eins schließt das andere aus.

Design bei Kotlin

Roman Elizarov : Ich bin Scala ständig gefolgt, denn wenn wir etwas in Kotlin entwerfen, lernen wir, was andere Sprachen haben, einschließlich Scala. Vor ungefähr zwei Jahren haben wir Kotlin-Koroutinen entworfen. Die Hauptinspiration ist natürlich C #. Mit ihm fing alles an und von da an war schon alles geboren. Dann fingen wir an, Go zu lernen.

Als das Design anfing, von C # abzuweichen und „Fortsetzungen“ und dann „begrenzte Fortsetzungen“ erschienen, begannen wir erneut, andere Sprachen zu studieren. Bei Google stoße ich auf Scala - es stellte sich heraus, dass darin bereits „ abgegrenzte Fortsetzungen “ waren.

- Sprechen Sie über Compiler Plugin?

Roman Elizarov : Ja. Gleichzeitig war das Design dem von Kotlin fantastisch ähnlich. Es gibt natürlich einen syntaktischen Unterschied: In Kotlin schreiben wir zu Beginn den Modifikator suspend, und in Scala haben Sie die Anmerkung csp zum Rückgabewert geschrieben. Aber was ist der Unterschied, wo der Modifikator platziert werden soll: in der Art der Rückgabewerte oder am Anfang?

Das Design in Scala war dem in Kotlin sehr ähnlich. Ich wurde interessiert - wie kommt es, dass ein so cooles Design warum nicht geflogen ist? Warum schreibt in der modernen Scala niemand so? Sie haben mir gezeigt, wie sie im Play Framework schreiben - dort gibt es kein Plugin.

Jeder schreibt Futures, und wir hatten eine großartige Idee, Futures loszuwerden, weil dieses Design praktischer ist. Und so geschah es in Kotlin: Futures werden nicht benötigt, es gibt Coroutinen. In Scala gaben sie die "Fortsetzungen" auf und flogen nicht. Warum?

Die Sinnlosigkeit und Rücksichtslosigkeit der Zusammenstellung

Bei der Suche habe ich die originellste Ankündigung gefunden . In diesem Jahr erschienen in Scala "abgegrenzte Fortsetzungen". In Scala wurde damals alles genauso gemacht wie jetzt in Kotlin.

Die Ankündigung in diesem Sinne ist indikativ. Es hieß: "Wir haben" abgegrenzte Fortsetzungen ", schauen Sie, wir können das gleiche coole Zeug schreiben wie in Lisp." Zum Beispiel haben wir ein Beispiel für Lisp aus den 80-90er Jahren genommen und es auf Scala umgeschrieben: Die Listen sind angedockt, hier „Shift / Reset“. In Lisp und ähnlichen Sprachen gibt es eine Konstruktion für begrenzte Fortsetzungen , die als „Verschieben / Zurücksetzen“ bezeichnet wird. Der Name explodiert im Gehirn - niemand weiß, was Shift / Reset ist. Weder einer, der Lisp studiert hat, noch einer, der ihn nie getroffen hat.

Die Hauptsache in dieser Ankündigung sind Kommentare wie diese: „Das ergibt ungefähr keinen Sinn. Ich habe gerade einige Zeit bei Wikipedia und einigen anderen Orten verbracht, um zu versuchen, dies zu verstehen. Aus meiner Sicht sind dies verschlungene Möglichkeiten, Zahlen hinzuzufügen, und ich habe keine Ahnung, was erreicht oder erreicht wird. " Sie erklären die Essenz der Post.

Daher ist eine solche Ankündigung eines wichtigen Merkmals absolut unbrauchbar. Wenn es von einer Person gelesen wird, die Code für die Anwendung schreibt, erhält sie keine Antwort auf die Frage: „Warum brauche ich das überhaupt? Welches Problem wird es lösen? “Der Autor hat eine solche Frage nicht gestellt. Daher hat das Feature nicht geflogen - nicht, weil es schlecht war, sondern weil es keine Aufgabe gab, zu fliegen .

"War sie falsch angewendet?"

Roman Elizarov : Ja, sie haben es falsch eingereicht. Es war wie angekündigt, aber sie erklärten nicht, warum es gebraucht wurde und welche Probleme es lösen konnte. Aber es geht nicht um „Richtigkeit“ oder Schönheit. Übrigens wissen wir bei Kotlin auch nicht, wie man schöne Blogposts schreibt, aber ein richtiger Post ist nicht genug, um eine schöne Ankündigung zu schreiben. Die korrekte Darstellung ist nicht nur eine Erklärung des Grundes, sondern auch eine Erklärung aus Sicht der API .

Ich habe den Code gelesen und dort werden die Shift / Reset-Methoden verwendet. Warum hieß es in den 70er Jahren Shift / Reset? Ich habe versucht, den Autor des Namens aus der Vergangenheit zu finden, konnte es aber nicht. Nur jemand hat sich diesen Namen ausgedacht. Für einen modernen Programmierer sagen diese Wörter überhaupt nichts aus. Sie bedeuten nichts.

Ich beschäftige mich so sehr mit Koroutinen, dass es den Anschein hat, als sollte ich alles über sie wissen, weil ich eine Reihe von wissenschaftlichen Artikeln lese. Aber wenn ich einen Code sehe, der "shift / reset" verwendet, bin ich jedes Mal bestrebt zu verstehen, was dort passiert und warum es überhaupt benötigt wird. Es scheint eine Art schwarze Magie zu sein, obwohl es bedeutungslos ist.

Alexey Fomkin: der verstorbene Flash, Voskhod und die ersten Treffen in Moskau

Alexey Fomkin ( yelbota ) - Programmierer, Sprecher, Podcast, Open Source-Mitarbeiter, Scala-Enthusiast.

Anmerkung des Autors . Nach dem Rückzug von Timushev und Uspensky ruhte die gesamte Bewegung in Moskau auf Alexey Fomkin . Außerdem startete er den Scalalaz- Podcast und schaute sich andere Podcasts an: DevZen , Debriefing , Remote Talk . Es wäre ein großer Fehler, es in dieser Artikelserie zu überspringen.

Von Ihrem Unternehmen zu einem Scala-Entwickler

Alexey Fomkin : Ich werde mich wahrscheinlich sehr langweilen - es gab nichts Interessantes. Ich habe meine persönliche Geschichte. Es ist interessant für mich, aber für Leser mag es langweilig sein.

Eigentlich war ich an Action-Script beteiligt und hatte später mein eigenes kleines Geschäft. Als das Geschäft geschlossen wurde, war ich ohne alles, weil Flash bis dahin gestorben war. Dementsprechend war nichts anderes in meinem Lebenslauf. Ich suchte Arbeit, war emotional deprimiert, weil ich alles verloren habe.

Ich habe mich nicht als technischen Direktor gesehen, nicht einmal als Teamleiter. Nach einem Misserfolg seiner Firma gab es nur Ambitionen für einen gewöhnlichen Programmierer. Ich habe versucht, einen JS-Entwickler in Yandex zu finden. Aber sie haben mich abgelehnt, weil ich ihn nicht gut kenne - was natürlich stimmte.

Dann dachte ich an Scala. Ich habe es viele Male versucht, seit 2010 - ich mag die Sprache. Ich habe es ausprobiert, weil es in dem Büro, in dem ich 2010 gearbeitet habe, Oaml gab. Ich wollte, wie OCaml, nur eine JVM haben - mir hat es gefallen. Nebenbei habe ich mehrere Projekte auf Scala geschrieben und 2014 angefangen, mich in meinem Unternehmen zu bewerben.

Es gab eine Idee, in Richtung Scala zu gehen: Es gibt viele Angebote, viele Projekte und Entwickler sind Mangelware. Dann habe ich mich angespannt und in ein paar Monaten mein gesamtes Wissen aktualisiert. Ich hatte Glück - ich bekam einen technischen Direktor und schrieb das Scala-Team.

Voskhod, Skype-Chat und Organisation der ersten Treffen

Gleichzeitig dachte ich, dass wir versuchen sollten, einige Dinge aufzurühren, bis das Thema in Russland nicht mehr sehr weit fortgeschritten ist. Er sprach mit Uspensky , Timushev und Askarin . Es stellte sich heraus, dass Askarin allein gelassen wurde - Uspensky war "auf den Koffern". Ich habe darüber gesprochen, Meetup zu machen oder nicht. "Ja, das sind wir." Und dies war der letzte Scherz, den das alte Team arrangierte. Es war in einer staatlichen Einrichtung, dem Forschungsinstitut "Voskhod". Ich ging dorthin, erzählte von Scala JS oder so, und dann starb dieses Thema ganz aus. Da alles so schlecht ist und es keine Aktivität gibt, habe ich beschlossen, alles selbst zu organisieren - ich fing an, in einem Skype-Chat aktiv zu werden, in dem die Rockies rumhingen.

- Wie viele Leute waren dort?

Alexey Fomkin : Ich erinnere mich nicht - es gibt nicht viele davon im modernen Chat. Das Rückgrat bilden 10-50 Personen, die ständig miteinander sprechen. Der Rest kommt, geht, stellt Fragen - genau wie jetzt.

Es war 2015: Skype-Chat, Scala.js, die ersten Treffen mit der Firma, in der er arbeitete. Wir haben Scala mächtig eingesetzt und ich habe Scala.js beworben. Ich ging in Podcasts zu allen möglichen JS-Entwicklern, sprach über Scala.js und rief Meetup auf.

2016 haben wir einen Podcast gestartet. Ich warf einen Schrei und reagierte auf viele Leute. Im Prinzip sind fast alle geblieben, außer Taranenko . Dann schlossen sich Grigory Pomadchin und Olya Makhasoeva an .

- Hat jemand mit den Mitaps geholfen? Ich war sauer, als du gegangen bist - als wäre alles ausgestorben.

Alexey Fomkin : In der Firma hat Max Pavlov geholfen. Er kann programmieren, aber mehr Manager. Ich war an Präsentationen beteiligt, der Scala-Teil, und Max half bei der Organisation: Räumlichkeiten, Ausrüstung, Registrierung.

Alles wurde von Data Monsters , aka Flexis, aka Adi Sait gesponsert - verschiedene Namen zu verschiedenen Zeiten. Ich habe gerade dort gearbeitet. Ein weiteres Meetup, das ich im Jahr 2018 verbracht habe. Er war allein

Nikolai Tatarinov: Play Framework, der erste Kurs und der St. Petersburger Zweig der Mitaps

Nikolai Tatarinov ist Entwickler bei SoundCloud, einem ehemaligen Veranstalter von SPb Scala Meetup.

Anmerkung des Autors . Nun zum St. Petersburger Zweig der Mitaps. Obwohl sie vor nicht allzu langer Zeit begonnen haben, haben bereits 9 Veranstaltungen stattgefunden. In Bezug auf die Qualität der Aufführung haben sie die Messlatte deutlich höher gelegt: ihren YouTube-Kanal , Live-Übertragungen.

Einer der Organisatoren ist Nikolai Tatarinov . Jetzt ist er zwar schon wegen Umzug in den Ruhestand gegangen, aber ich bin mit Standardfragen zu ihm gekommen. Nikolay sprach über den Einstieg in die Sprache, die Bewegung, die den Status des Play Frameworks vor Release 2.0 und das Schicksal von Actor Messaging leicht beeinflusste.

Rahmen spielen

Nikolai Tatarinov : Bei meinem ersten Job im Jahr 2012 haben wir das erste Play Framework verwendet. Es wurde in der Art von Rails gemacht. Es war interessant, weil wir eine Anwendung hatten, in der es einfach war, Änderungen vorzunehmen. Aber es war ein Prototyp - es entwickelte sich nicht zu einer Art Produktionssystem. Dort war alles gemischt - und es hat sich entwickelt.

Das erste Play Framework war Java und Groovy. , - — - Python-. , Maven Sbt. — Play Framework Play Framework .

, Play Framework , . — , « ».

Play Framework, , Scala, , — . - Play — . , — , . , . Play Framework , . , .

C Play Framework . , - , Scala . .

2013 — « Secon », . , — , - . , Scala. - , Scala Coursera.

Coursera

« Scala ». , , . , — , , . , , Scala .

Guava 7- Java. : . . , , , .

Scala

: 2014 . , , - Scala. 2015 , Actor . , Dialog , .

— Dialog Actor?

: . , Actor, Dialog. , Actor. , , .

, Actor, . Scala — . , Scala, - , — .

- Scala , — , . - , . , , .

, , . , , Java . — , . , - , . Scala.

, , Scala. SoundCloud. Scala.

: . IT Global Meetup — IT-, 2-3 . . — FProg Spb . : , , , , Coq.

. , Clojure, , — , Coq, , . .

, Scala. IT Global Meetup . , «Java Scala». , . , . , eLama, - , , Scala.

, Scala-, 50. Scala, . 2016 . , , . Slick, , Vodka .

Scala- 2017. , , , . , . . eLama" — .



Meetup DINS. , . — . , Meetup . , , 60-70 — . - .

. . , - . , - Excelsior JET, . , , .


PartialFunction .

« » — eax.me , , Scala 2013 . , , .

ScalaConf 2019 — (15 ) . Scala 26 . , « Hskell», — , Scala. ScalaConf 2019. .