During the preparation of the second part, Vladimir Uspensky ( vuspenskiy ) directed me to Alexander Podkhalyuzin , with whom we recorded a huge interview. The next day I received a message from Vladimir, but now with his personal history: Qiwi, Scala in Tinkoff, first meetings, links to old blogs (special thanks for this), and functionalism from 2008 from RĂșnar, which runs in Java, - this
Vladimir Uspensky: Coursera, Tinkoff and hiring features for Scala
Vladimir : At that time I worked at Qiwi and refactored a lot of Java code, but still I got a lot of water and a boilerplate. I was tormented, but somehow humbled myself.
After some time, I went to the blogs of Alexander Temerev and Vlad Patryshev . Vlad was in the forefront in the implementation of Java, as I understand it. I read about Scala with them, began to notice mentions of constructions strange to me then, such as options in Java . I even launched this option somewhere in production. There were more exotic Lazy Error Handling in Java and Higher-Order Java Parallelism from RĂșnar Bjarnason . All this hellishly blew up the brain and was wondering how to apply it all.
When I studied specific examples, for example, from Daniel Spiewak : Scala for Java Refugees , this was exactly what I was missing. All the water and strange inconsistencies like
`_` vs `*` vs `?`
From the Java code are
`_` vs `*` vs `?`
, and the essence remains.
It was Scala 2.7 and, to put it mildly, it was not stable. Many projects have tried it for unit tests or Case Classes. To add Scala to a Java project, you had to configure joint compilation in Maven . But I decided to try and added support to one non-critical project in Qiwi. Everything worked - I was very happy, but that was where it ended.
Work at Tinkoff and Scala implementation
Suddenly, I was invited to Tinkoff to lead the development of a new Internet bank, which was fully developed within the company. At first I figured out the current tasks, but when I got to the backend, I realized that it was time to implement Scala.
Just came out Scala 2.9 with modern, at that time, syntax. Trendy parallel collections were perfectly suited to run something quickly in parallel, if the details are not important. Yes, and Groovy creator James Strachan issued : "I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
Another factor in choosing Scala is that all the people who then worked on tools, language, libraries, or wrote about Scala were super smart and energetic. Therefore, there was confidence that this was the right choice for the future.
Just while working at the bank, I started going to foreign conferences. The first Scala Days in 2012, the geeky flatMap in Oslo. At that time I met Zhenya Burmako . Now we sometimes stroll along the ocean already here in California.
Hiring Scala Developers
Gradually wrote an online bank. In 2012, he became the best in Russia according to Global Finance . For me, this is a confirmation of the statement âDo it normally, it will be normalâ, and not something extraordinary.
Oleg Tinkov promoted the topic of the bank, which was funny. Perhaps this helped us to hire good developers - people were on the team, but I wanted to expand. First, we wrote in the vacancy "Java-programmer, Scala - plus." But mentioning Java in jobs for Scala developers cuts off people who don't want to have anything to do with Java. Therefore, we changed the vacancy to Scala Senior Developer. This allowed me to hire a couple of guys with whom I would very much like to work someday.
Facebook group
I wanted to understand who, in general, in Russia and Moscow, was also independently interested in Scala, and what the community thought. There were no meetings or chats, and the idea was to gather everyone. He made a group on Facebook , in which we planned the first few meetings. What is a meeting without a group at Meetup ? I went to create, but the group already exists - Roman Timushev created. We decided to join forces, and added Misha Aksarin .
The first meeting was gathered under the pretext of a Scala course on reactive programming on Coursera . Many peered, but about 20 people came: they met, told who they were doing and were interested in, discussed the exercises from the course and agreed to meet again.
So it started.
Roman Elizarov: 10,000 lines on Scala, perfectionism and merciless compilation
Roman Elizarov ( elizarov ) - leader of the JetBrains group, participated in work on coroutines, libraries in Kotlin.
Note by the author . Before recording the interview, I thought that it would be a disaster if I took them only from people involved in Scala. Continuous âadorationâ or, worse, âsurvivor's mistakeâ. Therefore, I decided that I would definitely add a fly in the ointment.
This is more difficult - people with real experience who for some reason havenât entered the language are an order of magnitude smaller than haters with zero experience in Scala. But then I remembered the post of Roman Elizarov ( elizarov ) - the leader of the JetBrains group - in which he scribbled on the Scala between the cases, which caused multiple burnouts, including mine. Despite the negative, it is unlikely that Roman wrote a post on some rumors about the language. There must be a reason, some kind of negative experience from use - it turned out that way. Below the interview with him is just about this, and some discussions about the design and connection of coroutine with Scala CPS Plugin.
Case in 2010
Roman Elizarov : Around the year 2000, I programmed all kinds of enterpases in Java. Therefore, I followed JVM languages, including Scala. It seems that the first time I read about the language around 2005-2006.
When you read abstractly, the syntax is pretty cool. I remember reading the description, playing around, and I really liked everything. Many things in Java that are detailed and hard to work with are made handy in Scala. All this interested me already then not from the point of view of FP, but from the pragmatic one - as we write the code. But, since the code base in Java is already large, a lot of current classes, it was not possible to use in practice until the story happened in 2010.
In 2010, our partners from the United States, from the enterprise, got bored. They wanted novelty, and they wrote a new subsystem entirely on Scala. He had some kind of web-interface, he was doing something simple. At the same time, this is not the Play Framework - just a web-service received requests from users, called the Java API. A normal web site to perform some kind of internal interactive functions. Partners gash it, it worked successfully, everything is fine.
At that time we were their contractors. The developers of the subsystem have played enough and decided to do other things. Our customers come to us and say: âGuys, take this thing for support? She uses your API anyway. â Great, here it is - a real way to try with Scala. So no one would allow us to program in Scala, because everything is tough, but since there is already a project, thatâs the reason. This is, in fact, the first production experience with Scala.
The first impression of Scala is how compact the code is than in Java . Scala lets you write complex things compactly. The subsystem took about 10,000 lines of code, but in Java it would take twice as much because of the classes. The syntax, all internal objects for data transfer, even the entire adaptation of the Java API are all compact.
The first and last 10,000 lines on Scala
When the developers left, they left the code unassembled - in the sense that it was just code . We tried to take it for support, but there was a problem - compilation.
Compile Scala code is a quest. The code compiles only with a specific version of Scala Compiler - accurate to the point version, to the patch version. A version larger or smaller is no longer compiled .
This decided for me in 2010 the fate of Scala in enterprise, where there are millions of lines of code. Itâs scary to imagine how to live if you change the minor version of the compiler and are not going to.
âYou wonât remember exactly why?â
Roman Elizarov : Why it was falling apart I donât remember, of course. Something was constantly changing from version to version. Maybe we were in a bad time?
But I continued to monitor the development of Scala, despite the fact that only in the enterprise we did not implement this. As a result, the functionality was transferred to other Java applications. At this Scala in this company ceased to exist.
These 10,000 lines were the first and only. The code worked for a long time in production, but then it was parsed by other services and eliminated.
Specifically for my professional activity, this experience left an indelible mark, in the sense that, nevertheless, the compatibility of all this is needed. I'm doing Kotlin right now. It is not surprising that we simply spend an unrealistic amount of time and additional forces to ensure the compatibility of everything and everything. Sometimes a wild amount of time does not go into functionality, but simply so that everything is compatible. In particular, my past experience affects this.
Still constantly remember Python. Regarding compatibility, we have two bugs: Scala and Python. When it comes to compatibility, no one wants to repeat the transition from 2 to 3 Python, and no one wants to be like Scala.
"Perfect code"
- Often you want to redo something so that everything is âchocolateâ?
Roman Elizarov : I am engaged in design and I constantly want to redo everything . I never like what I did. While I'm preparing something for release, I find a few things that I want to change. As soon as Iâve unreleased something, I already see the flaws in it: itâs not completed yet, here it is necessary to rewrite it from scratch. But this is the road to nowhere. There are only two approaches: either I will improve the code ad infinitum and never get to the release, or I will launch the release and it will become Legacy. You canât release the perfect code .
Then I spend half the time on improving the product, and the second on compatibility with what I have already released. Experience helps to âlay strawsâ in advance. I see that Iâll soon have to redo it, and spend a lot of time at the time of release on safety net in anticipation of future changes. Of course, doing something from scratch and not care about compatibility is much easier. But the compromise is that you either do it perfectly, or they use your product. One excludes the other.
Design at Kotlin
Roman Elizarov : I constantly followed Scala, because when we design something in Kotlin, we study what is in other languages, including Scala. About two years ago, we designed Kotlin coroutines. The main âinspirationâ is, of course, C #. It all started with him and from there already was born that's all. Then we began to study Go.
When the design began to deviate from C # and âcontinuationsâ appeared, and then âdelimited continuationsâ, we began to study other languages ââonce again. At Google, I stumble upon Scala - it turns out there were already â delimited continuations â in it.
- Are you talking about Compiler Plugin?
Roman Elizarov : Yes. At the same time, the design was fantastically similar to the one that is now in Kotlin. There is, of course, a syntactical difference: in Kotlin we write the suspend modifier at the beginning, and in Scala you wrote the csp annotation on the return value. But what's the difference where to put the modifier: in the type of return values ââor in the beginning?
The design in Scala was very similar to the current in Kotlin. I became interested - how is it, since such a cool design, why didnât it fly? Why doesnât anyone write like that in modern Scala? They showed me how they write in the Play Framework - there is no plugin there.
Everyone writes futures, and we had a great idea to get rid of futures, because this design is more convenient. And so it happened in Kotlin: futures are not needed, there are coroutines. In Scala, they abandoned the "continuations" and did not fly. Why?
The senselessness and ruthlessness of compilation
In the search process, I found the most original announcement . That year, âdelimited continuationsâ appeared in Scala. In Scala then everything was done the same as now in Kotlin.
The announcement in this sense is indicative. It said: "We did" delimited continuations ", look, we can write the same cool stuff as in Lisp." For example, we took an example on Lisp from the works of the 80-90s, and rewrote it on Scala: the lists are docked, here is âshift / resetâ. In Lisp and similar languages, there is a construction for delimited continuations , which is designated as âshift / resetâ. The name explodes the brain - no one knows what shift / reset is. Neither one who has studied Lisp, nor one who has never met him.
The main thing in this announcement is comments like this: âThis makes about zero sense. I just spent some time on Wikipedia as well as a few other places to try to understand this. From my perspective, these are convoluted ways of adding numbers and I have no idea what is being gained or accomplished. " They explain the essence of the post.
Therefore, such an announcement of an important feature is absolutely useless. If it is read by a person who writes code for the application, he will not receive an answer to the question: âWhy do I need this at all? What problem will this solve? âThe author did not raise such a question. Therefore, the feature did not fly - not because it was bad, but because there was no task to fly .
âWas she misapplied?â
Roman Elizarov : Yes, they filed it wrong. They seemed to announce it, but did not explain why it is needed and what problems it can solve. But the matter is not "correctness" or beauty. By the way, we in Kotlin also do not know how to write beautiful blog posts, but to write a proper post is not enough to write a beautiful announcement. The correct presentation is not so much an explanation of why, but also an explanation from the point of view of the API .
I read the code, and there the shift / reset methods are used. Why was it called shift / reset in the 70s? I tried to find the author of the name from the past, but could not. Just someone came up with this name. To a modern programmer, these words do not say anything at all. They mean nothing.
I deal with coroutines so much that it seems that I should know everything about them, because I read a bunch of scientific papers. But when I see the code that uses âshift / resetâ, I strain every time to understand what is happening there and why it is needed at all. It seems like some kind of black magic, while meaningless.
Alexey Fomkin: the deceased Flash, Voskhod and the first Moscow meetings
Alexey Fomkin ( yelbota ) - programmer, speaker, podcast, Open Source contributor, Scala enthusiast.
Note by the author . After retreating from the affairs of Timushev and Uspensky , the whole movement in Moscow rested on Alexey Fomkin . In addition, he launched the Scalalaz podcast, and looked at other podcasts: DevZen , Debriefing , Remote Talk . Skipping it in this series of articles would be a big mistake.
From your business to a Scala developer
Alexey Fomkin : I probably will be very bored - there was nothing interesting. I have my personal story. It is interesting to me, but for readers it may be boring.
Actually, I was involved in Action-Script, and later I had my own small business. When the business closed, I was left without everything, because Flash had died by then. Accordingly, there was nothing else in my resume. I was looking for work, I was emotionally depressed because I lost everything.
I didnât see myself as a technical director, not even a team leader. After a failure with his company, there was only ambition for an ordinary programmer. I tried to get a JS developer in Yandex. But they refused me because I do not know him well - which was true, of course.
Then I thought of Scala. I tried it many times, starting in 2010 - I like the language. I tried it because in the office in which I worked in 2010, there was Oaml. I wanted, like OCaml, just to have a JVM - I liked it. On the side, I wrote several projects on Scala, and in 2014 I already started applying it in my company.
There was an idea to move towards Scala: there are many offers, many projects, and developers are in short supply. Then I tensed up and in a few months pulled up and updated all my knowledge. I was lucky - I got a technical director and typed the Scala-team.
Voskhod, Skype chat and the organization of the first meetings
At the same time, I thought that we should try to stir up some things, until the topic is not very developed in Russia. I talked with Uspensky , Timushev and Askarin . It turned out that Askarin was left alone - Uspensky was "on the suitcases." I talked about doing Meetup or not. âYes, we are.â And this was the last mitap that the old team arranged. It was in some state institution, Research Institute âVoskhodâ. I went there, told about Scala JS or something, and then this topic died out altogether. Since everything is so bad and there is no activity, I decided to organize everything myself - I began to become active in a Skype chat, in which the rockies were hanging out.
- How many people were there?
Alexey Fomkin : I donât remember - there are not many of them in modern chat. The main backbone is 10-50 people who are constantly talking. The rest come, go, ask questions - just like now.
It was 2015: Skype chat, Scala.js, the first meetings with the company in which he worked. We used Scala powerfully, and I promoted Scala.js. I went to all kinds of JS developers, in podcasts, talked about Scala.js and called on Meetup.
In 2016, we started a podcast. I threw a cry and responded to a lot of people. In principle, almost everyone has remained, except Taranenko . Then Grigory Pomadchin and Olya Makhasoeva joined in .
- Has anyone helped with the mitaps? I was upset when you left - as if everything had died out.
Alexey Fomkin : Inside the company Max Pavlov helped. He knows how to program, but more a manager. I was engaged in presentations, the Scala part, and Max helped with the organization: premises, equipment, registration.
Everything was sponsored by Data Monsters , aka Flexis, aka Adi Sait - different names at different times. I worked there just then. Another Meetup I spent in 2018. He was alone.
Nikolay Tatarinov: Play Framework, the first course and the St. Petersburg branch of mitaps
Nikolai Tatarinov is a developer at SoundCloud, a former organizer of SPb Scala Meetup.
Note by the author . Now about the St. Petersburg branch of mitaps. Although they started not so long ago, 9 events have already taken place. In terms of the quality of the performance, they have greatly raised the bar: their YouTube channel , live broadcasts.
One of the organizers is Nikolai Tatarinov . Although now he has already retired due to relocation, but I came to him with standard questions. Nikolai spoke about the entry into the language, the movement, slightly affected the status of the Play Framework before release 2.0 and the fate of Actor Messaging .
Play framework
Nikolai Tatarinov : At my first job in 2012, we used the first Play Framework. It was made in the likeness of Rails. It was interesting because we had an application in which it was easy to make changes. But it was in a state of prototype - it did not evolve into some kind of production system. Everything was mixed there - and it developed.
The first Play Framework was Java and 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 â . - .
That's all
. . , - . , - Excelsior JET, . , , .
PartialFunction .
« » â eax.me , , Scala 2013 . , , .
ScalaConf 2019 â (15 ) . Scala 26 . , « Hskell», â , Scala. ScalaConf 2019. .