Siguiendo los pasos del movimiento ruso Scala. Parte 3

Esta es la parte final de la investigación del movimiento Scala en Rusia. En la primera parte, aprendí de Roman Grebennikov sobre Voronezh beau monde, C ++ y Erlang, y de Roman Timushev sobre el primer Akka y el nacimiento de las reuniones de Moscú. En la segunda parte, hablé con Alexander Podkhaluzin y Mikhail Mutsyanko : conociendo Scala, 2007, Scala Days, Scala Native, mudándome a Kotlin, que Scala es bueno para los bancos, los primeros eventos en San Petersburgo, Eclipse, Jason Zaugg, IDE y Scala Plugin



Durante la preparación de la segunda parte, Vladimir Uspensky ( vuspenskiy ) me dirigió a Alexander Podkhalyuzin , con quien grabamos una gran entrevista. Al día siguiente recibí un mensaje de Vladimir, pero ahora con su historia personal: Qiwi, Scala en Tinkoff, primeras reuniones, enlaces a blogs antiguos (gracias especiales por esto) y funcionalismo de 2008 de Rúnar, que se ejecuta en Java, - Esto sigue siendo sangre de los ojos, al menos inusual. Además, las historias de Roman Elizarov , Alexei Fomkin y Nikolai Tatarinov . Características de la contratación de desarrolladores de Scala, cursos en Coursera, "código perfecto", compilación "demoníaca", diseño en Kotlin, 10,000 líneas de código, banca por Internet Tinkoff, nuevamente Tinkoff, Play Framework, fallecieron reuniones de Flash, "Sunrise" y San Petersburgo - sobre todo esto en la parte final de la trilogía debajo del corte.

Vladimir Uspensky: Coursera, Tinkoff y características de contratación para Scala

Vladimir : En ese momento trabajaba en Qiwi y refactoricé una gran cantidad de código Java, pero aún así obtuve mucha agua y un repetitivo. Estaba atormentado, pero de alguna manera me humillé.

Después de un tiempo, fui a los blogs de Alexander Temerev y Vlad Patryshev . Vlad estaba a la vanguardia en la implementación de Java, según tengo entendido. Leí sobre Scala con ellos, comencé a notar menciones de construcciones extrañas para mí, como las opciones en Java . Incluso lancé esta opción en algún lugar de la producción. Hubo un manejo de errores perezoso más exótico en Java y un paralelismo en Java de orden superior por Rúnar Bjarnason . Todo esto explotó infernalmente el cerebro y se preguntaba cómo aplicarlo todo.

Cuando estudié ejemplos específicos, por ejemplo, de Daniel Spiewak : Scala for Java Refugees , esto era exactamente lo que me faltaba. Toda el agua y las extrañas inconsistencias como `_` vs `*` vs `?` Del código Java se han `_` vs `*` vs `?` , y la esencia permanece.

Era Scala 2.7 y, por decirlo suavemente, no era estable. Muchos proyectos lo han intentado para pruebas unitarias o clases de casos. Para agregar Scala a un proyecto Java, tenía que configurar la compilación conjunta en Maven . Pero decidí probar y agregué soporte a un proyecto no crítico en Qiwi. Todo funcionó, estaba muy feliz, pero ahí fue donde terminó.

Trabajar en la implementación de Tinkoff y Scala

De repente, me invitaron a Tinkoff para dirigir el desarrollo de un nuevo banco de Internet, que se desarrolló completamente dentro de la empresa. Al principio descubrí las tareas actuales, pero cuando llegué al backend, me di cuenta de que era hora de implementar Scala.

Acaba de salir Scala 2.9 con sintaxis moderna, en ese momento. Las colecciones paralelas de moda se adaptaban perfectamente para ejecutar algo rápidamente en paralelo, si los detalles no son importantes. Y el creador de Groovy James Strachan publicó : "Honestamente puedo decir que si alguien me hubiera mostrado el libro Programming Scala de Martin Odersky, Lex Spoon y Bill Venners en 2003, probablemente nunca hubiera creado Groovy".

Otro factor en la elección de Scala es que todas las personas que luego trabajaron en herramientas, lenguaje, bibliotecas o escribieron sobre Scala eran súper inteligentes y enérgicas. Por lo tanto, había confianza en que esta era la elección correcta para el futuro.

Justo mientras trabajaba en el banco, comencé a ir a conferencias extranjeras. Los primeros Scala Days en 2012, el geeky flatMap en Oslo. En ese momento conocí a Zhenya Burmako . Ahora a veces paseamos por el océano ya aquí en California.

Contratación de desarrolladores de Scala

Poco a poco escribió un banco en línea. En 2012, se convirtió en el mejor de Rusia según Global Finance . Para mí, esto es una confirmación de la afirmación "Hazlo normalmente, será normal", y no algo extraordinario.

Oleg Tinkov promovió el tema del banco, que fue divertido. Quizás esto nos ayudó a contratar buenos desarrolladores: había personas en el equipo, pero quería expandirme. Primero, escribimos en la vacante "Java-programmer, Scala - plus". Pero mencionar Java en los trabajos para los desarrolladores de Scala excluye a las personas que no quieren tener nada que ver con Java. Por lo tanto, cambiamos la vacante a Scala Senior Developer. Esto me permitió contratar a un par de personas con las que me gustaría trabajar algún día.

Grupo de Facebook

Quería entender quién, en general, en Rusia y Moscú, también estaba interesado independientemente en Scala, y qué pensaba la comunidad. No hubo reuniones ni charlas, y la idea era reunir a todos. Hizo un grupo en Facebook , en el que planeamos las primeras reuniones. ¿Qué es una reunión sin un grupo en Meetup ? Fui a crear, pero el grupo ya existe: Roman Timushev creó. Decidimos unir fuerzas y agregamos a Misha Aksarin .



La primera reunión se reunió con el pretexto de un curso Scala sobre programación reactiva en Coursera . Muchos miraron, pero vinieron unas 20 personas: se conocieron, dijeron a quién estaban haciendo y estaban interesados, discutieron los ejercicios del curso y acordaron reunirse nuevamente.

Entonces comenzó.

Roman Elizarov: 10,000 líneas sobre Scala, perfeccionismo y compilación despiadada

Roman Elizarov ( elizarov ) - líder del grupo JetBrains, participó en el trabajo sobre corutinas, bibliotecas en Kotlin.

Nota del autor . Antes de grabar la entrevista, pensé que sería un desastre si los tomara solo de personas involucradas en Scala. Continua "adoración" o, peor aún, "error del sobreviviente". Por lo tanto, decidí que definitivamente agregaría una mosca en la pomada.

Esto es más difícil: las personas con experiencia real que por alguna razón no han ingresado al idioma son un orden de magnitud más pequeño que los que odian y no tienen experiencia en Scala. Pero luego recordé la publicación de Roman Elizarov ( elizarov ), el líder del grupo JetBrains, en el que garabateó en el Scala entre los casos, lo que causó múltiples agotamientos, incluido el mío. A pesar de lo negativo, es poco probable que Roman haya escrito una publicación sobre algunos rumores sobre el idioma. Debe haber una razón, algún tipo de experiencia negativa por el uso: resultó de esa manera. Debajo de la entrevista con él se trata sobre esto, y algunas discusiones sobre el diseño y la conexión de la rutina con Scala CPS Plugin.

Caso en 2010

Roman Elizarov : Alrededor del año 2000, programé todo tipo de enterpasas en Java. Por lo tanto, seguí los lenguajes JVM, incluido Scala. Parece que la primera vez que leí sobre el lenguaje alrededor de 2005-2006.

Cuando lees de manera abstracta, la sintaxis es bastante buena. Recuerdo haber leído la descripción, jugar, y realmente me gustó todo. Muchas cosas en Java que son detalladas y difíciles de trabajar son fáciles de hacer en Scala. Todo esto me interesó entonces, no desde el punto de vista de FP, sino desde el pragmático, mientras escribimos el código. Pero, dado que el código base de Java ya es grande, un grupo de clases actuales, no fue posible usarlo en la práctica hasta que sucedió la historia en 2010.

En 2010, nuestros socios de los Estados Unidos, de la empresa, se aburrieron. Querían novedad, y escribieron un nuevo subsistema completamente en Scala. Tenía algún tipo de interfaz web, estaba haciendo algo simple. Al mismo tiempo, este no es Play Framework, solo un servicio web recibió solicitudes de los usuarios, llamado API de Java. Un sitio web normal para realizar algún tipo de funciones interactivas internas. Los socios lo cortaron, funcionó con éxito, todo está bien.

En ese momento éramos sus contratistas. Los desarrolladores del subsistema han jugado lo suficiente y decidieron hacer otras cosas. Nuestros clientes se acercan a nosotros y nos dicen: “Chicos, ¿toman esto como soporte? Ella usa tu API de todos modos. Genial, aquí está, una forma real de probar con Scala. Entonces, nadie nos permitiría programar en Scala, porque todo es difícil, pero como ya hay un proyecto, esa es la razón. Esta es, de hecho, la primera experiencia de producción con Scala.

La primera impresión de Scala es cuán compacto es el código que en Java . Scala te permite escribir cosas complejas de forma compacta. El subsistema tomó aproximadamente 10,000 líneas de código, pero en Java tomaría el doble debido a las clases. La sintaxis, todos los objetos internos para la transferencia de datos, incluso la adaptación completa de la API de Java son compactos.

Primera y última 10,000 líneas en Scala

Cuando los desarrolladores se fueron, dejaron el código sin ensamblar, en el sentido de que solo era código . Intentamos tomarlo como soporte, pero hubo un problema: la compilación.

Compilar el código Scala es una búsqueda. El código se compila solo con una versión específica de Scala Compiler, precisa para la versión de punto, para la versión de parche. Una versión más grande o más pequeña ya no se compila .

Esto decidió para mí en 2010 el destino de Scala en la empresa, donde hay millones de líneas de código. Da miedo imaginar cómo vivir si cambias la versión menor del compilador y no vas a hacerlo.

"¿No recordarás exactamente por qué?"

Roman Elizarov : Por supuesto que no se está desmoronando, por supuesto. Algo cambiaba constantemente de una versión a otra. Tal vez estábamos en el momento equivocado?

Pero seguí monitoreando el desarrollo de Scala, a pesar de que solo en la empresa no implementamos esto. Como resultado, la funcionalidad se transfirió a otras aplicaciones Java. En este Scala en esta empresa dejó de existir.

Estas 10,000 líneas fueron las primeras y únicas. El código funcionó durante mucho tiempo en la producción, pero luego fue analizado por otros servicios y eliminado.

Específicamente para mi actividad profesional, esta experiencia dejó una marca indeleble, en el sentido de que, sin embargo, se necesita la compatibilidad de todo esto. Ahora estoy haciendo Kotlin. No es sorprendente que simplemente pasemos una cantidad de tiempo poco realista y fuerzas adicionales para garantizar la compatibilidad de todo y de todo. A veces, una gran cantidad de tiempo no entra en la funcionalidad, sino simplemente para que todo sea compatible. En particular, mi experiencia pasada afecta esto.

Todavía recuerdo constantemente a Python. En cuanto a la compatibilidad, tenemos dos errores: Scala y Python. Cuando se trata de compatibilidad, nadie quiere repetir la transición de 2 a 3 Python, y nadie quiere ser como Scala.

"Código perfecto"

- ¿A menudo quieres rehacer algo para que todo sea "chocolate"?

Roman Elizarov : Estoy comprometido con el diseño y constantemente quiero rehacer todo . Nunca me gusta lo que hice. Mientras preparo algo para el lanzamiento, encuentro algunas cosas que quiero cambiar. Tan pronto como he publicado algo, ya veo los defectos: todavía no se ha completado, aquí tenemos que reescribirlo desde cero. Pero este es el camino a la nada. Solo hay dos enfoques: o mejoraré el código indefinidamente y nunca llegaré al lanzamiento, o lanzaré el lanzamiento y se convertirá en Legacy. No puedes liberar el código perfecto .

Luego dedico la mitad del tiempo a mejorar el producto y el segundo a la compatibilidad con lo que ya he lanzado. La experiencia ayuda a "poner pajitas" de antemano. Veo que tendré que rehacerlo pronto y pasar mucho tiempo en el momento del lanzamiento en la red de seguridad en previsión de futuros cambios. Por supuesto, hacer algo desde cero y no preocuparse por la compatibilidad es mucho más fácil. Pero el compromiso es que lo haces a la perfección o usan tu producto. Uno excluye al otro.

Design en Kotlin

Roman Elizarov : Seguí constantemente a Scala, porque cuando diseñamos algo en Kotlin, estudiamos lo que tienen otros idiomas, incluido Scala. Hace unos dos años, diseñamos las corutinas de Kotlin. La principal "inspiración" es, por supuesto, C #. Todo comenzó con él y de allí ya nació, eso es todo. Entonces comenzamos a estudiar Go.

Cuando el diseño comenzó a desviarse de C # y aparecieron "continuaciones", y luego "continuaciones delimitadas", comenzamos a estudiar otros idiomas una vez más. En Google, me tropiezo con Scala; resulta que ya había " continuaciones delimitadas " en él.

- ¿Estás hablando del plugin compilador?

Roman Elizarov : Sí. Al mismo tiempo, el diseño era increíblemente similar al que está ahora en Kotlin. Existe, por supuesto, una diferencia sintáctica: en Kotlin escribimos el modificador de suspensión al principio, y en Scala usted escribió la anotación csp en el valor de retorno. Pero, ¿cuál es la diferencia donde colocar el modificador: en el tipo de valores de retorno o al principio?

El diseño en Scala era muy similar al actual en Kotlin. Me interesé, ¿cómo es eso, ya que un diseño tan genial, por qué no voló? ¿Por qué nadie escribe así en el Scala moderno? Me mostraron cómo escriben en Play Framework: no hay ningún complemento allí.

Todos escriben futuros, y tuvimos una gran idea para deshacernos de los futuros, porque este diseño es más conveniente. Y así sucedió en Kotlin: no se necesitan futuros, hay corutinas. En Scala, abandonaron las "continuaciones" y no volaron. Por qué

La insensatez y la crueldad de la compilación.

En el proceso de búsqueda, encontré el anuncio más original. Ese año, "continuaciones delimitadas" aparecieron en Scala. En Scala, entonces todo se hizo igual que ahora en Kotlin.

El anuncio en este sentido es indicativo. Decía: "Hicimos" continuaciones delimitadas ", mira, podemos escribir las mismas cosas geniales que en Lisp". Por ejemplo, tomamos un ejemplo en Lisp de los trabajos de los años 80-90, y lo reescribimos en Scala: las listas están acopladas, aquí "shift / reset". En Lisp y lenguajes similares, hay una construcción para continuaciones delimitadas , que se designa como "shift / reset". El nombre explota el cerebro: nadie sabe qué es shift / reset. Ni uno que haya estudiado a Lisp, ni uno que nunca lo haya conocido.

Lo principal en este anuncio son comentarios como este: “Esto tiene casi cero sentido. Acabo de pasar un tiempo en Wikipedia y en algunos otros lugares para tratar de entender esto. Desde mi punto de vista, estas son formas complicadas de sumar números y no tengo idea de lo que se gana o logra ". Explican la esencia de la publicación.

Por lo tanto, tal anuncio de una característica importante es absolutamente inútil. Si lo lee una persona que escribe código para la aplicación, no recibirá una respuesta a la pregunta: “¿Por qué necesito esto? ¿Qué problema resolverá? ”El autor no planteó esa pregunta. Por lo tanto, la función no funcionó, no porque fuera mala, sino porque no había ninguna tarea para volar .

"¿Ella se aplicó mal?"

Roman Elizarov : Sí, lo archivaron mal. Fue como si se anunciara, pero no explicaron por qué era necesario y qué problemas podría resolver. Pero el asunto no es "lo correcto" o la belleza. Por cierto, en Kotlin tampoco sabemos cómo escribir hermosas publicaciones de blog, pero escribir una publicación adecuada no es suficiente para escribir un hermoso anuncio. La presentación correcta no es tanto una explicación de por qué, sino también una explicación desde el punto de vista de la API .

Leí el código, y allí se usan los métodos shift / reset. ¿Por qué se llamó shift / reset en los años 70? Traté de encontrar al autor del nombre del pasado, pero no pude. A alguien se le ocurrió este nombre. Para un programador moderno, estas palabras no dicen nada en absoluto. No significan nada.

Trato tanto con las rutinas que parece que debería saber todo sobre ellas, porque leo un montón de artículos científicos. Pero cuando veo un código que usa "shift / reset", me esfuerzo cada vez más por comprender lo que está sucediendo allí y por qué es necesario. Parece una especie de magia negra, sin sentido.

Alexey Fomkin: el fallecido Flash, Voskhod y las primeras reuniones de Moscú

Alexey Fomkin ( yelbota ) - programador, orador, podcast, colaborador de código abierto, entusiasta de Scala.

Nota del autor . Después de retirarse de los asuntos de Timushev y Uspensky , todo el movimiento en Moscú se basó en Alexey Fomkin . Además, lanzó el podcast Scalalaz y miró otros podcasts: DevZen , Debriefing , Remote Talk . Omitirlo en esta serie de artículos sería un gran error.

De su negocio a un desarrollador Scala

Alexey Fomkin : Probablemente estaré muy aburrido, no había nada interesante. Tengo mi historia personal Es interesante para mí, pero para los lectores puede ser aburrido.

En realidad, participé en Action-Script, y luego tuve mi propio pequeño negocio. Cuando el negocio cerró, me quedé sin todo, porque Flash ya había muerto. En consecuencia, no había nada más en mi currículum. Estaba buscando trabajo, estaba emocionalmente deprimido porque lo perdí todo.

No me veía como un director técnico, ni siquiera como un líder de equipo. Después de un fracaso con su compañía, solo había ambición para un programador ordinario. Traté de obtener un desarrollador JS en Yandex. Pero me rechazaron porque no lo conozco bien, lo cual era cierto, por supuesto.

Entonces pensé en Scala. Lo intenté muchas veces, comenzando en 2010: me gusta el idioma. Lo intenté porque en la oficina en la que trabajaba en 2010, estaba Oaml. Quería, como OCaml, solo tener una JVM, me gustó. Por otro lado, escribí varios proyectos en Scala, y en 2014 comencé a aplicar en mi empresa.

Hubo una idea para avanzar hacia Scala: hay muchas ofertas, muchos proyectos y los desarrolladores escasean. Luego me tensé y, en unos meses, detuve y actualicé todo mi conocimiento. Tuve suerte: conseguí un director técnico y escribí el equipo Scala.

Voskhod, chat de Skype y organización de las primeras reuniones.

Al mismo tiempo, pensé que deberíamos tratar de agitar algunas cosas, hasta que el tema no esté muy desarrollado en Rusia. Habló con Uspensky , Timushev y Askarin . Resultó que Askarin se quedó solo, Uspensky estaba "en las maletas". Hablé sobre hacer Meetup o no. "Sí, lo somos". Y este fue el último mitap que el viejo equipo arregló. Fue en alguna institución estatal, el Instituto de Investigación "Voskhod". Fui allí, le conté sobre Scala JS o algo así, y este tema desapareció por completo. Como todo es tan malo y no hay actividad, decidí organizar todo por mí mismo: comencé a estar activo en un chat de Skype, en el que los rockies estaban pasando el rato.

- ¿Cuánta gente había allí?

Alexey Fomkin : No recuerdo, no hay muchos en el chat moderno. La columna vertebral principal es de 10 a 50 personas que hablan constantemente. El resto viene, va, hace preguntas, como ahora.

Era 2015: chat de Skype, Scala.js, las primeras reuniones con la empresa en la que trabajaba. Usamos Scala con fuerza, y promoví Scala.js. Fui a todo tipo de desarrolladores de JS, en podcasts, hablé sobre Scala.js y llamé a Meetup.

En 2016, comenzamos un podcast. Lancé un grito y respondí a mucha gente. En principio, casi todos permanecieron, excepto Taranenko . Entonces Grigory Pomadchin y Olya Makhasoeva se unieron .

- ¿Alguien ha ayudado con los mitaps? Estaba molesto cuando te fuiste, como si todo se hubiera extinguido.

Alexey Fomkin : Dentro de la empresa, Max Pavlov ayudó. Él sabe programar, pero más gerente. Participé en presentaciones, la parte de Scala, y Max ayudó con la organización: locales, equipos, registro.

Todo fue patrocinado por Data Monsters , también conocido como Flexis, también conocido como Adi Sait, diferentes nombres en diferentes momentos. Estaba trabajando allí en ese momento. Otro Meetup que pasé en 2018. El estaba solo.

Nikolai Tatarinov: Play Framework, el primer curso y la rama de mitaps de San Petersburgo

Nikolai Tatarinov es desarrollador de SoundCloud, ex organizador de SPb Scala Meetup.

Nota del autor . Ahora sobre la rama de mitaps de San Petersburgo . Aunque comenzaron hace poco, ya se han realizado 9 eventos. En cuanto a la calidad del rendimiento, han elevado enormemente el listón: su canal de YouTube , transmisiones en vivo.

Uno de los organizadores es Nikolai Tatarinov . Aunque ahora ya se ha retirado debido a la reubicación, pero llegué a él con preguntas estándar. Nikolay habló sobre la entrada al lenguaje, el movimiento, afectó ligeramente el estado de Play Framework antes del lanzamiento 2.0 y el destino de Actor Messaging .

Marco de juego

Nikolai Tatarinov : En mi primer trabajo en 2012, usamos el primer Play Framework. Fue hecho a semejanza de Rails. Fue interesante porque teníamos una aplicación en la que era fácil hacer cambios. Pero estaba en un estado de prototipo: no evolucionó hacia algún tipo de sistema de producción. Todo se mezcló allí, y se desarrolló.

El primer marco de juego fue Java y 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. .