22.08.2019 12:54
moikrug 79 41600 Источник
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.

Комментарии (79)


  1. saipr
    22.08.2019 16:26
    #20538445

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

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


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

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


    1. karaboz
      22.08.2019 16:35
      #20538487
      +1

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


    1. QtRoS
      22.08.2019 16:50
      #20538559
      +1

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


      1. saipr
        22.08.2019 17:41
        #20538837

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


      1. 0xd34df00d
        23.08.2019 02:10
        #20540247
        +1

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


        1. QtRoS
          23.08.2019 08:40
          #20540729

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


          1. PsyHaSTe
            23.08.2019 12:26
            #20541823

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


            1. QtRoS
              23.08.2019 12:47
              #20541971

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


              1. Whuthering
                23.08.2019 12:49
                #20541993

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


                1. PsyHaSTe
                  23.08.2019 13:19
                  #20542169
                  +1

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


                  1. taliban
                    24.08.2019 04:39
                    #20545193

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


                    1. PsyHaSTe
                      26.08.2019 15:12
                      #20551035

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


                      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. PsyHaSTe
                23.08.2019 13:18
                #20542159

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


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


                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 со всеми соответствующими минусами отключенной типизации.


                1. QtRoS
                  23.08.2019 15:56
                  #20543031

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


                  1. PsyHaSTe
                    23.08.2019 16:12
                    #20543117

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

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


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

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


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

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


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

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


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

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



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


                    1. QtRoS
                      23.08.2019 16:27
                      #20543211

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


                      1. PsyHaSTe
                        23.08.2019 18:04
                        #20543779

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


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


            1. BOM
              23.08.2019 15:24
              #20542845
              +1

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


              1. PsyHaSTe
                23.08.2019 16:03
                #20543067

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


              1. 0xd34df00d
                23.08.2019 16:29
                #20543221

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


          1. 0xd34df00d
            23.08.2019 15:10
            #20542779
            +1

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


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


            1. QtRoS
              23.08.2019 15:46
              #20542993

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


              1. 0xd34df00d
                23.08.2019 16:34
                #20543243

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

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


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

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


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

                Аналогично.


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


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

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


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

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


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


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

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


                1. QtRoS
                  23.08.2019 16:57
                  #20543355

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


                  1. 0xd34df00d
                    23.08.2019 17:01
                    #20543381
                    +1

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


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


                    1. QtRoS
                      23.08.2019 17:14
                      #20543449

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


                1. Whuthering
                  23.08.2019 17:10
                  #20543419
                  +2

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


                  1. 0xd34df00d
                    23.08.2019 17:17
                    #20543473
                    +1

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


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


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

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


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


              1. domix32
                23.08.2019 19:44
                #20544187

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


      1. evocatus
        23.08.2019 11:50
        #20541603

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

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


        1. QtRoS
          23.08.2019 12:42
          #20541939

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


          1. evocatus
            23.08.2019 13:07
            #20542087

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


            1. QtRoS
              23.08.2019 13:43
              #20542321

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


              1. 0xd34df00d
                23.08.2019 15:10
                #20542781

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


                1. QtRoS
                  23.08.2019 15:50
                  #20543009

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


                  1. PsyHaSTe
                    23.08.2019 16:16
                    #20543151

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


                  1. 0xd34df00d
                    23.08.2019 16:38
                    #20543257

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


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


                    1. QtRoS
                      23.08.2019 17:05
                      #20543401
                      +3

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


                      1. 0xd34df00d
                        23.08.2019 17:18
                        #20543477

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


                        1. QtRoS
                          23.08.2019 17:39
                          #20543607

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


                          1. 0xd34df00d
                            23.08.2019 17:47
                            #20543665

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


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

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


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

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


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

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


              1. evocatus
                23.08.2019 18:17
                #20543825

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


    1. KanuTaH
      22.08.2019 17:10
      #20538685
      +1

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


      1. saipr
        22.08.2019 17:42
        #20538847

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

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


        1. Nalivai
          23.08.2019 15:26
          #20542865
          +1

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


  1. dss_kalika
    22.08.2019 17:11
    #20538691

    *пошёл за учепником по Го


    1. QtRoS
      22.08.2019 18:38
      #20539091

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


      1. dss_kalika
        22.08.2019 18:47
        #20539129

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


  1. SerafimArts
    22.08.2019 21:16
    #20539613
    +1

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


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


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


    1. Whuthering
      23.08.2019 12:12
      #20541731

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


      1. SerafimArts
        23.08.2019 14:55
        #20542715

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


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

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


    1. PsyHaSTe
      23.08.2019 12:27
      #20541837

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


      1. Whuthering
        23.08.2019 12:51
        #20541997

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


        1. PsyHaSTe
          23.08.2019 13:24
          #20542207

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


          1. Whuthering
            23.08.2019 15:31
            #20542893
            +1

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


            1. 0xd34df00d
              23.08.2019 16:40
              #20543271

              Лично для меня C++ хоть и не слишком простой, но по крайне мере понятный язык.

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


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

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


        1. 0xd34df00d
          23.08.2019 15:12
          #20542787
          +1

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


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


      1. lgorSL
        23.08.2019 14:18
        #20542519

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


        1. 0xd34df00d
          23.08.2019 15:11
          #20542783

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


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


    1. Nalivai
      23.08.2019 15:27
      #20542871

      PHP сдает позиции тому же Go, оттуда и падение популярности


  1. funca
    22.08.2019 22:31
    #20539795

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

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


    1. karaboz
      22.08.2019 23:06
      #20539891

      Мойкруг давно не принадлежит Яндексу, а один из 4 проектов Хабра (=

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

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


  1. kuftachev
    23.08.2019 01:37
    #20540203
    +1

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


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


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


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


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


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


    1. karaboz
      23.08.2019 11:56
      #20541647

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

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


      1. tonad
        23.08.2019 12:27
        #20541835

        На DOU привязывают к $, имхо, это большой плюс, так как валюта менее волантильная, чем гривна. Удобно проводить ретроспективу изменений, удобно сравнивать с другими странами.


  1. Filex
    23.08.2019 09:33
    #20540931

    rust пока экзотика?


    1. IMnEpaTOP
      23.08.2019 09:43
      #20540961

      С середины июня пару раз в неделю вбиваю на 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. berezuev
        23.08.2019 10:17
        #20541127

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


        1. IMnEpaTOP
          23.08.2019 10:47
          #20541261

          Это всё понятно. Потому положительная динамика (даже летом) это оптимистичный знак тем, кто ищет знаки.


      1. JonNiBravo
        23.08.2019 15:07
        #20542765

        У нас в проекте переодически появляется мысль переписать некоторые вещи с Go на Rust. Для себя сейчас выбираю следующий язык для изучения как раз между Rust и Elixir, для сферы высоконагруженных и высокодоступных распределенных систем


  1. allexart
    23.08.2019 11:52
    #20541625

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


    1. Whuthering
      23.08.2019 12:14
      #20541741

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


      1. IMnEpaTOP
        23.08.2019 13:24
        #20542209
        +1

        Потому что кто-то должен ведь всё это охранять? Если они вот так встанут и уйдут, как опасно то станет. Не могут они так поступить со всеми нами.


        1. li4inka
          23.08.2019 18:28
          #20543887

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


  1. Alex_Builder
    23.08.2019 18:27
    #20543879

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

    А вообще еще кто-нибудь сейчас занимается программированием и выбором инструмента под решение задачи или в этой индустрии теперь все тупо лишь мечтают о зарплатах? :D


    1. dss_kalika
      23.08.2019 18:33
      #20543909

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


    1. 0xd34df00d
      23.08.2019 18:50
      #20543973
      +2

      А вообще еще кто-нибудь сейчас занимается программированием и выбором инструмента под решение задачи или в этой индустрии теперь все тупо лишь мечтают о зарплатах? :D

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


    1. Whuthering
      23.08.2019 19:27
      #20544099

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

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


      1. Alex_Builder
        24.08.2019 02:48
        #20545147

        Решил вам развернуто ответить :)

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

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

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

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

        Давайте я объяснюсь.
        Я уже писал как-то в другой теме, что вот включаю я свой персональный компьютер и не вижу там ни одной хоть сколько бы серьезной и нужной мне программы, написанной на 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 лишь мечутся как Г в проруби и регулярно кидают своих адептов.

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

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