company_banner

Как менялись зарплаты и популярность языков программирования за последние 2 года

    image

    В нашем недавнем отчёте по зарплатам в ИТ за 2 полугодие 2019 многие интересные подробности остались за кадром. Поэтому мы решили осветить самые важные из них в отдельных публикациях. Сегодня попробуем ответить на вопрос, как менялась зарплата у разработчиков разных языков программирования.

    Все данные мы берём из калькулятора зарплат «Моего круга», в котором пользователи указывают те зарплаты, которые получают на руки после вычета всех налогов. Сравнивать зарплаты будем по полугодиям, в каждом из которых мы собираем более чем по 7 тысяч зарплат.



    На 2-е полугодие 2019 зарплаты по основным языкам программирования выглядят так:
    самые высокие медианы зарплат у разработчиков на Scala, Objective-C и Golang — 150 000 руб. в месяц, рядом с ними язык Elixir — 145 000 руб. Следом идут Swift и Ruby — 130 000 руб., а затем Kotlin и Java — 120 000 руб. 

    Самые низкие медианные зарплаты у Delphi — 75 000 руб. и C — 80 000 руб.

    У всех остальных языков медианная зарплата в районе 100 000 руб. или чуть ниже.



    А как долго держится такая ситуация, всегда ли перечисленные выше лидеры были таковыми? Посмотрим, как изменялись медианы зарплат по всем взятым нами для исследования языкам программирования за последние два года.

    Видим, что если у Scala и Elixir медиана зарплат выросла совсем немного, то у Objective-C и Go произошёл сильный скачок, позволивший им догнать эти два языка. Swift за это же время догнал Ruby и немного обошёл Kotlin и Java.

    Динамика относительных зарплат по всем языкам следующая: за два последних года самый большой скачок медианной зарплаты у Objective-C — 50%, далее идёт Swift — 30%, следом Go, C# и JavaScript — 25%.

    Учитывая инфляцию, можно сказать, что почти не меняется медианная зарплата у разработчиков PHP, Delphi, Scala и Elixir, а у разработчиков С и С++ она явно падает.

    Любопытно сопоставить динамику зарплат с динамикой распространённости языков программирования среди разработчиков. По данным, собранным в нашем калькуляторе, мы посчитали по каждому полугодию, какова была доля тех, кто указывал тот или иной язык по сравнению со всеми, кто указывал языки программирования.

    Более всего распространён JavaScript — порядка 30% указывают его в качестве своего основного навыка, и доля таких разработчиков за два года чуть выросла. Далее идёт PHP — порядка 20%-25% владеют им, но доля таких специалистов уверенно уменьшается. Далее по распространённости следуют Java и Python — порядка 15% владеют этими языками, но если доля специалистов Java чуть растёт, то доля специалистов Python чуть уменьшается. Замыкает топ самых распространённых языков — C#: порядка 10-12% владеют им, и их доля растёт.

    Самые редкие языки — Elixir, Scala, Delphi и C — 1% разработчиков или менее владеют ими. Говорить о динамике их распространённости сложно из-за довольно маленькой выборки по этим языкам, но в целом видно, что их относительная доля скорее падает. 

    На следующей диаграмме видно, что за два года выросла доля разработчиков JavaScript, Kotlin, Java, C# и Go, и заметно упала доля разработчиков PHP.




    Итого, можем обозначить следующие общие наблюдения:

    • Видим одновременный заметный рост зарплат и рост доли разработчиков в языках JavaScript, Kotlin, Java, C# и Go. Видимо, использующий эти технологии потребительский рынок и соответствующий ему рынок труда сейчас синхронно растут.
    • Заметный рост зарплат и небольшой или отсутствующий рост доли разработчиков — в Objective-C, Swift, 1С, Ruby и Python. Скорее всего, использующий эти технологии потребительский рынок растёт, а рынок труда за ним не поспевает или использует устаревающие технологии.
    • Незначительный или отсутствующий рост зарплат и доли разработчиков — в Scala, Elixir, С, С++, Delphi. Использующий эти технологии потребительский рынок и рынок труда не растут.
    • Незначительный рост зарплат и заметное уменьшение доли разработчиков — в PHP. Использующий эти технологии потребительский рынок и рынок труда сужаются.



      Если вам нравятся наши исследования зарплат и вы хотите получать ещё более точные и полезные сведения, не забывайте оставлять свои зарплаты в нашем калькуляторе, откуда мы потом и берём все данные: moikrug.ru/salaries/new.
    Мой круг
    295,52
    Сервис карьеры в IT
    Поделиться публикацией

    Комментарии 85

      +1
      Как менялись зарплаты и популярность языков программирования за последние 2 го

      Немного о себе. Я программист с 1974 года.
      На мой взгляд вы взяли не очень удачный период. Как менялась зарплата? В лучшем случае никак (я сужу по малому и среднему бизнесу ).
      Теперь о популярности языков. Естественно, основным моим языком был и есть Си. Но вот (как раз в тот промежуток времени, который вы рассматриваете) мне потребовалось написать графическую утилиту. Работа была рутинная и так не хотелось ее делать на Си с Qt. На свое счастье я вспомнил про Tcl/Tk, к которому не обращался с 1998 года. И я понял как я много потерял за эти годы.
      Сегодня он для меня стал вторым по значимости языком. Чего только на нем н пишу: УЦ, утилиты управления токенами PKCS#11 и т.д. и т.п.


      Видим одновременный заметный рост зарплат

      Вот тут я не могу согласиться с вами или мне просто не везет! Может другие языки использовать?

        +6
        Владимир, любая статистка всегда показывает среднюю температуру по больнице, оперирует средними значениями. Если мы говорим, что медианная зарплата у Go разработчиков выше, чем у Си разработчиков, то это лишь означает, что в выборке Go разработчиков вероятней встретить специалиста с более высокой зарплатой. Но при этом всё равно можно встретить специалистов Си, которые зарабатывают больше специалистов Go.
          +2

          А Вы попробуйте изучить тот же Go, хуже не будет :)

            +1

            Аналогичное встречное предложение :)
            Я смотрел Go.

              +4

              Таки мне стало хуже.

                +1

                Это как? Парадигма сменилась? Новые знания перестали в голове умещаться? Или Вы про смену работы и на Go теперь грустно писать?

                  +2

                  Ну лично мне стало плохо от того, что язык настолько популярен, а я не могу выразить в нем привычные концепции кроме как портянкой кода в полэкрана и через отключение проверки типов (привет. interface {})

                    0

                    Делитесь примерами, обсудим; может быть просто хотелось писать код не в парадигме языка.

                      0
                      подозреваю, вам сейчас начнут рассказывать про дженерики и исключения :)
                        +2

                        Ну исключения я и сам не люблю, АДТ наше все. А вот генерики — да. Когда мне говорят, что генерики это только для библиотечного кода, который пишется один раз в жизни и в реальном коде никогда не нужен, мне становится интересно, чем занимаются люди, которым не приходится решать задач, требующих обобщения.

                          0
                          Всем приходилось, но какой процент дженериков на весь код?
                            +1

                            Ну, я взял рандомный микросервис, и запустил две регулярки:


                            Search "(public|private).+\(" (671 hits in 159 files)
                            Search "(public|private).+<T.+?\(" (43 hits in 17 files)

                            Получается порядка 10% объявленных методов это генерики.


                            Если искать типы то расклад такой:


                            Search "(class|interface)\s+[^<]+\b" (232 hits in 228 files)
                            Search "(class|interface)\s+\w+<" (16 hits in 16 files)

                            В насквозь прикладном микросервисе опять же порядка 10% генерик типов (только объявленных собственных).


                            Сколько используется чужих генериков (из кастомных библиотек, к примеру) не берусь считать, но думаю половина кода спокойно выйдет.

                        +1

                        Ну буквально в среду у меня была задача батчить разные действия с монгой, потому что она не справлялась с нагрузкой.


                        В итоге появился класс вида


                        public class ActionBatcher<T>
                        {
                            private readonly Action<IReadOnlyList<T>> action;
                            private List<T> batch;
                        
                            public ActionBatcher(Action<IReadOnlyList<T>> action)
                            {
                                this.action = action;
                            }
                        
                            public bool IsRunning { get; private set; }
                        
                            public void RunOrBatch(T item) { ... }
                            public void RunNextBatch() { ... }
                        
                            ...
                        }

                        (гист с полным кодом)


                        Простой, понятный класс, который собирает некие объекты в батч, и выполняет заданные действия над тем, что успел собрать с момента последнего запуска. Ни разу не библиотечный код из башни слоновой кости, обычный тип решающий конкретную практическую задачу.


                        1. Класс используется с десятком различных T, поэтому копипастить одну и ту же реализацию очень не хочется
                        2. Использовать interface{} не вариант, потому что аналогом был бы dynamic со всеми соответствующими минусами отключенной типизации.
                          –3

                          А если все же рассматривать случаи без дженериков и обобщенных классов? А то получается давите в известное слабое место, а суждение о возможностях языка делаете более общее.
                          P.S. Не хочу расстраивать, но класс спроектирован неважно. С точки зрения пользователя непонятно, зачем там публичный IsRunning, ведь для многопоточной среды код не годится, а в однопоточной по очевидной причине он не нужен. Так же странно выглядит разный объем батча, необходимость явно вызывать обработку, да и в целом непонятно, почему проблемы с монгой пришлось решать так.

                            +1
                            А если все же рассматривать случаи без дженериков и обобщенных классов? А то получается давите в известное слабое место, а суждение о возможностях языка делаете более общее.

                            Я хотел как раз показать, что обобщенное и генерик-программирование занимает очень большой процент от основного пласта задач. А учитывая генерик-код библиотек которые мы используем процент обобщенного кода думаю за 90% переходит.


                            С точки зрения пользователя непонятно, зачем там публичный IsRunning

                            В некоторых сценариях нужно понимать, идет ли сейчас выполнение какой-то операции или нет. В основном для логгирования.


                            ведь для многопоточной среды код не годится

                            Код и не предполагается для работы в многопотоке. Точнее, вопрос многопоточности на себя берет акка, а с точки зрения пользовательского кода он синхронный


                            а в однопоточной по очевидной причине он не нужен

                            А как вам понять, идет ли сейча выполнение кода? Для работы кода это. конечно, не нужно, а вот для логгирования пригодится. Возможно можно было бы выставлять публичное ридонли свойство элементов которые должны будут попасть в обработку, но в тех сценариях что были в коде можно было обойтись булкой.


                            Так же странно выглядит разный объем батча, необходимость явно вызывать обработку, да и в целом непонятно, почему проблемы с монгой пришлось решать так.

                            Просто снижение нагрузки на БД. За счет этого батчера получается не выполнять операции записи, которые все равно будут выкинуты. В частности, таким образом батчатся разные версии одной сущности, в итоге в БД улетает только один запрос на изменение, а не 100.




                            Ну и да, вопрос проектирования довольно спорный, вы ведь не знаете моих ограничений/требований/..., не говоря про ограничение по времени на выполнение задачи, поэтому предлагаю исходить из того, что задача "нужно батчить подобным образом задачи" есть. Как её решать я не ограничиваю вас никак, я пришел к такой абстракции, покажите, какую абстракцию мне предлагает го и как с ней работать.

                              0

                              А как метод IsRunning вернёт результат, если, собственно, этот поток сейчас "running" и находится внутри переданного action?..

                                0

                                Видимо, это классическая проблема с именованием :) IsRunning по сути показывает некоторую другую метрику, которая ресеттится через попытку запустить следующий батч, если больше нет работы. Возможно, действительно лучше будет немного порефакторить и убрать это поле.


                                В Ну даже если. уберите лишнее, основной поинт остается: вот мне в максимально прикладном коде понадобилась такая структура данных. Как мне обойтись средствами языка, который не позволяет выражать генерики и не потерять в читаемости/типобезопасности?

                        0
                        Может быть, проблема в том, что под привычными концепциями вы понимаете привычные концепции на каком-то другом языке? Все таки у каждого языка свои концепции, стилистика, лучшие практики и т.д. Обвинять Го в том, что он недостаточно Си это не конструктивно. Пытаться писать фортрановский код на Джаве тоже. И тому подобное.
                          0

                          Ну покажите go-way решения моей проблемы, возможно, я проникнусь глубиной и мудростью этого подхода, как например произошло со мной, когда я изучал Effectful взаимодействия в чистых языках.

                            +2

                            Это было бы хорошим аргументом, если бы не было опыта успешного и приятного изучения других языков с совсем другими, куда более чуждыми концепциями.

                          +2

                          Ну, бывает, что вот ковыряешь какую-то новую технологию или даже просто читаешь про неё, и испытываешь моральное и эстетическое удовольствие. А бывает наоборот.


                          Вот с Go — наоборот.

                            0

                            Я как-то случайно в данном обсуждении затесался в ярые защитники Go. На самом деле я скорее считаю, что каждому инструменту свое применение, и Go в том числе. Где-то он хорош, а где-то нет. Но тем не менее, прямые и безусловные категоричные суждения язык явно не заслуживает. Ибо один бинарник без рантайма и зависимостей это не "наоборот". Можно использовать докер образ scratch и иметь контейнер весом в пару менабайт это не "наоборот". Кросс-компиляция под любую платформу на любой платформе это не "наоборот". Запуск сопрограмм одним ключевым словом это не "наоборот". Решение проблемы 10к запросов в секунду коробочным http-сервером это не "наоборот".

                              0
                              На самом деле я скорее считаю, что каждому инструменту свое применение, и Go в том числе.

                              Ну вот я всякое разное пишу, но таковых применений для себя не вижу. А пишу и десктоп-софт, и веб-серверы, и сервисы, и микросервисы, и числодробилки, и запускалки тензорфлоу.


                              Ибо один бинарник без рантайма и зависимостей это не "наоборот".

                              Это не очень интересная мне метрика. Какая мне разница, что в докер, deb или rpm заворачивать?


                              Можно использовать докер образ scratch и иметь контейнер весом в пару менабайт это не "наоборот".

                              Аналогично.


                              Можно ещё упомянуть, что набирать go build (или как там) быстрее, чем, скажем, stack build --fast.


                              Кросс-компиляция под любую платформу на любой платформе это не "наоборот".

                              А этим правда пользуются в тех областях, под которые заточен Go?


                              Запуск сопрограмм одним ключевым словом это не "наоборот".

                              Это уже было в симпсонах много где.


                              И напомните, этими сопрограммами потом легко управлять? Я могу запустить 100500 сопрограмм для обработки каждого элемента списка, а потом дождаться выполнения их всех сразу (или одной из них)? Могу запустить 100500 сопрограмм и собрать результаты точно той же функцией свёртки, как из любой другой монады любого другого контейнера?


                              Решение проблемы 10к запросов в секунду коробочным http-сервером это не "наоборот".

                              Ну вот тут мне нечего сказать, надо бенчмарки писать.

                                0

                                Как мне кажется, "не очень мне интересно" не является достаточным основанием высказывать безусловные суждения о профнепригодности или технологической ущербности языка. В режиме "ой всё" напомню цитату "есть языки, которые все ругают, а есть те, на которых никто пишет". На Go пишут много и повсеместно.

                                  +1

                                  Так я ж сразу написал, что дело в личной эстетике и моральном удовольствии, про профнепригодность я ничего не говорил. Наоборот, я считаю, что для той ниши, для которой Go изначально создавался (и о которой её создатели совершенно не стесняются говорить), он просто прекрасен.


                                  Ну просто я скорее стараюсь этой ниши избегать.

                                    0

                                    Кстати сами авторы по-моему в нее не сразу прицелились, потому что был как минимум один фейловый кейс с разработкой на Go под Android.

                                  +2
                                  И напомните, этими сопрограммами потом легко управлять? Я могу запустить 100500 сопрограмм для обработки каждого элемента списка, а потом дождаться выполнения их всех сразу (или одной из них)? Могу запустить 100500 сопрограмм и собрать результаты точно той же функцией свёртки, как из любой другой монады любого другого контейнера?
                                  Эм… а в чем сложность?
                                  Создаете массив каналов (по одному каналу на каждую корутину), передаете каждой корутине канал как аргумент при старте, а потом или блокирующе читаете результат работы из нужного канала, или итерируетесь по массиву каналов и точно так же читаете сообщения из каждого, при желании сразу же применяя сверточную функцию.
                                    +1

                                    Как всё это в коде будет выглядеть?


                                    Вот у меня есть список из 100 чисел, я для каждого из них хочу сходить в базу (пусть это будет отдельной функцией, неважно), получить оттуда другое число, и далее два варианта:


                                    1. взять первое полученное число, все остальные действия прервать,
                                    2. взять все числа и просуммировать.

                                    Ну и вариант чуть сложнее: есть дерево, в узлах числа. Хочу взять каждое число-значение и заменить его в на результат похода в базу и выковыривания оттуда некоей структуры по этому числу-идентификатору (пусть для этого тоже есть отдельная функция). Как это будет выглядеть?


                                    Да, эта задача правда встречается на практике: например у вас есть дерево комментариев, где пока в каждом узле лежит ID коммента, и вы хотите построить дерево саммих комментов.

                                  0

                                  Что подразумевалось под рантаймом?

                            +1
                            Я изучил Go и написал на нём пару проектов. Плююсь до сих пор и жду введения обобщённого программирования. Они так зациклились на том, чтобы сделать трудным написание плохих программ, что сделали трудным написание хороших.
                            А как замена C/Python для простых командных утилиток — пойдёт.

                            Тот же C тоже бывает разный. Есть студенты, которые пилят говнокод для Ардуино, а есть люди, решающие задачи, которые по большому счёту ни на чём кроме С и не решить, использующие API Linux, которые нигде в литературе не описаны, поэтому им приходится изучать патчи ядра, lwn и списки рассылки.
                              0

                              Обобщённое программирование в основном требуется для своего рода "библиотечного" функционала, который подразумевает переиспользование. Я прекрасно понимаю, как без него порой плохо — например, в текущем проекте есть один core-класс, на котором строятся временные ряды, без которого было бы совсем грустно, и в Go пришлось бы генерировать код. Но если отбросить эту проблему, неужели плюсы не перевесили?

                                0
                                Нет, не перевесили. Я действительно жалею, что не начал на Python (при всех его недостатках).
                                Обобщённое программирование (или динамическая типизация, которая его по сути подразумевает) требуется для написания хорошего чистого кода, где намерение выражено явно, нет дублирования, код короткий насколько это возможно, написан на должном уровне абстракции и т.д.
                                  0

                                  Оу, даже так. Тогда, наверное, и нечего противопоставить в контексте преимуществ Go, если безопасность типов и в разы меньшая вероятность проблем от их несоответствия в рантайме для Вас меньше значит, чем абстракции дженериков.

                                    +1

                                    Но ведь система типов Go недостаточно выразительна, чтобы воспользоваться безопасностью типов.

                                      0

                                      "Недостаточно выразительна" трудно интерпретировать однозначно, поэтому если вы поясните мысль, я буду признателен.
                                      Мне ее возможностей в целом достаточно, если опять же не возвращаться к дженерикам.

                                        +2

                                        Могу привести аналогию. "Мне возможностей С++ целом достаточно, если опять же не возвращаться к безопасности памяти". В этом ведь ключевая проблема, и это не "лишь" один нюанс при куче плюсов, это штука которая перечеркивает любые преимущества в почти любых задачах.

                                          +2

                                          Мне сложно вложить то, что я ожидаю от системы типов, в термины Go.


                                          Например, гарантировать, что функция не имеет сайд-эффектов. Или гарантировать, что вычисление в software transactional memory-контексте не делает того, что сломало бы гарантии STM. Или написать контейнер, в котором тип значения определяется значением ключа, А потом с использованием этого написать библиотеку обобщённых типобезопасных метрик вроде такой, например.

                                            +2

                                            А, это та самая библиотека с 0 Stars, Issues и Pull requests...

                                              +1

                                              Буду иметь в виду, что выразительность системы типов измеряется в количестве звёздочек.

                                                0
                                                Я может резковато написал, но зачем все это:
                                                > контейнер, в котором тип значения определяется значением ключа, а… И т.д.
                                                если этой «библиотекой» кроме вас пользуется 0 человек. Может быть это было неплохое умственное упражнение, и Вы им гордитесь, но его упоминание в контексте системы типов не добавляет веса словам.
                                                К тому же, опять же по моему мнению, не очень справедливо козырять всякими хаскелями, когда сравниваются, в общем-то мейнстрим языки. Давайте более приземлённые кейсы и языки рассматривать, на которых люди пишут за деньги, а не упражняются в выделывании хитрых конструкций.
                                                  0

                                                  Ну так, во-первых, я ту библиотеку только в комментах на хабре полтора раза пиарил пока что, а, во-вторых, зависимые мапы в другой либе: тыц и тыц, например.


                                                  К тому же, опять же по моему мнению, не очень справедливо козырять всякими хаскелями, когда сравниваются, в общем-то мейнстрим языки.

                                                  У меня уже довольно давно нет впечатления, что хаскель не мейнстрим. Да, маргинальщина, но маргинальщина среди мейнстрима.


                                                  Давайте более приземлённые кейсы

                                                  То есть, я правильно понимаю, что вы хотите намеренно ограничить то, какие системы типов вы рассматриваете, менее интересными и выразительными, и потом, конечно, ожидаете, что Go будет смотреться не так блёкло?


                                                  и языки рассматривать, на которых люди пишут за деньги

                                                  Я пишу на хаскеле за деньги. Теперь можно?

                                        +1
                                        В современном Python можно проставить аннотации типов (притом эта система аннотаций выразительнее Golang) и о несоответствии типов сообщит современная IDE (типа PyCharm) или инструмент типа mypy ещё на этапе написания. А в рантайме Go может выдать не меньше ошибок — например, при работе с map, или при парсинге HTTP-запроса, или при парсинге шаблона для html/template с диска, или при попытке заполнить структуру из JSON, пришедшего от фронтенда.
                                        А когда понимаешь, что никак не получится создать функцию, которая бы принимала на вход любые структуры, имеющие определённый набор полей, то становится действительно горько.
                                        Использовать interface{} и приведение типов? Ага, и править бесконечные switch-statements по всему коду при добавлении нового типа? Это классический антипаттерн «как не надо делать полиморфизм», который дядюшка Боб приводит в каждой второй лекции.
                                        Использовать interface{} и рефлексию? Это всё распространится как рак по всему коду, также «безопасно» как указатели в Си и ужасающе неудобно.
                                        И вообще: interface{} — это та же динамическая типизация, только хуже, потому что неудобно и то, что Python делает автоматически, придётся писать вручную. Его применение считается в Go антипаттерном и неспроста.
                                        Есть ещё один вариант, по которому большинство и идёт: копипастить код как обезьяна. Нет, спасибо.
                                +2

                                Я бы написал рутинную графическую утилиту на QML. Tcl я очень уважаю, но пишу на нем главным образом скрипты автоматизации, Tk практически не пользуюсь. Но это вопрос вкуса.

                                  +2
                                  это вопрос вкуса.

                                  Золотые слова, все программирование в основной массе — это вопрос вкуса!

                                    +2
                                    Ну иногда это еще и вопрос применимости. Писать на PHP в микроконтроллер при определенной доле извращения можно, но очень не нужно.
                                0
                                *пошёл за учепником по Го
                                  +2

                                  Так Go tour лучше пройти ;)

                                    +7
                                    *пошёл в пеший Go tour
                                  +2

                                  Просто в качестве ироничного наблюдения за этим графиком:
                                  1) Чем хардкорнее язык и сложнее на нём писать — тем меньше на нём разработчиков.


                                  А по экстремумам:
                                  2) Этим же и сказывается падение популярности PHP, т.к. за последние 4 года он очень круто вырос в сторону строгой типизации (стал более хардкорным), качества кода и в целом.
                                  3) Этим же обуславливается повышение популярности JS, там дофига всякого сахара добавили (стал менее хардкорным) за последние 4 года.


                                  Естественно, эти выводы притянуты "за уши" и кое-где не соответствуют действительности, но в целом ведь похоже вырисовывается? =)

                                    0
                                    1) Чем хардкорнее язык и сложнее на нём писать — тем меньше на нём разработчиков.
                                    Delphi из этого правила весьма выпадает.
                                    строгой типизации
                                    не совсем понятно, почему вы слабую типизацию к хардкору относите. Поиск и отладка некоторых багов в программах на слабо типизированных языках может быть еще большим хардкором :)
                                      0

                                      А никто и не говорит о том, что везде всё точно. Тот же Go будет попроще плюсов.


                                      не совсем понятно, почему вы слабую типизацию к хардкору относите. Поиск и отладка некоторых багов в программах на слабо типизированных языках может быть еще большим хардкором :)

                                      И динамическую в т.ч. И не к усложнению, а наоборот, к упрощению отношу.

                                      0

                                      На С++ писать сложнее, чем на хаскеле, но разработчиков на первом больше.

                                        +1
                                        На С++ писать сложнее, чем на хаскеле
                                        простите, что?
                                          0

                                          А что вас так удивляет?

                                            +1
                                            У меня ровно другие мысли.
                                            Лично для меня C++ хоть и не слишком простой, но по крайне мере понятный язык. Собственно, на нем я большую часть своей жизни и пишу.
                                            Хаскель же, как и другие академические языки, отваливался еще на начальных этапах неоднократных попыток его изучения, такое ощущение, что его реально люди с другой планеты придумывали, и мозг нужно вывернуть просто неимоверно. Впрочем, возможно это просто вопрос привычки и мышления другими категориями и понятиями.
                                              0
                                              Лично для меня C++ хоть и не слишком простой, но по крайне мере понятный язык.

                                              Как работает Boost.Hana, понимаете, например? Свою написать смогли бы? Я бы, скорее всего, смог, но мне пришлось бы довольно много попотеть.


                                              Хаскель же, как и другие академические языки, отваливался еще на начальных этапах неоднократных попыток его изучения, такое ощущение, что его реально люди с другой планеты придумывали, и мозг нужно вывернуть просто неимоверно.

                                              Аж интересно стало для собственной статистики, что вас больше всего удивило/оттолкнуло/етц?

                                                0

                                                ИМХО, свой код понятен на "почти" любом языке, даже через несколько лет, чужой код на c++ может быть как легко читаем так и "совсем непонятен" или "чтобы понять что делает эта функция нужно просмотреть очень много кода вне её".

                                              +1

                                              Ехал UB через UB
                                              Видит UB в UB UB
                                              Сунул UB UB в UB
                                              UB UB UB UB


                                              Примерно это.

                                              +1

                                              Похоже, большинство С++ разработчиков так не считают.

                                                0

                                                Я лет 10 назад тоже так не считал. Но чем больше я пишу на плюсах и чем больше я пишу на хаскеле, тем больше я убеждаюсь, что на плюсах писать невозможно.


                                                А хаскель-то предельно тупой и простой так-то.

                                              0
                                              PHP сдает позиции тому же Go, оттуда и падение популярности
                                              0
                                              зарплаты будем по полугодиям, в каждом из которых мы собираем более чем по 7 тысяч зарплат

                                              По данным википедии у вас в Яндексе 8 с хвостиком тысяч сотрудников. Интересно как часто происходил пересмотр зарплат у ваших сотрудников за последние 2 года и как влияют на решение такие вот медианые цифры, собираемые на Моем Круге?
                                                0
                                                Мойкруг давно не принадлежит Яндексу, а один из 4 проектов Хабра (=

                                                Но вы задали очень интересный вопрос, нужно провести опрос среди компаний и узнать, насколько относительно молодой еще сервис зарплат влияет на зарплатную политику.

                                                Я знаю, что некоторые эйчары рекомендуют держать зарплаты сотрудников в пределах 20% диапазона относительно средней. Если же этого не получается, то у компании есть еще много вариантов компенсировать недостаток зарплаты, например: делать офигенный продукт, создавать комфортные условия труда, внедрять современные технологии, заниматься профессиональным развитием сотрудников, выстраивать гоамотный менеджмент и т.д.
                                                  0

                                                  При этом, к сожалению, эти же эйчары в непродуктивных компаниях считают точно также, и как результат, огромное количество связанных с ИТ продуктов имеет очень низкое качество, т.к. на "не очень интересных местах" поток желающих работать за туже з.п. скуднее и ниже качеством.

                                                +4

                                                Это реально статья от математика, а не от того, кто в теме.


                                                На примере того же PHP, есть по сути две части выдачи вакансий по теме, одна часть — это серьезная разработка, вторая — это WordPress и прочая нечисть, в которой тоже употребляется это слово. Вот без сравнения этих частей информация вообще не даёт никакой информации.


                                                По редким языкам с большой оплатой, без анализа вакансий не понятно, это перспективные направления или просто люди когда-то влезли в фигню и теперь готовы сильно переплачивать, чтобы не переписывать все с нуля.


                                                Требования по стажу тоже не учитываются.


                                                И ещё много вопросов к этим цифрам, в таком виде анализ не имеет никакого смысла.


                                                P.S. Посмотрите, как делают статистику на DOU.ua по языкам и по зарплатам.

                                                  0
                                                  Дада, вы правы, к полученной нами статистике хорошо бы добавить аналитику и постараться понять, с чем связаны замеченные тенденции. Для этого нужны отдельные ресурсы и время, и к сожалению, пока мы не смогли их выделить.

                                                  p.s. А дайте ссылочку на то, как делают статистику DOU. Мы их знаем и уважаем, но делаем примерно также, а где-то даже чуть лучше, как мне кажется. И вы же видели другие наши исследования зарплат, что мы регулярно выпускаем на Хабре?
                                                    0
                                                    На DOU привязывают к $, имхо, это большой плюс, так как валюта менее волантильная, чем гривна. Удобно проводить ретроспективу изменений, удобно сравнивать с другими странами.
                                                      0

                                                      А в калькуляторе есть разделение продуктовая/непродуктовая компания? В прошлый раз когда участвовал в опросе, такого вроде небыло, а возможно, можно было бы поделить...

                                                    +1
                                                    rust пока экзотика?
                                                      +4
                                                      С середины июня пару раз в неделю вбиваю на HH в поиске rust. Динамика положительная (с 34 результатов от 13.06 до 51 от 23.08 и на всём отрезке я фиксировал маленький, но рост по 1-4 результата в неделю). Однако это в целом очень небольшие числа, к тому же реально вакансий именно растовых не так много, в основном рост идёт за счёт упоминания раста как желательного опыта кандидата на вакансию.
                                                      С другой стороны, динамика явно стабильно положительная. Через годик это уже будет вполне себе маленький, но рынок труда. Например по Elixir, который есть в статистике поста, HH выдаёт всего 43 результата. Что, по вашему, вероятнее вырастет — раст или эликсир?
                                                      Скрытый текст
                                                      13.06 — 34
                                                      17.06 — 35
                                                      26.06 — 37
                                                      02.07 — 40
                                                      04.07 — 41
                                                      05.07 — 42
                                                      10.07 — 46
                                                      15.07 — 45
                                                      23.07 — 47
                                                      26.07 — 49
                                                      30.07 — 50
                                                      50.08 — 49
                                                      12.08 — 50
                                                      14.08 — 51
                                                      16.08 — 57
                                                      21.08 — 53
                                                      23.08 — 51
                                                        +1

                                                        Есть мнение, что ваша статистика немного искажена отпусками HR'ов. В начале лета с работой всегда хуже дела обстоят.

                                                          0
                                                          Это всё понятно. Потому положительная динамика (даже летом) это оптимистичный знак тем, кто ищет знаки.
                                                          0
                                                          У нас в проекте переодически появляется мысль переписать некоторые вещи с Go на Rust. Для себя сейчас выбираю следующий язык для изучения как раз между Rust и Elixir, для сферы высоконагруженных и высокодоступных распределенных систем
                                                        –1

                                                        А я вот задумался на том что охранник сидит и получают 20К, это же весь день смотрят монитор проверяет камеры. Почему зарплата программиста в несколько раз больше чем зарплата у охранника с чем это связано я работал программистом 2 недели у меня сильно заболела спина жопа глаза. А работа охранника такая же. Сложность разная но со временем опыт наростает, и сложности и нет.

                                                          +2
                                                          Почему зарплата программиста в несколько раз больше чем зарплата у охранника
                                                          а почему тогда все охранники не идут работать программистами и получать в несколько раз больше, если, как вы говорите,
                                                          работа охранника такая же
                                                          ? :)
                                                            +2
                                                            Потому что кто-то должен ведь всё это охранять? Если они вот так встанут и уйдут, как опасно то станет. Не могут они так поступить со всеми нами.
                                                              0

                                                              Императора бы ещё дельного поставить им во главу.

                                                            0

                                                            Все в принципе понимают что охранник не особо нужен, а его задача создавать видимость безопасности и ждать а вдруг что случится.

                                                            +1
                                                            А я вот с одних только Delphi в месяц больше 250т поднимаю чистыми.
                                                            Скажите, что я делаю не так?

                                                            А вообще еще кто-нибудь сейчас занимается программированием и выбором инструмента под решение задачи или в этой индустрии теперь все тупо лишь мечтают о зарплатах? :D
                                                              0
                                                              А можно немного уточнить — какой формат работы?
                                                              Это корпоративная система, фриланс, просто работа в нескольких проектах? )
                                                              Ну и уровень должности, если не сложно. (разработчик? ведущий? свой проект? свой отдел? архитектор? начальник всея айти?)
                                                                +2
                                                                А вообще еще кто-нибудь сейчас занимается программированием и выбором инструмента под решение задачи или в этой индустрии теперь все тупо лишь мечтают о зарплатах? :D

                                                                Вы упускаете третий вариант: выбирать задачи под инструмент.

                                                                  +2
                                                                  А кто говорит, что вы что-то делаете не так? Просто у вас необычный случай, и ваша зарплата за этот стек сильно выше среднего и соответственно сильно выбивается из общей статистики.

                                                                  А что до «задач» и «инструментов», то когда есть несколько инструментов, плюс-минус подходящих для решения задачи, то при итоговом выборе вступают еще и другие критерии, как, например, количество людей на рынке труда, могущих, и главное желающих с ним работать, чтобы потом было кому поддерживать и развивать это всё. И тогда совершенно обоснован и естественнен выбор даже чуть менее подходящего вместо чуть более подходящего.
                                                                  Ну и вариант «выбирать задачи под инструмент» выше уже упомянули, и учитывая спрос на разработчиков в наше время и разнообразие проектов в мире IT, с этим проблем особо нет.
                                                                    +1
                                                                    Решил вам развернуто ответить :)

                                                                    > А кто говорит, что вы что-то делаете не так?

                                                                    Вы иронию понимаете? ;)

                                                                    > Просто у вас необычный случай… и ваша зарплата за этот стек…

                                                                    Необычный случай? Зарплата за Стек? Что вы несете?
                                                                    Классическое найтивное программирование вдруг стало чем-то необычным?
                                                                    А платят теперь за понятие «стек технологий» (так любимое эффективными менеджерами) а не за результат, здравый смысл и возможность писать быстрые программы без каких-либо ненужных прослоек?

                                                                    Давайте я объяснюсь.
                                                                    Я уже писал как-то в другой теме, что вот включаю я свой персональный компьютер и не вижу там ни одной хоть сколько бы серьезной и нужной мне программы, написанной на javascript-е. И уж тем более ни одной на Питоне. А ведь последний чуть ли не в лидерах должен быть по количеству шума вокруг него в последние годы.
                                                                    Но я ничего не вижу на десктопе и из лидеров данного конкретного списка. За исключением разве что Objective-C (но я не вижу и Objective-C, поскольку в моей области деятельности Маки нафиг никому не нужны).
                                                                    Да у меня даже и на C#-то на десктопе днем с огнем ничего не сыщешь (кроме разве что каких-то мелочей от самой MS). Хотя, казалось бы, это-то должно бы давно уже появиться.

                                                                    Все графические редакторы, все инженерные и математические пакеты, весь 3D, все нужные мне офисы и бухгалтерии, все системные утилиты и прочие интрументы для работы, все это либо C++, либо в том числе и Delphi (Delphi в моем случае это AIMP, утилиты Auslogics и хелпмэйкер HelpNDoc, пару хороших утилит для Баз-данных включая DBWorkbench, сборщик FinalBuilder и шикарный но дорогой автотестер TestComplete ). И просто поверьте, что я не выбираю программное обеспечение по принципу на чем это сделано.

                                                                    И только не нужно мне рассказывать, что это мол де десктоп, а вот у нас мол в корпоративе все крутится на серверном скриптике «A» под библиотечкой «B» с прикрученными справа и слева пакетами «C» и «D», а визуализируется на HTML страничках под нехилым набором из новомодненьких библиотек E, F, G (набор которых чуть ли не каждые пару-тройку лет меняются).
                                                                    И изначально все это было задумано вашими «эффективными менеджерами», чтобы ускорить и упростить.

                                                                    Только на деле чаще всего выходит, что на создание и отладку всего этого времени уходит не меньше, а то и больше, чем на написание быстрого десктопа и серверной части сразу под конкретные платформы (естественно, кроме самих серверов и баз данных). А хуже то, что постоянная изменчивость и нестабильность вышеперечисленных «стеков», помноженная на нестройность и не строгость скриптовых технологий, еще раз помноженная на слабую компетентность непрофильных специалистов и четвертый раз помноженное на естественные скриптовые тормоза никак в результате не приводит к заветному для «эффективных менеджеров» удешевлению и упрощению.
                                                                    Да и в результате чаще всего мы видим лишь очередную эмуляцию десктопа в Браузере, поскольку все html красивоти для серьезной работы как бы нафиг не нужны. Ну и не факт, что это вообще будет работать через пару лет при смене браузера и поколения скриптового движка.

                                                                    При этом я вовсе не умаляю существенную значимость того же javascript-а в сайтостроительстве.
                                                                    Хотя по размерам кода современных сайтов IMHO на таком изначальном убожестве это писать уже опасно. Недаром и появляются обертки типа typescript-ов


                                                                    > При итоговом выборе вступают еще и другие критерии, как, например, количество людей на рынке труда могущих, и главное желающих с ним работать, чтобы потом было кому поддерживать и развивать это всё.

                                                                    Ну вы же, думаю, не надеетесь, что что-либо из вышеперечисленных мной серьезных пакетов будет вдруг непонятно зачем переписано на какую-нибудь Скалу или Го лишь мимолетной моды ради?
                                                                    Или тем более на скриптовые тормоза?
                                                                    А главное зачем?! Чтобы нанять якобы дешевых спецов? См.выше. Да и по факту спецы эти уже не дешевы.

                                                                    А теперь давайте более предметно и прагматично.
                                                                    Вот нужны десктопные морды с небольшими мобильными довесками.
                                                                    В силу задач (управление промышленными контроллерами) на десктопе желательно иметь возможность быстро спускаться до низкоуровневого программирования и время отклика должно быть минимален по возможности. Т.е. желателен быстрый найтив.
                                                                    C# и вообще менеджет подход не желателен (к тому же часть все равно придется писать на найтиве).
                                                                    Ну, например, можно и на С++Qt, благо опыт есть.
                                                                    Но оказывается, что и современный Дельфи совсем не плох.
                                                                    Интерфейсная часть накидывается элементарно и относительно быстро. А при использовании FMX теперь можно это замутить хоть даже и под Линукс. А вся подноготная часть пишется одинаково просто хоть на прикладном уровне, хоть на уровне прямого доступа к памяти и даже ассемблера и с почти бесшовным склеиванием с СОМ и низкоуровневым API на любой поддерживаемой платформе. При этом вероятность выстрелить себе в ногу при написании рутинной части все же существенно меньше, чем на C++.
                                                                    Специалистов на просторах СНГ полно, да и за пределами есть. И это уже чаще именно специалисты, а не ничего не знающие пока толком школьники, которые лишь мечтают вызубрить (именно вызубрить) какую-то очередную новомодную фенечку ради заветной большой зарплаты.
                                                                    Но только даже на моих глазах таких фенечек с 90-х уже куча промелькнула и пропала в никуда.

                                                                    И знаете, я бы все понял, если бы в этих списках новомодных и хорошо-оплачиваемых языков, появлялись бы такие вещи как язык «D». И не только появлялись, но и выходили бы хорошие IDE, а сторонние фирмы наперебой клепали бы инфраструктуру и компоненты для этого.
                                                                    Но вместо этого лишь куча таких же как и «D» многообещающих, но бесплодных выстрелов.

                                                                    Ну или если бы C# на найтив перевели с возможностью прямого доступа к пямяти и ее очистки по желанию и т.п.( а ведь грозились когда-то).
                                                                    А вместо этого MS лишь мечутся как Г в проруби и регулярно кидают своих адептов.

                                                                    И вот на этом фоне Дельфи или даже Лазарь на найтиве выглядят весьма даже неплохо и развиваются вполне предсказуемо и стабильно. Не говоря уже о конечном результате в виде единственного запускаемого файла, который стабильно, быстро и совершенно не прожорливо пашет потом годами и ему как и Си-шному найтиву очень долго потом плевать и на смену операционок, и от смен прослоек он тоже не зависит.

                                                                    Поэтому, если я могу к счастью выбрать сам, не опираясь на мнения «эффективных менеджеров» (ака недоучек из экономических колледжей) и не на мнение тинейджеров без профильного образования, то выходит, что и Дельфи живее всех живых, да еще и мобильные довески делать позволяет опираясь практически ровно на тот же код.
                                                                    А платят мне и напарнику за конечный результат, а не зарплату. Поэтому, и сумма в среднем большая выходит.
                                                                    0
                                                                    в этой индустрии теперь все тупо лишь мечтают о зарплатах?


                                                                    Ну, логично, что работа по найму — это в первую очередь, о зарплате сейчас, а во вторую очередь, о зарплате, если текущее место перестанет существовать. Что тут не так?
                                                                      0
                                                                      > Что тут не так?

                                                                      Не так здесь то, что во времена моей учебы программазмом и схемотехникой в основном занимались те, кому это было реально интересно. Поэтому, на выходе из ВУЗов как правило уже получались специалисты весьма высокого уровня и хорошо знающие основы. А шелуха типа зубрежки языков или переключение между ними в зависимости от задачи была как бы немного вторична.

                                                                      А карьеристы за зарплатой тогда шли в Финэк или на юридические факультеты. И приблизительно так же обсуждали, что бы им по-быстрому и попроще поучить, чтобы в блатную конторку на хорошую зарплату пристроиться.

                                                                      А теперь все перевернулось наоборот :)

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое