Baruch Sadogursky, JFrog: Developer Advocate, Java 9 and Kotlin's world domination (but you better look at Groovy)
In early November, the JavaDay conference will be held in Kiev for the seventh time. We talked to her regular speaker Baruch jbaruch Sadogursky - Developer Advocate in JFrog. During the conversation, we managed to discuss:
- Features of the work of the Developer Advocate: why it should not promote the products of the employer
- Java 9 and Java release frequency on the example of minibuses and trains
- Kotlin and his way to world domination
Your post sounds like Developer Advocate? As far as I understand, this is a certain analogue of the evangelist, right?
Yes, an analogue of the evangelist, but not quite. The very concept of “evangelism” bears a religious coloring in the context of conveying to the people of the truth about a single right decision. This is not what I do. At least I would like to believe it. An evangelist is one who tells how to do it right. Advocate in English, although initially has no legal value, as in Russian, but implies protection, representation of interests. That's the difference.
')
Defender of interests of developers. This implies an understanding of the wishes of the developers, the community - and reporting them within the company?
This is one of the directions. The second, no less important, is to help developers solve certain problems even without using (although, of course, it’s better using) the products of the company that pays my salary. I can say: "Guys, use Artifactory, because it will help solve your problems." And sometimes I can say: "Do not use it better - it will not help you here." I will be praised for both options, but, of course, it is better when I I can use the first one.
Where, then, is the line between promoting a company's product and the professional work of Developer Advocate?
The fact is, how much do you understand the needs of those with whom you work. As far as you are able to help solve their problems, putting their interest above the interests of the product that you promote. Roughly speaking, if you are able to say: do not take our product - it will not help you now , then you are a professional Developer Relations. And if you are still promoting the product, because you didn’t listen, didn’t understand the developer, this is unprofessional.
Should Developer Advocate be a developer at the same time? For example, to keep yourself in shape and understand the needs of the community.
Required. And it's not in shape. Without writing code, you will not understand the needs of people - and you will not fulfill your duties. Be sure to write code, understand technology, “play” with them. Yes, and it's just interesting and pleasant.
What should be the balance between marketing and development components? How often do you code?
Getting back to the core of work, marketing is not part of developer relations. Developer Advocate in the company most often very little. Now there are 250 people working for JFrog and only one advocate. Although soon there will be three of us. But for a company of 250 people, even this is not enough. Therefore, under this function usually do not allocate a department, and attached to another unit.
Developer Advocate can work anywhere, but not in the sales department. In our case, I belong to the marketing. I do not do marketing in pure form, but rather prepare the ground for it. After a person listens on my report on how JFrog products can be useful to him, he can become a leader with whom marketing will work.
In terms of the relationship between relations and development, the ideal ratio would be 50/50. Unfortunately, there are few people - there is a lot of work, so the technical part has to be “picked up” during off-hours. For example, I'm going to JavaDay, including to listen to the latest news, to try out new technologies on myself. The debriefing podcast has the same goals for me. I do not try to promote anything there for work, but on the contrary - to study and listen in order to stay informed. I really hope that when I dial a team, I will finally have time to do this during working hours.
That is, you like to drive and perform. But you also like to write code?
I really like to drive and write code. If I could do both in the 50/50 ratio ... I already have a perfect job, but it would be a little bit more perfect.
Developer Relations Professionalism - be honest with yourself. But the employer certainly puts some KPI? How is work performance measured?
The influence can be measured, but it is very difficult and expensive. At an early stage, companies are not willing to invest in measuring the impact of a Developer Relations specialist on the community. In many companies, influence either doesn’t measure at all, or relies on very simple and naive metrics such as the number of followers on Twitter or the people who attended the report. But how many people came to speak depends on two things: how much the report has a scandalous name, and who spoke in parallel. If with me in parallel there were stars of the first magnitude, like those that are already hanging on the JavaDay site, then no one will come to me even for a terrific report. This is an example of KPIs that do not make any sense.
Which KPIs are really important? How much my report caught people? Let's look at the example of Yegor Bugayenko. His reports are very "catchy" people. Is it good or bad? Does his Developer Relations improve or worsen? Egor speaks for the sake of hiring. In this case, everything is simple: if three people after his report came to work for him, then the report was good. It does not matter that another 100 people could be potentially dissatisfied with the report.
And if it's not hiring, but a product, platform, API? How many people after the report registered? And how do you know that they came after the conference, and not because the article on the blog came out on the same day? Nevertheless, I believe that it is possible to measure, although this is not a trivial task.
You have been confirmed as a speaker on JavaOne again. What are you going to do?
There have not yet received answers for all my reports, since most of my reports still concern DevOps. I hope that they will receive a lot of my tech reports, for example, about Docker. On the main stream in Java, one report on voice user interfaces has so far been received. Let's make one of our two favorite formats: Alexa vs Google Home . We will write some kind of extension for them, and in the process we will compare the decisions that Amazon and Google made in the context of design and integration for third-party extensions.
In July, you entered the Top 20 Java Influencers 2017 list. How important are hit in such ratings for Developer Advocate? Why did you get into it, do you think?
Last year, the organizers made this rating for the first time, and we - those who did not get there - terribly trolled those who got there. The fact is that the rating is based precisely on those meaningless metrics that we talked about earlier. The guys just took Klout - a platform that builds influence ratings in social networks based on user interaction. But, in fact, the platform is rather naive and, as I said, the impact is still difficult to measure. But this year I got there! And that's all, Klout at once is the most serious and truthful tool for measuring influence over minds! (Just kidding of course. It's a trifle, but nice).
Oracle recently cut all evangelists. Did he probably have enough money to measure their effectiveness?
An excellent indicator of whether they were cut in vain or not, do you know their names. If you read the news that the evangelists were fired, and you never heard about them, then the specialists from them were so-so. In the case of Oracle, there were also famous people like Simon Ritter - and not so much. Their reduction of any damage to Java or the company did not cause.
Don't you think that now there is no one to promote Java 9, which is not yet very popular?
The answer is twofold. No Developer Relations can promote a bad product. If people understand that they do not like what is in the “nine”, then no one can convince them. A year ago, the release was more than problematic. If I worked in Oracle in the position of the Developer Advocate, then I would criticize, at least internally, these solutions.
Now the situation has changed a bit. Oracle was forced to change the concept, to abandon the aggressive promotion of modules that will be in the nine "under the hood", and transferring the entire community to them was transferred in the direction of Java 10. This makes the "nine" a fairly harmless update. So, from the situation “oh no, I will not upgrade, because it will break everything”, we went into the situation “it is possible and proapdate - probably there are some nishtyaks”. And in this state of affairs, the lack of a Developer Relations in Oracle is bad for Java. It is no longer necessary to protect the modularity, but it is necessary to disclose the advantages that are in the new release - and not all are obvious.
Let's imagine that Oracle has Baruch on his salary. Would you promote Java 9? What exactly would like to convey to developers?
Yes, of course, now we can talk about a lot of positive aspects of Java 9. The biggest feature that caused the greatest number of debates and rejections is Jigsaw. His previous reincarnation promised to break everything, but now it has been removed from the agenda. Almost everything that works in Java 8 will work almost unchanged and in the "nine". Therefore, we can talk about other features.
For example, there are novelties in the syntax of the language - incubator projects - that will allow you to try some things aimed at 10 and beyond, like the new HttpClient. Yes, it will not be such a giant release as 5-ka or 8-ka. Java 9 will be a more minor stabilizing release, like 7-ka. But there is something to talk about in it - and there are reasons to suggest upgrading.
How much is delay and adaptation harm the development of the language? Oracle, on the other hand, had the idea of ​​reducing development cycles in order to release new versions more than once every five years.
Yes, now there is a discussion about whether Java releases should be “minibuses” or “trains”. "Minibus" comes out when it is full. That is, there is a specific set of features that are scheduled in a particular release. It will be released when all the features are ready - the minibus is full. The “train” is on schedule: those who managed - left, who did not - are waiting for the next train. Until now, Java releases have been a “minibus”. The “departure” of Java 9 was constantly postponed, because everyone was waiting for the modules to be ready.
Now in Oracle, there is a shift towards the “train” with the release date assigned. This, most likely, will lead us to releases “in one”, when the larger will be followed by a more “cosmetic” one. That is, if the next phase of the modules (the one that breaks everything to everyone) enters the “top ten”, and most likely there will be no major changes in Java 11. Just do not have time to write.
Are you for “minibus” or for “train”?
It seems to me that the "train" is more correct. This approach will greatly reduce the stress on project owners of Oracle. In the case of a “minibus”, they must rush headlong, make compromises in quality, but have time to release - or be guilty of being delayed again.
I think Java 8 just ran into this problem. To put it mildly, it was problematic in terms of quality and in terms of bugs, documentation and design decisions. Although Java remains more stable than many other languages ​​(even on a stable JVM), the G8 was surprisingly crude by Java standards. Probably the pressure to have time to “fill in a minibus” was the reason. In the case of regular releases (they didn’t have time for this - will be released next), such a problem will most likely be avoided.
Can Java be developed on the basis of continuous delivery?
I very much doubt, because you shouldn't forget about the platform we are dealing with. She is an adult. Many conservative enterprise customers rely on it. Upgrades are not fast, and the constant release of new versions creates some pressure. “Three versions have already been released, but we still have not updated!” They are not ready for this. Therefore, doing continuous delivery for developers is possible. But I doubt very much that it makes sense to post the long term support version more than once a year.
We talked about the frequency of releases. Come on now about the quality. What is missing in java? What would you add in the next major releases?
This, of course, can be talked about endlessly. There are a lot of language features that are not in Java because it has been historically or so conceived. If we talk about what would have pleased me specifically, then these are properties, generics without erasure and, probably, type inference. Embedded immutability would probably also be a very good option. In short, if you want to know how I want Java to look, look at Groovy.
What about Kotlin? Why is everyone talking about him now?
Firstly, when they talk about you on Google I / O, this clearly contributes to popularity. In addition, Kotlin is a good language. It has a lot of things taken from other languages ​​and correctly implemented. Although, of course, as we all know, the popularity of the language depends on the beard of its author (stroking the beard). But, seriously, it also depends on the possibility of promotion and popularization. Some Smalltalk, which everyone considers to be a sample of the PLO, did not take off for completely non-objective reasons.
Kotlin now has a good starting point to conquer the world. It is called JetBrains, which thanks to IntelliJ IDEA is very popular and respected among developers. When we think about JetBrains, we imagine cool products that are made at a good technological level. In addition, instead of chasing profits, their team does what it sees fit (at least they want us to think so). This is such a dream company.
Such trust stock is displayed in the language itself. "Oh, Kotlin did in JetBrains - it means something good!". And then you look and it turns out that this is really something good. This was noticed by the developers after Google I / O, which created a wave of HYIP. Moreover, if you do not write for Android on Kotlin, then you are kodish on some Java 6. The pain and anguish.
And why is Kotlin so good? What are its advantages over Java?
Kotlin has many good features from other languages. More convenient and correct syntax, which reduces the number of boilerplate. For example, POJOs can be created with a lot less code. It does not need any getters, setters. Straight groovy some!
One of the most serious features is Null Safety. This advantage, for example, over Groovy. In general, there are far fewer ways to shoot yourself in the leg in everything related to nullability. Six years of design by smart people are not in vain.
What about fancy stuff like reactive programming?
In the 138th issue of “Debriefing” we spoke with Roma Elizarov, who is just writing a jet library for Kotlin. Language is made so that libraries like RX are very easy and convenient to connect natively. As soon as you connect it, it fits in very harmoniously with the syntax and you can work with it as if it were embedded in the language.
Is it worth learning now?
You should always learn a new language - this is a great opportunity to expand your horizons, to become the best programmer, no matter what you write. Even if you work in a traditional bank, where nothing will change in the coming decades, it is worth learning Kotlin just for the sake of professional development. This is your job as a developer.
But besides, if you look for career opportunities, Kotlin is an interesting bet. This does not mean a 100% chance that it will “shoot” and your next job will be exactly on Kotlin. On the other hand, as Taleb taught us - an attempt is not torture! - what if it also shoots?
Kotlin has a good start on Android, but how much can it compete with Java in the enterprise segment?
To date, the gap between Java and the giant. In the near future it does not block. It seems to me that the target audiences are a bit different. We talked about banks and government agencies who love Java for its stability and the huge corporation that stands behind it. They will not change Java to Kotlin today, simply because some programmers find it easier to write code. This is a very long process that Java took 15 years to complete. To change Java in this segment, another language will need five times more. More dynamic companies, start-ups, for which the quality and quantity of releases are much more important, and not some kind of stability, and which are easier to change, will more likely accept a language like Kotlin.
The banks are confident that Java will not go anywhere, it will be supported for a long time, Java developers can always be found, and its next version will be backwards compatible and they will not have to be upgraded every two months. They work with a supplier who understands their needs.
It reminded me of a post where a guy interviewed his mother. She has been working as a COBOL-developer at a bank for the last twenty years or so. Now such developers are very expensive, and the bank can not afford to go to something else, because they need uptime 24/7.
In fact, they can not afford to rebuild, not because they do not have time to change the server. It is not true. They can't afford it, because millions of lines of code are written in COBOL. It is much cheaper to pay COBOL developers more than the average developer gets than to rewrite all these systems in other languages.
And yet they rewrite. I think in 2017 there is a lot more Java in banking systems than COBOL. Yes, these are long-term projects that do parallel support for the COBOL code, but in the end a shift occurs. In 50 years, Java will be a new COBOL. This is obviously inevitable and, of course, natural.
- Features of the work of the Developer Advocate: why it should not promote the products of the employer
- Java 9 and Java release frequency on the example of minibuses and trains
- Kotlin and his way to world domination
“The point is how well you are able to help solve the problems of developers, putting their interests above the interests of the product that you are promoting.”
Your post sounds like Developer Advocate? As far as I understand, this is a certain analogue of the evangelist, right?
Yes, an analogue of the evangelist, but not quite. The very concept of “evangelism” bears a religious coloring in the context of conveying to the people of the truth about a single right decision. This is not what I do. At least I would like to believe it. An evangelist is one who tells how to do it right. Advocate in English, although initially has no legal value, as in Russian, but implies protection, representation of interests. That's the difference.
')
Defender of interests of developers. This implies an understanding of the wishes of the developers, the community - and reporting them within the company?
This is one of the directions. The second, no less important, is to help developers solve certain problems even without using (although, of course, it’s better using) the products of the company that pays my salary. I can say: "Guys, use Artifactory, because it will help solve your problems." And sometimes I can say: "Do not use it better - it will not help you here." I will be praised for both options, but, of course, it is better when I I can use the first one.
Where, then, is the line between promoting a company's product and the professional work of Developer Advocate?
The fact is, how much do you understand the needs of those with whom you work. As far as you are able to help solve their problems, putting their interest above the interests of the product that you promote. Roughly speaking, if you are able to say: do not take our product - it will not help you now , then you are a professional Developer Relations. And if you are still promoting the product, because you didn’t listen, didn’t understand the developer, this is unprofessional.
Should Developer Advocate be a developer at the same time? For example, to keep yourself in shape and understand the needs of the community.
Required. And it's not in shape. Without writing code, you will not understand the needs of people - and you will not fulfill your duties. Be sure to write code, understand technology, “play” with them. Yes, and it's just interesting and pleasant.
What should be the balance between marketing and development components? How often do you code?
Getting back to the core of work, marketing is not part of developer relations. Developer Advocate in the company most often very little. Now there are 250 people working for JFrog and only one advocate. Although soon there will be three of us. But for a company of 250 people, even this is not enough. Therefore, under this function usually do not allocate a department, and attached to another unit.
Developer Advocate can work anywhere, but not in the sales department. In our case, I belong to the marketing. I do not do marketing in pure form, but rather prepare the ground for it. After a person listens on my report on how JFrog products can be useful to him, he can become a leader with whom marketing will work.
In terms of the relationship between relations and development, the ideal ratio would be 50/50. Unfortunately, there are few people - there is a lot of work, so the technical part has to be “picked up” during off-hours. For example, I'm going to JavaDay, including to listen to the latest news, to try out new technologies on myself. The debriefing podcast has the same goals for me. I do not try to promote anything there for work, but on the contrary - to study and listen in order to stay informed. I really hope that when I dial a team, I will finally have time to do this during working hours.
That is, you like to drive and perform. But you also like to write code?
I really like to drive and write code. If I could do both in the 50/50 ratio ... I already have a perfect job, but it would be a little bit more perfect.
Developer Relations Professionalism - be honest with yourself. But the employer certainly puts some KPI? How is work performance measured?
The influence can be measured, but it is very difficult and expensive. At an early stage, companies are not willing to invest in measuring the impact of a Developer Relations specialist on the community. In many companies, influence either doesn’t measure at all, or relies on very simple and naive metrics such as the number of followers on Twitter or the people who attended the report. But how many people came to speak depends on two things: how much the report has a scandalous name, and who spoke in parallel. If with me in parallel there were stars of the first magnitude, like those that are already hanging on the JavaDay site, then no one will come to me even for a terrific report. This is an example of KPIs that do not make any sense.
Which KPIs are really important? How much my report caught people? Let's look at the example of Yegor Bugayenko. His reports are very "catchy" people. Is it good or bad? Does his Developer Relations improve or worsen? Egor speaks for the sake of hiring. In this case, everything is simple: if three people after his report came to work for him, then the report was good. It does not matter that another 100 people could be potentially dissatisfied with the report.
And if it's not hiring, but a product, platform, API? How many people after the report registered? And how do you know that they came after the conference, and not because the article on the blog came out on the same day? Nevertheless, I believe that it is possible to measure, although this is not a trivial task.
You have been confirmed as a speaker on JavaOne again. What are you going to do?
There have not yet received answers for all my reports, since most of my reports still concern DevOps. I hope that they will receive a lot of my tech reports, for example, about Docker. On the main stream in Java, one report on voice user interfaces has so far been received. Let's make one of our two favorite formats: Alexa vs Google Home . We will write some kind of extension for them, and in the process we will compare the decisions that Amazon and Google made in the context of design and integration for third-party extensions.
In July, you entered the Top 20 Java Influencers 2017 list. How important are hit in such ratings for Developer Advocate? Why did you get into it, do you think?
Last year, the organizers made this rating for the first time, and we - those who did not get there - terribly trolled those who got there. The fact is that the rating is based precisely on those meaningless metrics that we talked about earlier. The guys just took Klout - a platform that builds influence ratings in social networks based on user interaction. But, in fact, the platform is rather naive and, as I said, the impact is still difficult to measure. But this year I got there! And that's all, Klout at once is the most serious and truthful tool for measuring influence over minds! (Just kidding of course. It's a trifle, but nice).
Oracle recently cut all evangelists. Did he probably have enough money to measure their effectiveness?
An excellent indicator of whether they were cut in vain or not, do you know their names. If you read the news that the evangelists were fired, and you never heard about them, then the specialists from them were so-so. In the case of Oracle, there were also famous people like Simon Ritter - and not so much. Their reduction of any damage to Java or the company did not cause.
"Now we can talk about so many positive aspects of Java 9"
Don't you think that now there is no one to promote Java 9, which is not yet very popular?
The answer is twofold. No Developer Relations can promote a bad product. If people understand that they do not like what is in the “nine”, then no one can convince them. A year ago, the release was more than problematic. If I worked in Oracle in the position of the Developer Advocate, then I would criticize, at least internally, these solutions.
Now the situation has changed a bit. Oracle was forced to change the concept, to abandon the aggressive promotion of modules that will be in the nine "under the hood", and transferring the entire community to them was transferred in the direction of Java 10. This makes the "nine" a fairly harmless update. So, from the situation “oh no, I will not upgrade, because it will break everything”, we went into the situation “it is possible and proapdate - probably there are some nishtyaks”. And in this state of affairs, the lack of a Developer Relations in Oracle is bad for Java. It is no longer necessary to protect the modularity, but it is necessary to disclose the advantages that are in the new release - and not all are obvious.
Let's imagine that Oracle has Baruch on his salary. Would you promote Java 9? What exactly would like to convey to developers?
Yes, of course, now we can talk about a lot of positive aspects of Java 9. The biggest feature that caused the greatest number of debates and rejections is Jigsaw. His previous reincarnation promised to break everything, but now it has been removed from the agenda. Almost everything that works in Java 8 will work almost unchanged and in the "nine". Therefore, we can talk about other features.
For example, there are novelties in the syntax of the language - incubator projects - that will allow you to try some things aimed at 10 and beyond, like the new HttpClient. Yes, it will not be such a giant release as 5-ka or 8-ka. Java 9 will be a more minor stabilizing release, like 7-ka. But there is something to talk about in it - and there are reasons to suggest upgrading.
How much is delay and adaptation harm the development of the language? Oracle, on the other hand, had the idea of ​​reducing development cycles in order to release new versions more than once every five years.
Yes, now there is a discussion about whether Java releases should be “minibuses” or “trains”. "Minibus" comes out when it is full. That is, there is a specific set of features that are scheduled in a particular release. It will be released when all the features are ready - the minibus is full. The “train” is on schedule: those who managed - left, who did not - are waiting for the next train. Until now, Java releases have been a “minibus”. The “departure” of Java 9 was constantly postponed, because everyone was waiting for the modules to be ready.
Now in Oracle, there is a shift towards the “train” with the release date assigned. This, most likely, will lead us to releases “in one”, when the larger will be followed by a more “cosmetic” one. That is, if the next phase of the modules (the one that breaks everything to everyone) enters the “top ten”, and most likely there will be no major changes in Java 11. Just do not have time to write.
Are you for “minibus” or for “train”?
It seems to me that the "train" is more correct. This approach will greatly reduce the stress on project owners of Oracle. In the case of a “minibus”, they must rush headlong, make compromises in quality, but have time to release - or be guilty of being delayed again.
I think Java 8 just ran into this problem. To put it mildly, it was problematic in terms of quality and in terms of bugs, documentation and design decisions. Although Java remains more stable than many other languages ​​(even on a stable JVM), the G8 was surprisingly crude by Java standards. Probably the pressure to have time to “fill in a minibus” was the reason. In the case of regular releases (they didn’t have time for this - will be released next), such a problem will most likely be avoided.
Can Java be developed on the basis of continuous delivery?
I very much doubt, because you shouldn't forget about the platform we are dealing with. She is an adult. Many conservative enterprise customers rely on it. Upgrades are not fast, and the constant release of new versions creates some pressure. “Three versions have already been released, but we still have not updated!” They are not ready for this. Therefore, doing continuous delivery for developers is possible. But I doubt very much that it makes sense to post the long term support version more than once a year.
We talked about the frequency of releases. Come on now about the quality. What is missing in java? What would you add in the next major releases?
This, of course, can be talked about endlessly. There are a lot of language features that are not in Java because it has been historically or so conceived. If we talk about what would have pleased me specifically, then these are properties, generics without erasure and, probably, type inference. Embedded immutability would probably also be a very good option. In short, if you want to know how I want Java to look, look at Groovy.
“Kotlin has a good starting point to conquer the world. It's called JetBrains. ”
What about Kotlin? Why is everyone talking about him now?
Firstly, when they talk about you on Google I / O, this clearly contributes to popularity. In addition, Kotlin is a good language. It has a lot of things taken from other languages ​​and correctly implemented. Although, of course, as we all know, the popularity of the language depends on the beard of its author (stroking the beard). But, seriously, it also depends on the possibility of promotion and popularization. Some Smalltalk, which everyone considers to be a sample of the PLO, did not take off for completely non-objective reasons.
Kotlin now has a good starting point to conquer the world. It is called JetBrains, which thanks to IntelliJ IDEA is very popular and respected among developers. When we think about JetBrains, we imagine cool products that are made at a good technological level. In addition, instead of chasing profits, their team does what it sees fit (at least they want us to think so). This is such a dream company.
Such trust stock is displayed in the language itself. "Oh, Kotlin did in JetBrains - it means something good!". And then you look and it turns out that this is really something good. This was noticed by the developers after Google I / O, which created a wave of HYIP. Moreover, if you do not write for Android on Kotlin, then you are kodish on some Java 6. The pain and anguish.
And why is Kotlin so good? What are its advantages over Java?
Kotlin has many good features from other languages. More convenient and correct syntax, which reduces the number of boilerplate. For example, POJOs can be created with a lot less code. It does not need any getters, setters. Straight groovy some!
One of the most serious features is Null Safety. This advantage, for example, over Groovy. In general, there are far fewer ways to shoot yourself in the leg in everything related to nullability. Six years of design by smart people are not in vain.
What about fancy stuff like reactive programming?
In the 138th issue of “Debriefing” we spoke with Roma Elizarov, who is just writing a jet library for Kotlin. Language is made so that libraries like RX are very easy and convenient to connect natively. As soon as you connect it, it fits in very harmoniously with the syntax and you can work with it as if it were embedded in the language.
Is it worth learning now?
You should always learn a new language - this is a great opportunity to expand your horizons, to become the best programmer, no matter what you write. Even if you work in a traditional bank, where nothing will change in the coming decades, it is worth learning Kotlin just for the sake of professional development. This is your job as a developer.
But besides, if you look for career opportunities, Kotlin is an interesting bet. This does not mean a 100% chance that it will “shoot” and your next job will be exactly on Kotlin. On the other hand, as Taleb taught us - an attempt is not torture! - what if it also shoots?
Kotlin has a good start on Android, but how much can it compete with Java in the enterprise segment?
To date, the gap between Java and the giant. In the near future it does not block. It seems to me that the target audiences are a bit different. We talked about banks and government agencies who love Java for its stability and the huge corporation that stands behind it. They will not change Java to Kotlin today, simply because some programmers find it easier to write code. This is a very long process that Java took 15 years to complete. To change Java in this segment, another language will need five times more. More dynamic companies, start-ups, for which the quality and quantity of releases are much more important, and not some kind of stability, and which are easier to change, will more likely accept a language like Kotlin.
The banks are confident that Java will not go anywhere, it will be supported for a long time, Java developers can always be found, and its next version will be backwards compatible and they will not have to be upgraded every two months. They work with a supplier who understands their needs.
It reminded me of a post where a guy interviewed his mother. She has been working as a COBOL-developer at a bank for the last twenty years or so. Now such developers are very expensive, and the bank can not afford to go to something else, because they need uptime 24/7.
In fact, they can not afford to rebuild, not because they do not have time to change the server. It is not true. They can't afford it, because millions of lines of code are written in COBOL. It is much cheaper to pay COBOL developers more than the average developer gets than to rewrite all these systems in other languages.
And yet they rewrite. I think in 2017 there is a lot more Java in banking systems than COBOL. Yes, these are long-term projects that do parallel support for the COBOL code, but in the end a shift occurs. In 50 years, Java will be a new COBOL. This is obviously inevitable and, of course, natural.
Source: https://habr.com/ru/post/335796/
All Articles