Which server language to choose ... for a mobile developer
You’ll say what the mobile developer’s business is about what the backend is written on. The main thing is that the API there should be convenient, understandable, flexible. But we don’t think so.
At AppsConf, we all think that we sometimes need to go beyond the limits of mobile development and pump the hat of the letter T in the T-shape model. Here, for example, get to know server languages a little deeper than: "I heard that Ruby died." And a little wider - that is, not only with the popular ones, but also from the second rows and even underground ones.
To get you inspired by the idea of the Introductory track, we recorded an interview with Nikita Sobolev. They were going to talk about programming languages, but it turned out about programmers. Come under the cut, if you think that it is better to be just a good developer, and not an Android or iOS developer, and especially if you do not agree with this. Friday is the time to argue.
- How do you like the idea of a whole track of review reports on various technologies from the backend to the frontend at the conference on mobile development, which we called Introductory?
Nikita Sobolev CTO at wemake.services, author of the Repeatable Software Development Process methodology, organizer of ElixirLangMoscow, member of the Moscow Python Conf ++ program committee, frequent speaker at IT conferences and a champion for code quality .
In my opinion, this is the best track on a mobile conference.
I don’t really like the idea of narrow specialists. I’m much closer to the idea of a T-shape person - that is, a person who is well versed in one thing, but with a wide horizon of understanding problems in the subject area.
Unfortunately, it seems to me that mobile developers in this sense are on their own. The matter is compounded by the fact that they are very dependent on the vendor. Roughly speaking, Apple will close - they will leave in the cold.
Therefore, I really like the idea of the Introductory track and the fact that conference guests are invited to look around, find out what others have, adopt their experience and improve themselves as a specialist in terms of breadth of views.
- For what other conferences is this idea relevant?
For so many. I have at hand a Python example. Last time we invited Go, Elixir and Julia. This year I want to invite the front-end and the Haskellist (by the way, Call for Papers is already open ). Because Python developers are also different, many of them work as full-stack, it is also useful for them to get knowledge from the outside.
- Do you think that mobile developers have become more willing to look around, because it has become necessary for professional development, or has it always been so, just the community has matured?
It’s hard for me to judge for sure, the last time I wrote a mobile application in 2010. My main language then was Java, I took Objective-C and wrote an application for iOS. I was inspired, I thought, now I will start to do all this. But no: there was no memory management, there were no libraries, there were no dependency management, the build system was disgusting. Since then, I have not carefully looked into this area.
And now I see several trends that naturally attract mobile workers to “serious programming”.
In the past, languages were highly specialized in this area. Objective-C was only for development under Apple. And now, for example, they are trying to pull Swift to the server and do something on it. Java for the backend and for Android were two different languages. And now Kotlin is more or less similar for both. JavaScript has appeared in the world of mobile application development, and this is some kind of server language, and at the same time, a language for the frontend.
There is a single infrastructure that begins to interest people. If earlier (in my case this is 2010) mobile development was completely out of touch, now everything is different.
Moreover, rapprochement is on both sides. Tighter platform integration gives people the opportunity and the need to follow this integration.
- But if the integration itself goes to the mobile developer, why should he understand the languages for the backend?
I have a philosophical answer to this question.
It is clear that there is an entrance to each of these tools, the accumulation of practice and so on, but rigid fixation on one technology, in my opinion, is detrimental to the individual who is engaged in this.
At least technology is becoming obsolete. Languages that were popular 15 years ago are now almost never used. The skill of constantly developing and learning new things, looking at neighbors, is critically important for any developer. In particular, it is important to understand the backend, because the backend is fundamental for the entire development, today everything somehow communicates with the server.
In addition, for sure, mobility users are uncomfortable with other developers who find it easier to find a common language. The front-end and back-end are still closer than the developer of mobile applications to any of them. My report will help to some extent close the problem of human communication, help integrate.
How deep or superficial you need to understand is another question. Especially if we are talking about a mobile developer who, whatever one may say, needs to dig deep into his field.
I am for the fact that you need to actively look around and in the past. It is important to study the history of software and programming. If you don’t know the story, then you will reinvent so many things that you have already come up with and abandoned for completely objective reasons. I’m leading a telegram channel where I share links to cool open source projects without being tied to the language, I try to highlight important ideas.
- Does a mobile application developer have enough general ideas or not?
It depends, first of all, on the environment. If a person has a need to directly influence the backend in his company: to set more correct tasks for them, to participate in the process, possibly manage these people, then you will have to figure it out deeply.
But if you are only engaged in mobile development, then it’s enough to have a superficial idea of what is happening there, what languages, problems, popular solutions are. For such people my report on Saint AppsConf is also calculated. Naturally, a deep presentation cannot be given in one report.
- What else does a developer need to be a cool developer?
These skills, it seems to me, are enough. Everything else can either be deduced from these or discarded.
- So you think that you need to understand the subject area?
Limited, of course, but necessary. For example, we simultaneously have 3-4 projects, of course, I don’t understand all of them perfectly, but I understand the basic concepts with which I work. How they are interconnected, how they affect money, where is the expense, where is the income, why is all this necessary for business.
And I advise other developers too. In our company, we draw up documentation for them, how the business works, what problems we solve, why this cannot be solved by hands. Sometimes hiring a person so that he once, for example, went through a directory of goods, is cheaper. If we automate the process, you need to understand why.
- Let's look at an example. If you write a delivery service for a bakery, you have to understand how delivery works, but you don’t have to understand the types of buns that this bakery bakes?
And in some types of buns, too. Because some buns can be stored for an hour, and some two days. Accordingly, their delivery will be different.
- In your report, you promise to consider several popular languages at once, several languages from the second rows and several languages from deep underground. What kind of languages will they be?
I won’t take those languages that conference participants can already know: Kotlin, Java, JavaScript. It makes no sense to talk about them if most of the audience is already familiar with them. I decided to talk about languages that people are guaranteed not to know, because mobile applications do not write to them at all. There are plenty to choose from.
I basically love programming languages. Without a specific task. I like the programming language as an idea. Some people thought: “There is such a set of problems, they can be combined and solved all at once. Let's make a language for this. ” He will solve a specific list of problems. And another language will solve other problems, because usually all problems cannot be solved at once.
I really like to watch what problems each language solves and why it may be necessary in practice. Language itself becomes an object of intellectual art for me. A large number of people worked, thought, designed, optimized. This is very interesting, so I follow many programming languages.
Those languages that I chose for the report have several interesting characteristics. Firstly, they are controversial. None of them is a language that is ultimately good in everything in the consciousness of the community.
Everyone knows that Python is slow, but it is still the most popular language, it is used everywhere. I will try to explain why it is used.
And speaking of Ruby, the first thing people say is that Ruby is dead. In fact, Ruby developers now more than in any other language bother with architecture and implement a huge number of ideas from other languages - functional, object-oriented and make something very interesting out of it.
If we talk about Go, then Go has a very narrow scope of applicability, but in the wake of hype, everyone started to write on it.
- Do you think that you need to choose your language for each task, project?
This is a good idea, but it does not work in practice. Exactly where we started. There are Android programmers, there are Python programmers who, when you show them Ruby code, which is the same thing, only in profile, they say: “Oh no, everything is incomprehensible, I don’t want to understand”.
Of course, I would like people to be more versatile and able to choose an instrument for the task, but it turns out that people know one thing and always take this tool.
The hiring factor is also added here. For example, in our company, we could not choose from TypeScript and Python. But, if I need to hire an Elixir developer, I will look for him all my life. I know such developers, but not so much, and not so that I can quickly lure them to me. Therefore, you have to moderate your ambitions and adapt to the market and to customers, who also have a limited stack in accordance with the market.
- You promise a subjective look at almost 10 completely different languages. Are you really familiar with them all, did you write something on all of them?
With each in different ways, but, of course, I tried all of them at least to some extent.
For example, on Rust I write open source, and on pony I wrote 15 lines of code, read the tutorial, admired it, and now I want to show it to the conference participants. So that they too are inspired by the idea.
- Obviously, in one report you will not be able to give a complete picture and understanding of each language. Why should people go to your report and not google it?
The reason is that when a living person tells you, it’s completely different. A report to some extent is always a show. When people come to the show, they receive not only content, but also emotions. When you google, you get only content. If you are interested in it, you will google it anyway. And the format of the speech of a living person allows popularly and easily to get interesting knowledge.
- What will be the main elements of your “show”?
There are many languages, they are all cool, but there is nothing to write on.
There are many popular languages for solving your business problems: hiring, customers, libraries. But they all became popular for a reason. As a rule, the main reason is that they are very simple. They are based on simple concepts that are easy to start on, but hard to continue.
There are niche languages, and very interesting complex concepts are already appearing on which you can build something big and reliable: Rust with its excellent compiler, Elixir with its absolutely armor-piercing virtual machine, Haskell with its type system, etc. But they cannot become popular just because of the high entry threshold.
Most developers who want to learn something take popular languages and write them. And the question of why something else might be needed does not arise, because in those projects with which they work, nothing more complicated is required.
- Writing “Hello world” on Haskell is already a big feat, but is that not enough?
Yes, you need to boil in the community of functionaries. To listen to what problems they solve, what reports they make - so you can understand the section.
For example, in the Haskellist community, the entry problem is very acute. They still cannot solve it and make their language friendlier to beginners. Historically, Haskell uses a completely different syntax and completely different rules, just to write at least something. Even an experienced developer will at first be completely unclear what is happening in this code.
And it's not just about functional programming. If you start getting acquainted with the functionalities with Elixir, it will be much easier. Elixir is very similar in syntax to Ruby. At first, the difference will not be visible, you can write in the same way as in Ruby. And only then it becomes clear that this is a functional language. You do not notice this until some point, and then you discover additional opportunities for yourself. You understand that in fact it is built on completely different principles. Knowing this base, it becomes easy to switch to a less friendly functional language.
Order is important.
- In addition to popular languages and languages, as you say, of the second series, which is at least to some extent heard, you are going to introduce completely unknown ones. For example, what is this pony?
Pony is an open-source, object-oriented, actor-model, capabilities-secure, high-performance programming language. That is, strictly typified, memory safe, actor language. He is very young and very interesting.
Its developers create a language where you can create a very large number of actors, as in Elixir, but these actors are guaranteed type-safe. The limits of applicability of this language are still completely incomprehensible. But I would say that he can hit Go, and I actively support everything that can hit Go.
- If all languages have weaknesses and limitations, what to do? What to do with it?
Suffer. And keep looking for technical excellence. This is an unattainable dream of any engineer, but the process of finding this excellence is a great goal.
A bonus question for those who want to share their experience, but for some reason have not yet become a speaker. You often speak, why do you need it and what motivates you?
I have three goals:
A speaker at a conference can influence an industry through an audience. He from the rostrum can prove his point of view and motivate people to change.
At AppsConf, we all think that we sometimes need to go beyond the limits of mobile development and pump the hat of the letter T in the T-shape model. Here, for example, get to know server languages a little deeper than: "I heard that Ruby died." And a little wider - that is, not only with the popular ones, but also from the second rows and even underground ones.
To get you inspired by the idea of the Introductory track, we recorded an interview with Nikita Sobolev. They were going to talk about programming languages, but it turned out about programmers. Come under the cut, if you think that it is better to be just a good developer, and not an Android or iOS developer, and especially if you do not agree with this. Friday is the time to argue.
- How do you like the idea of a whole track of review reports on various technologies from the backend to the frontend at the conference on mobile development, which we called Introductory?
Nikita Sobolev CTO at wemake.services, author of the Repeatable Software Development Process methodology, organizer of ElixirLangMoscow, member of the Moscow Python Conf ++ program committee, frequent speaker at IT conferences and a champion for code quality .
In my opinion, this is the best track on a mobile conference.
I don’t really like the idea of narrow specialists. I’m much closer to the idea of a T-shape person - that is, a person who is well versed in one thing, but with a wide horizon of understanding problems in the subject area.
Unfortunately, it seems to me that mobile developers in this sense are on their own. The matter is compounded by the fact that they are very dependent on the vendor. Roughly speaking, Apple will close - they will leave in the cold.
Therefore, I really like the idea of the Introductory track and the fact that conference guests are invited to look around, find out what others have, adopt their experience and improve themselves as a specialist in terms of breadth of views.
- For what other conferences is this idea relevant?
For so many. I have at hand a Python example. Last time we invited Go, Elixir and Julia. This year I want to invite the front-end and the Haskellist (by the way, Call for Papers is already open ). Because Python developers are also different, many of them work as full-stack, it is also useful for them to get knowledge from the outside.
- Do you think that mobile developers have become more willing to look around, because it has become necessary for professional development, or has it always been so, just the community has matured?
It’s hard for me to judge for sure, the last time I wrote a mobile application in 2010. My main language then was Java, I took Objective-C and wrote an application for iOS. I was inspired, I thought, now I will start to do all this. But no: there was no memory management, there were no libraries, there were no dependency management, the build system was disgusting. Since then, I have not carefully looked into this area.
And now I see several trends that naturally attract mobile workers to “serious programming”.
In the past, languages were highly specialized in this area. Objective-C was only for development under Apple. And now, for example, they are trying to pull Swift to the server and do something on it. Java for the backend and for Android were two different languages. And now Kotlin is more or less similar for both. JavaScript has appeared in the world of mobile application development, and this is some kind of server language, and at the same time, a language for the frontend.
There is a single infrastructure that begins to interest people. If earlier (in my case this is 2010) mobile development was completely out of touch, now everything is different.
Moreover, rapprochement is on both sides. Tighter platform integration gives people the opportunity and the need to follow this integration.
- But if the integration itself goes to the mobile developer, why should he understand the languages for the backend?
I have a philosophical answer to this question.
If you want to be an Android developer, then you probably don’t need to understand the backend. And if you want to be just a developer - of course, it is necessary.A developer is someone who solves problems from the real world with code. Accordingly, decisions can occur everywhere, including in a mobile application, on a server, on a frontend. A good developer can solve in principle any real-world problem using development tools.
It is clear that there is an entrance to each of these tools, the accumulation of practice and so on, but rigid fixation on one technology, in my opinion, is detrimental to the individual who is engaged in this.
At least technology is becoming obsolete. Languages that were popular 15 years ago are now almost never used. The skill of constantly developing and learning new things, looking at neighbors, is critically important for any developer. In particular, it is important to understand the backend, because the backend is fundamental for the entire development, today everything somehow communicates with the server.
In addition, for sure, mobility users are uncomfortable with other developers who find it easier to find a common language. The front-end and back-end are still closer than the developer of mobile applications to any of them. My report will help to some extent close the problem of human communication, help integrate.
How deep or superficial you need to understand is another question. Especially if we are talking about a mobile developer who, whatever one may say, needs to dig deep into his field.
I am for the fact that you need to actively look around and in the past. It is important to study the history of software and programming. If you don’t know the story, then you will reinvent so many things that you have already come up with and abandoned for completely objective reasons. I’m leading a telegram channel where I share links to cool open source projects without being tied to the language, I try to highlight important ideas.
- Does a mobile application developer have enough general ideas or not?
It depends, first of all, on the environment. If a person has a need to directly influence the backend in his company: to set more correct tasks for them, to participate in the process, possibly manage these people, then you will have to figure it out deeply.
But if you are only engaged in mobile development, then it’s enough to have a superficial idea of what is happening there, what languages, problems, popular solutions are. For such people my report on Saint AppsConf is also calculated. Naturally, a deep presentation cannot be given in one report.
- What else does a developer need to be a cool developer?
- The ability to read and understand what is read.
- Ability to write, express your thoughts in writing.
- The ability to speak to express these thoughts verbally.
- Ability to listen and hear other people.
- Understanding the subject area. The developer must understand what he is doing, because he solves the problem of life in technical ways.
- And of course, understand the technique.
These skills, it seems to me, are enough. Everything else can either be deduced from these or discarded.
- So you think that you need to understand the subject area?
Limited, of course, but necessary. For example, we simultaneously have 3-4 projects, of course, I don’t understand all of them perfectly, but I understand the basic concepts with which I work. How they are interconnected, how they affect money, where is the expense, where is the income, why is all this necessary for business.
And I advise other developers too. In our company, we draw up documentation for them, how the business works, what problems we solve, why this cannot be solved by hands. Sometimes hiring a person so that he once, for example, went through a directory of goods, is cheaper. If we automate the process, you need to understand why.
- Let's look at an example. If you write a delivery service for a bakery, you have to understand how delivery works, but you don’t have to understand the types of buns that this bakery bakes?
And in some types of buns, too. Because some buns can be stored for an hour, and some two days. Accordingly, their delivery will be different.
- In your report, you promise to consider several popular languages at once, several languages from the second rows and several languages from deep underground. What kind of languages will they be?
I won’t take those languages that conference participants can already know: Kotlin, Java, JavaScript. It makes no sense to talk about them if most of the audience is already familiar with them. I decided to talk about languages that people are guaranteed not to know, because mobile applications do not write to them at all. There are plenty to choose from.
I basically love programming languages. Without a specific task. I like the programming language as an idea. Some people thought: “There is such a set of problems, they can be combined and solved all at once. Let's make a language for this. ” He will solve a specific list of problems. And another language will solve other problems, because usually all problems cannot be solved at once.
I really like to watch what problems each language solves and why it may be necessary in practice. Language itself becomes an object of intellectual art for me. A large number of people worked, thought, designed, optimized. This is very interesting, so I follow many programming languages.
Those languages that I chose for the report have several interesting characteristics. Firstly, they are controversial. None of them is a language that is ultimately good in everything in the consciousness of the community.
Everyone knows that Python is slow, but it is still the most popular language, it is used everywhere. I will try to explain why it is used.
And speaking of Ruby, the first thing people say is that Ruby is dead. In fact, Ruby developers now more than in any other language bother with architecture and implement a huge number of ideas from other languages - functional, object-oriented and make something very interesting out of it.
If we talk about Go, then Go has a very narrow scope of applicability, but in the wake of hype, everyone started to write on it.
Each of the languages that I have chosen to present during the speech has some kind of conflict.As a character in a good story. And the essence of the conflict is that some things work well, and some do not. This conflict will be at the head of the report.
- Do you think that you need to choose your language for each task, project?
This is a good idea, but it does not work in practice. Exactly where we started. There are Android programmers, there are Python programmers who, when you show them Ruby code, which is the same thing, only in profile, they say: “Oh no, everything is incomprehensible, I don’t want to understand”.
Of course, I would like people to be more versatile and able to choose an instrument for the task, but it turns out that people know one thing and always take this tool.
The hiring factor is also added here. For example, in our company, we could not choose from TypeScript and Python. But, if I need to hire an Elixir developer, I will look for him all my life. I know such developers, but not so much, and not so that I can quickly lure them to me. Therefore, you have to moderate your ambitions and adapt to the market and to customers, who also have a limited stack in accordance with the market.
- You promise a subjective look at almost 10 completely different languages. Are you really familiar with them all, did you write something on all of them?
With each in different ways, but, of course, I tried all of them at least to some extent.
For example, on Rust I write open source, and on pony I wrote 15 lines of code, read the tutorial, admired it, and now I want to show it to the conference participants. So that they too are inspired by the idea.
- Obviously, in one report you will not be able to give a complete picture and understanding of each language. Why should people go to your report and not google it?
The reason is that when a living person tells you, it’s completely different. A report to some extent is always a show. When people come to the show, they receive not only content, but also emotions. When you google, you get only content. If you are interested in it, you will google it anyway. And the format of the speech of a living person allows popularly and easily to get interesting knowledge.
- What will be the main elements of your “show”?
There are many languages, they are all cool, but there is nothing to write on.
There are many popular languages for solving your business problems: hiring, customers, libraries. But they all became popular for a reason. As a rule, the main reason is that they are very simple. They are based on simple concepts that are easy to start on, but hard to continue.
There are niche languages, and very interesting complex concepts are already appearing on which you can build something big and reliable: Rust with its excellent compiler, Elixir with its absolutely armor-piercing virtual machine, Haskell with its type system, etc. But they cannot become popular just because of the high entry threshold.
Most developers who want to learn something take popular languages and write them. And the question of why something else might be needed does not arise, because in those projects with which they work, nothing more complicated is required.
It is very important for the developer to understand the limitations of the tool.To understand the limitation, you need to rest against your forehead, fight a problem, and then step back and look at it from a distance. Only in the reports of people who have worked with something for many years does this manifest itself. And I am well acquainted with these people, I have accumulated various cases and I know where to rest against. And I can summarize my experience and that of other people.
- Writing “Hello world” on Haskell is already a big feat, but is that not enough?
Yes, you need to boil in the community of functionaries. To listen to what problems they solve, what reports they make - so you can understand the section.
For example, in the Haskellist community, the entry problem is very acute. They still cannot solve it and make their language friendlier to beginners. Historically, Haskell uses a completely different syntax and completely different rules, just to write at least something. Even an experienced developer will at first be completely unclear what is happening in this code.
And it's not just about functional programming. If you start getting acquainted with the functionalities with Elixir, it will be much easier. Elixir is very similar in syntax to Ruby. At first, the difference will not be visible, you can write in the same way as in Ruby. And only then it becomes clear that this is a functional language. You do not notice this until some point, and then you discover additional opportunities for yourself. You understand that in fact it is built on completely different principles. Knowing this base, it becomes easy to switch to a less friendly functional language.
Order is important.
- In addition to popular languages and languages, as you say, of the second series, which is at least to some extent heard, you are going to introduce completely unknown ones. For example, what is this pony?
Pony is an open-source, object-oriented, actor-model, capabilities-secure, high-performance programming language. That is, strictly typified, memory safe, actor language. He is very young and very interesting.
Its developers create a language where you can create a very large number of actors, as in Elixir, but these actors are guaranteed type-safe. The limits of applicability of this language are still completely incomprehensible. But I would say that he can hit Go, and I actively support everything that can hit Go.
- If all languages have weaknesses and limitations, what to do? What to do with it?
Suffer. And keep looking for technical excellence. This is an unattainable dream of any engineer, but the process of finding this excellence is a great goal.
Saint AppsConf in 10 days. The program committee selected 35 reports and 12 mitaps, among which each mobile developer will find ideas useful for solving daily tasks and for their professional and personal development. I'll meet you on October 21 and 22 in St. Petersburg!
A bonus question for those who want to share their experience, but for some reason have not yet become a speaker. You often speak, why do you need it and what motivates you?
I have three goals:
- Have fun, I really like conferences, it's fun and interesting.
- Local - find developers and customers.
- Global - to make our industry better . I see a lot of problems and I want to positively influence and make good out of bad.
A speaker at a conference can influence an industry through an audience. He from the rostrum can prove his point of view and motivate people to change.
All Articles