Пять перспективных языков программирования со светлым будущим (3 года спустя)

    КДПВ


    В 2016-м году я опубликовал перевод статьи про 5 перспективных языков программирования, в которой прогнозировался их рост в ближайшие 2-3 года.
    Зачастую прогнозы так и остаются прогнозами, без последующего анализа. Но я решил, что это непорядок. И посколько 3 года уже пролетели, пора подвести промежуточные итоги и посмотреть, что произошло с этими языками за это время.


    Однако, прежде чем мы перейдём к пятёрке наших героев, хочется уделить немного внимания предсказанному в той же статье переходу Swift и Go из второго эшелона в первый.


    про эшелоны

    В исходной статье языки программирования условно делятся на 3 эшелона по популярности.
    Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, C# и т.д.
    Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Большинство языков в первом эшелоне прочно укоренились на своих позициях. Поэтому выпадение языка с лидирующих позиций занимает ощутимое время, а для языка второго эшелона очень трудно пробиться в первый.
    К третьему эшелону относятся непопулярные языки, а также относительно новые перспективные языки (о которых пойдёт речь), которые только начинают свой путь наверх. Некоторые языки пребывают в третьем эшелоне на протяжении многих лет, не получая популярности, в то время как другие врываются на сцену всего за пару лет.


    Оба эти языка безусловно укрепили свои позиции. Swift от версии 3.0 успел дойти до 5.0 и наконец пообещал стабильность ABI. Другими словами, Apple больше не планирует раздражать программистов на Swift постоянной сменой сигнатур методов и т.д. Кроме того, Swift окончательно потеснил Objective-C, обогнав его в свежем рейтинге RedMonk и поднявшись на 6 позиций по сравнению с рейтингом 3-х летней давности. Очевидно, что тенденция продолжится, поэтому можно сказать, Swift занял своё место в первом эшелоне.


    Что касается Go, то он сместился в рейтинге на одну позицию ниже (с 15-го места на 16-е), прошёл путь от версии 1.7 до 1.13, и находится в стадии глобального переосмысления обработки ошибок и наличия дженериков в языке — вопросов, которые вызывали больше всего нареканий в течение всех 12 лет его существования. В общем, Go потихоньку эволюционирует, растёт количество проектов, которые применяют его в production, но о переходе в первый эшелон пока говорить рано.


    Помимо Swift и Go, стоит отметить TypeScript, который за 3 года совершил необычайный прорыв, перескочив в рейтинге с 26-го места на 10-е. Если вы занимаетесь разработкой фронтенда, но до сих пор не ознакомились с этим языком, то момент настал. Уже прям must-know.


    А теперь фанфары и главная часть — наша пятёрка языков, которым пророчили переход из 3-го эшелона во 2-й. Что изменилось для них за эти 3 года?!


    Для начала, сводная таблица по количественной OpenSource-активности на Github:


    Rust Elixir Kotlin Elm Crystal
    Repos Users Repos Users Repos Users Repos Users Repos Users
    2016 5146 1935 2668 861 960 1541 433 194 150 52
    2019 23700 13500 16800 4000 24300 26400 5300 994 1200 469
    Рост 4.6x 7x 6.3x 4.6x 25x 17x 12x 5.1x 8x 9x

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


    Понятно, что чем скромнее были позиции языка 3 года назад, тем легче показать кратный рост. Но тем не менее, с этой задачей отлично справились и Rust, и Elixir — лидеры нашей пятёрки по кол-ву репозиториев в 2016 году. Однако, самый выдающийся результат показал Kotlin, показав по-настоящему взрывной рост. О причинах поговорим чуть ниже, а пока давайте посмотрим какой путь проделали эти языки по лестнице RedMonk:


    RedMonk stats 2016


    RedMonk stats 2019


    Чтобы оценить продвижение языков по графику, я взял их координаты и посчитал дельту:


    ((x2 - x1) + (y2 - y1)) / 2

    Получились такие результаты среднего прироста по обеим осям:


    Kotlin:  +41%
    Rust:    +20%
    Elixir:  +20%
    Elm:     +18%
    Crystal: +32% # из-за того, что 3 года назад его не было на графике вообще

    Как видно, все языки пятёрки существенно продвинулись к популярности (вверх и вправо). Занятный факт, что все они находятся ниже диагональной линии, что означает относительно низкую активность на StackOverflow. Впрочем, тут нет никакой загадки, у сообщества каждого из этих языков есть форум на базе Discourse, и как следствие большинство вопросов обсуждаются там, а не на StackOverflow.


    В целом, все 5 языков показали хороший количественный рост. Но кто же проявил себя лучше всех? Давайте составим своеобразный Top и рассмотрим не только количественные, но и качественные критерии.


    5-е место: Elm


    К сожалению, Elm показал достаточно удручающие результаты. Во-первых, за 3 года вышло всего 2 релиза, причём последний на данный момент — 0.19 оказался настолько противоречивым, что даже привёл к некоторому расколу сообщества. И вот уже больше года новых версий не выпускается, хотя работа в репозитории идёт достаточно активно. При этом Эван Чаплицки (автор языка) ещё 2 года назад дал понять, что никакого вразумительного roadmap нет и не будет. При таком раскладе, Elm остаётся чисто экспериментальным языком с теперь уже сомнительным будущим. Хотя есть люди, которые по-прежнему смотрят на Elm c оптимизмом. С их доводами можно ознакомиться тут.


    Стоит отметить, что ещё в комментариях к исходной статье dimsmol, fshp и hellosandrik высказывались в пользу PureScript, как более жизнеспособной альтернативы Elm. И хотя он тоже до сих пор не достиг версии 1.0, динамика релизов выглядит более обнадёживающей. Так что любителям Haskell стоит обратить внимание на этот язык.


    4-е место: Crystal


    Если 3 года назад Crystal вообще не было видно на графике RedMonk, то теперь он вполне уверенно ворвался в Top-100 языков программирования. А также прошёл путь от версии 0.19 до 0.30. Впрочем, столь большое количество релизов показывает не только динамичность развития языка, но и его нестабильность. К большому сожалению, план выпустить версию 1.0 в 2017 году провалился.


    Как мне видится, во многом тут виновато совсем не вовремя появившееся желание реализовать поддержку Windows. Этот эпик продвигается очень медленно и требует значительных усилий от и без того маленькой команды разработки. Причём абсолютно непонятно зачем оно нужно до релиза 1.0. Основная целевая аудитория Crystal — это программисты, использующие Ruby в повседневной работе. А программировать на Ruby под Windows считалось моветоном ещё лет 10 назад. Другими словами, доля программистов, использующих Windows по работе и при этом заинтересованных в Crystal, исчезающе мала. И тратить на это огромные усилия, не имея на руках стабильной версии языка, крайне недальновидно. Ведь наличие версии 1.0 — это практически обязательное условие для побуждения средних и крупных компаний к использованию технологии.


    В итоге, Crystal теряет потенциальную аудиторию, т.к. компании, которым стало тесно в рамках Ruby и Python массово переходят на Elixir и Go. А для Crystal остаётся узкая ниша компаний, чьи программисты не смогли переключиться на эти языки. И это печально, т.к. хоть Crystal и не конкурент Elixir, но вот с Go он мог бы конкурировать вполне успешно, предоставляя местами даже лучшую производительность и сравнимую функциональность, приправленную выразительностью Ruby и встроенной в компилятор защитой от nil reference.


    2-е* место: Rust


    Rust взял курс на выпуск новой версии компилятора раз в 6 недель и придерживается этого плана. Как результат, за 3 года язык долетел с версии 1.11 до 1.37. В этом есть свои плюсы, например, ввод новых функциональных возможностей идёт постепенно и очень плавно. Но есть и минусы, например, понадобившаяся вам библиотека может опираться на более новую версию языка, чем ваш проект, начатый 3 месяца назад. Другими словами, будьте готовы к частым обновлениям. Тем не менее Core Team понимает, что постоянные обновления могут утомлять и объявили 2019-й — годом восстановления сил и стабилизации. Делается упор на полировку того, что есть, доработку затянувшихся фич (которые были давно начаты, но не доведены до master) и организационные моменты. Кроме того планируется улучшить поддержку IDE через улучшение Rust Language Server, улучшить отладку для WebAssembly и посмотреть в сторону разработки GUI-тулкита.


    В целом, Rust находится в процессе обретения статуса стабильного, сформировавшегося языка. Определенно стоит с ним познакомиться, если вам интересна high-performance разработка. Однако, сдерживающим фактором роста популярности является репутация Rust, как языка со слишком высоким порогом входа, которая отпугивает от него новичков. Поэтому сообществу ещё предстоит продолжение работы над имиджем языка в этом плане, если они не хотят пойти по пути Haskell ("avoid success at all costs"). Впрочем, не пугайтесь — те, кто попробовал, его любят: Rust занял 1-е место среди The Most Loved Languages в опросе StackOverflow в этом году.


    * в резюме статьи объяснено, почему 2 вторых места :-)


    2-е место: Elixir


    Если Rust ещё только планирует стабилизироваться в этом году, то Elixir, пройдя за 3 года путь от версии 1.3 до 1.9, уже это сделал. В ближайшее время не планируется никаких крупных изменений или дополнений в самом языке. И есть 2 причины, по которым Elixir может себе такое позволить:


    Во-первых, поскольку Elixir базируется на Erlang/OTP, он может пользоваться результатами усилий Ericsson и OTP Team по работе над рантаймом и виртуальной машиной. Elixir Team так же старается вносить свой вклад в эту работу и этот вклад ощутимо вырос за предыдущие 3 года.


    Во-вторых, Elixir спроектирован как расширяемый язык. Инструменты и абстракции, которые были использованы для создания и совершенствования языка, доступны и для библиотек и фреймворков. Это означает, что сообщество может продолжать улучшать экосистему без необходимости изменений в самом языке. В том числе и сам Жозе Валим (автор Elixir) пошёл этим путём и недавно анонсировал Broadway — библиотеку, упрощающую отказоустойчивую параллельную обработку данных из произвольных источников.


    В общем, Elixir уже является стабильным и полностью сформировавшимся языком, который отлично подойдёт всем, кто разрабатывает системы, нацеленные на высокую нагрузку или на высокую стабильность, или на то и другое одновременно. По сути для таких проектов особых вариантов и нет, либо использовать Erlang, либо Elixir, либо изобретать кучу собственных велосипедов. Кстати, если вы присматриваетесь к частичному внедрению Elixir в существующие проекты, рекомендую отличную книгу “Adopting Elixir”. В ней же можно почитать про опыт достаточно крупных компаний, которые уже перешли на этот язык.


    1-е место: Kotlin


    Безусловный лидер пятёрки — Kotlin. Ему удалось за 3 года проделать невероятный путь и практически перескочить из 3-го эшелона в 1-й, заменив Java в разработке под Android. Начиналось это с официальной поддержки Kotlin, анонсированной в 2017 году командой разработки Android. И, как следствие, его включения в Android Studio 3.0. В итоге, дружба с Android привела к тому, что 4 месяца назад Google объявил Kotlin предпочтительным выбором для разработки под Android. Конечно, этому во многом поспособствовали патентные споры Google и Oracle насчёт Java, но, разумеется, и заслуга JetBrains в этом есть. Они далеко не первые, кто захотел сделать Java с человеческим лицом, но первые кому удалось это сделать так, что отказ от Java в пользу нового языка стал мейнстримом. Мои поздравления!


    Кстати, JetBrains также активно развивает Kotlin Native, позволяющий компилировать код на Kotlin в нативный бинарник.


    Что касается рейтинга RedMonk, язык занимает пока что 20-е место, но это очевидно связано с тем, что Kotlin может без проблем использовать существующие Java-библиотеки, соответственно нет насущной необходимости их переписывать на него. Тем не менее, становится всё меньше причин начинать новые проекты на Java, даже если они не связаны с Android-разработкой. Так что вполне вероятно, что спустя ещё 3 года Java останется лишь в кровавом энтерпрайзе, а в остальном Kotlin займёт её место, как Swift занял место Objective-C.


    Резюме


    Можно сказать, что прогноз в целом оказался удачным. Хоть Elm и Crystal пока не оправдали надежд и их дальнейшее будущее пока под большим вопросом, зато остальные 3 языка проявили себя просто отлично. Kotlin при поддержке Google рванул как ракета в небеса, а Rust и Elixir полностью стабилизировались и однозначно стали production-ready языками. Я не смог выбрать, кто из них показал лучший прогресс… где-то Elixir обогнал Rust, где-то наоборот, и даже по кол-ву юзеров на форумах сообществ у них паритет (около 11 тыс. человек), поэтому в статье я им обоим отдал 2-е место. Эти языки определённо заслуживают внимания.
    Да, каждый из них имеет свою нишу и на тривиальных проектах можно обойтись и без них. Зато в высоконагруженных проектах они придут на выручку и предоставят вам на выбор 2 пути: выжать максимум из железа (Rust) или обеспечить лёгкое масштабирование и отказоустойчивость (Elixir).


    P.S. А как за 3 года изменился ваш Top перспективных языков?

    Only registered users can participate in poll. Log in, please.

    Какие языки из нашей пятёрки вы применяли на практике за предыдущие 3 года?

    • 3.4%Crystal21
    • 14.8%Elixir90
    • 4.1%Elm25
    • 56%Kotlin341
    • 41.9%Rust255
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 154

      +15

      Много голосов о применении Rust на практике, а вакансий всё нет и нет))


      UPD:
      А я хочу такие.

        +2

        Так никто не спрашивал про работу, вопрос был про применение на практике. Вот и крафтил народ свои хомяки на актиксе.

          +2

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

            +1
            Вакансии висят месяцами. Компании ведут конкурсный отбор. Так что если открытых вакансий мало, то их реально мало.
              0

              Что касается Rust, он ещё часто идёт как вспомогательный язык в вакансии, типа
              "Написание high-load сервисов на Go и Python с реализацией CPU-bound задач на Rust."
              "Работать в основном с Go с небольшим количеством Java / Kotlin (Spring), Elixir и Rust в архитектуре микросервисов"


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

                0
                Второе допущение, ты анализируешь глобально. Локально всё может быть по другому. Например, в иркутской области ты вряд ли найдешь такие вакансии.
                  +1

                  Локальные тренды всегда запаздывают. Когда вакансии дойдут до отделённых регионов России уже бессмысленно будет что-то анализировать. Поэтому да, начинается всё с глобального анализа и анализа рынка в США.

                  0

                  Если в проекте есть го, то не совсем понятно, что там растом делать. Разве что если какие-то дикие проблемы с gc, но с этим вроде уже научились справляться.

                    0

                    Это цитаты из реальных вакансий с hh.ru, можете им написать — спросить о мотивах.
                    А судя по написанному, у одних Rust для CPU-bound задач, а у других микросервисы на нём.

                +3
                У нас в компании, когда я приходит, стек был основан на JS/TS.
                Появились задачи для нативного кода, они были решены на Rust.
                Вакансия не сформировалась ни на секунду (и не факт, что появится: код небольшой, стабильный, и если аналогичные проблемы не появятся в будущем и не изменятся требования, маловероятно, что придётся с ним что-то делать).
                +18
                Потому что нет проектов, целиком написанных на Rust. Если же нам нужно сопрягаться с основной частью проекта, написанной на C/C++, то Rust — это как бы не худший выбор из возможных.
                Работа с «сырой» памятью там настолько затруднена, и поверх наброшено столько мозголомных абстракций, что допустить ошибку при прописывании ffi-биндингов очень просто, а вот её отлов потом может занять буквально недели, и всё равно не будет полной уверенности, что на всех платформах программа будет стабильно работать.
                Вот классический пример:
                extern crate libc;
                extern {
                    fn c_func(x: *mut *mut libc::c_void);
                }
                
                fn main() {
                    let x = 0 as *mut u8;
                    c_func(&mut (x as *mut libc::c_void));
                    println!("new pointer is {}", x);
                }
                Вопрос: что напечатает эта программа? А она вне зависимости от действий внешней функции c_func выдаст… 0x0. Чтобы всё работало как надо, указатель нужно описать вот так:
                (&mut x) as *mut _ as *mut *mut libc::c_void
                Да, вот такое вот мозговыносящее месиво, и если где-то в нём ткнул не тот символ, то компилятор сделает неявное копирование, и будет работать с копией, которая к тому же когда функция вернётся, станет невалидной и рано или поздно память будет чем-то переписана. Отлаживать такое — просто адский ад, особенно когда программа потом падает совсем не там, где «портится» долбанный указатель, да ещё и один раз из десяти, так что даже воспроизвести баг с трудом выходит.
                И это ещё ничего. Куда веселее, когда вам нужно собрать программу под 32 и 64 бита, и вот вдруг оказывается, что сишный компилятор и Rust не сошлись во мнениях, как при разной битности должны выглядеть выравнивания внутри структур/union'ов либо разрядности отдельных элементов. И тоже где-то кем-то портятся данные, и ведь хрен поймёшь, почему так. Доходит до того, что приходится в отладчике смотреть ассемблерный код, разбираясь, как интерпретируются структуры внутри функций.
                Если кто-то хочет без особых усилий пощупать все эти «замечательные» особенности Rust'а, могу предложить отладить вот эту программку. Это — маленькое приложение-пример, демонстрирующее использование из-под Rust'а сишного GUI-фреймворка Nuklear с GDI+ бэкендом. Бинарник при правильной сборке получается менее 300 Кб. Так вот, если вы попытаетесь собрать это не под 64-битную винду, а под 32 бита, полученный exe свалится с сегфолтом. Задача: разобраться, почему 64 бита компилируется нормально, а 32 дают нерабочий бинарник.
                ответ
                Ошибка находится в файле nuklear-rust/nuklear-sys/src/lib.rs, в этом коде:
                #[repr(C)]
                #[derive(Copy, Clone)]
                pub union nk_handle {
                    pub ptr: *mut ::std::os::raw::c_void,
                    pub id: ::std::os::raw::c_int,
                    _bindgen_union_align: u64,
                }
                
                где _bindgen_union_align нужно объявить как u32 для 32-битной сборки, чтоб получить рабочий бинарник.
                Когда найдёте и исправите первый баг, получив рабочий бинарник, вот вам задачка повышенной сложности: определить, почему под 32 бита в окне обрезается половина надписей в контролах, когда на 64 битах всё _вроде бы_ нормально. (На самом деле ни хрена не нормально, просто команды прорисовки контролов «удачно» встали, но перетасовав их местами можно и на 64 битах получить тот же эффект).
                На этот раз подсказывать не буду — не стану портить «удовольствие». И да, понадобится отладчик — придётся лазить в asm-код.
                Подводя итог, Rust — это последнее, что я хотел бы использовать, если придётся писать и отлаживать биндинги к C/C++ коду. Вот просто ужас-ужас такое потом саппортить.
                  +3

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


                  D:\git\nuklear-rust\nuklear-sys>cargo test --target=i586-pc-windows-msvc
                     Compiling nuklear-sys v4.0.4 (D:\git\nuklear-rust\nuklear-sys)
                      Finished dev [unoptimized + debuginfo] target(s) in 2.02s
                       Running target\i586-pc-windows-msvc\debug\deps\nuklear_sys-1bc3559804f4b9c2.exe
                  
                  running 106 tests
                  test bindgen_test_layout_nk_baked_font ... FAILED
                  test bindgen_test_layout_nk_allocator ... FAILED
                  test bindgen_test_layout_nk_buffer ... FAILED
                  [...]
                  
                  test result: FAILED. 54 passed; 52 failed; 0 ignored; 0 measured; 0 filtered out
                    +6
                    под 32 бита, полученный exe свалится с сегфолтом

                    Это не проблема языка, а лично моя, поскольку я не проверял бинды под 32-битность. Баг есть, времени на его ковыряние — нет.
                    Также bindgen сам по себе рассадник сегфолтов, произведенное им надо править руками в случае любого сложного заголовка.
                    Да, и очень интересно узнать, как дела с кроссплатформенными биндами в си у других языков. Без сарказма — я просто не интересуюсь.

                      0
                      Да, и очень интересно узнать, как дела с кроссплатформенными биндами в си у других языков. Без сарказма — я просто не интересуюсь.

                      То ли у меня парсер сломался, то ли это взаимоисключающие параграфы, ну да ладно.


                      А вообще — у моего любимого хаскеля есть штатный FFI в language report'е, но он скучный и не очень безопасный (можно опечататься в сигнатуре сишной функции, и никто это не поймает). Есть чуть более интересный inline-c для мелких штуковин, которые можно написать вот прям, как подсказывает имя, инлайн в исходнике.


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

                        +2

                        Но в этих случаях ничего автоматически и без бубна не делается, если платформ больше одной?


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

                          0

                          Я сходу не вижу необходимости для бубна. В частности, почти наверняка тот код соберётся под маком, хотя я писал и тестировал это всё под линуксом. На одной из прошлых работ коллеги вообще что-то там делали то ли для спарка, то ли для aix'а.

                            +1

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

                              0

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

                              0

                              Если выравнивание (alignment) так же будет прописано константами, то тоже может сегфолтиться для структур/объединений с разным выравниванием на разных платформах.

                                0

                                А что там у Rust untagged unions? Я чет совсем потерял контакт с их статусом.

                                  +2

                                  В той, части, что необходима для FFI (кроме unnamed unions) они были стабилизированы в Rust 1.19. Сейчас решают, как они должны взаимодействовать с non-Copy и Drop типами.

                                  0

                                  Там оно вроде как при сборке парсится и вычисляется. Но я не уверен в этом на 100%, надо перепроверить.

                                    +1

                                    То есть биндинги генерируются при каждой сборке? Тогда — да, сегфолтов не будет. Возможно будут трудности с кросс-компиляцией. В принципе такое можно организовать и в Rust с помощью build.rs.

                                      0
                                      То есть биндинги генерируются при каждой сборке?

                                      Да.


                                      Вообще, судя по этому (и следующей сотне строк) там относительно честный расчёт структуры. Интересно, как оно работает с #pragma pack.

                                0
                                я имел в виду, что не интересуюсь биндами к си в других языках, потому спрашиваю без сарказма.
                                «Не интересуюсь» = «мне это не интересно», а зачем спрашивать, если ответ не интересен — непонятно. Видимо, имелось в виду «не узнавал/не интересовался».
                                  +3

                                  Потому что возник вопрос, очевидно же. Это не значит, что я начну ими интересоваться в достаточной для компетенции мере.

                                    0
                                    «Спрашиваю потому что возник вопрос»? Действительно очевидно.
                              0
                              D вообще бинарно совместим с C — просто влинковываем объектник и всё работает.
                              В C# есть атрибут DllImport — можно делать биндинги к любой нативной dll. Есть некоторые проблемы с маршалингом — базовые типы (int, float, string) работают более-менее, более сложное нужно разруливать руками. В целом терпимо :)
                              За другие языки не скажу.
                              0
                              А если в обратную сторону использовать? Вызывать раст и С
                              0
                              Год назад мониторил. В основном предложения есть у криптовалютных стартапов. Rust мне самому безумно нравится, но боюсь что он останется крайне нишевым языком.
                                +1

                                Есть ещё надежда на WebAssembly, под который он идеально подходит. Ну и, в принципе, можно было бы как альтернативу Go его продвигать.

                                  0

                                  А под webassembly не проще ли на typescript писать? Или есть онисничения?

                                    0

                                    Для typescript пока экспериментальные варианты только есть. А Rust, в принципе, изначально под WebAssembly делался. А как по факту будет, поживём — увидим :-)

                                  +1

                                  Как го альтернативу вряд ли. Как c++ да. Но вот на одном проекте столкнулся с довольно обоснованным возражением и этому от руководства: думали сделать сервис на rust, но поняли, что кто умеет rust, тот и c++ умеет. Только c++ грабли известные, бизнес процессы отработанные, разработчиков искать легче. Выгода от rust оказалась неоднозначной для руководства.

                                    +9

                                    Это они только думают, что C++ умеют. Я первые десять лет практики на C++ тоже так думал.

                                      0

                                      Да, конечно, в любом хоть сколько-то сложном языке есть уровни и уровни Мастерства.

                                        0
                                        Когда мастер совершает детские ошибки, то мастер ли он?
                                          0

                                          Вы о чём?

                                            0
                                            Ошибки управления памятью совершают даже мастера.
                                      0
                                      До 70% всех CVE можно устранить при помощи Rust. Для некоторых руководителей это весомый аргумент.
                                        +1

                                        Ценой сложности и новых неочевидных ошибок — пример выше просто отличный.

                                  0

                                  А раст разве уже production-ready?

                                    –5
                                    Нет. И пока не ожидается.

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

                                    Ну и потому что это синтаксический ад, как выше привели пример
                                      +5

                                      Да. А с чего бы нет? Знаю компании, которые используют его в продакшене и вроде как довольны.

                                        +3

                                        Я бы с интересом почитал про опыт на расте в проде. Пока все, что я слышал про реально сложные задачи на расте, негативно. Конкаренси там, работа с сетью, с io

                                          +2

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


                                          Но concurrency — это большая проблема в любом языке, и я не вижу причин, почему Раст тут может быть "хуже".


                                          Про проблемы с io я в целом не слышал. Что конкретно имеется в виду?


                                          Кстати возможно будет интересно сравнение производительности Rust и десятка других языков в реальной задаче: https://github.com/ixy-languages/ixy-languages

                                            0

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

                                              0

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

                                                +2

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

                                                  0

                                                  Тушите свет, жереников при жизни Роба Пайка не будет

                                                +2

                                                ИМХО в Го тоже не всё ок. Примитивов для какой-то более-менее продвинутой работы с конкаренси нет, гарантируемого компилятором STM нет, гарантируемого детерминированного параллелизма тоже нет. После некоторых других языков я, если честно, не знаю, что там в Го вообще ок.

                                                  0

                                                  А какие претензии к конкарренси в го?

                                                    0

                                                    Я ж написал в предыдущем комментарии.

                                                0
                                                Но concurrency — это большая проблема в любом языке, и я не вижу причин, почему Раст тут может быть "хуже".

                                                Ну, так-то у Rust упрощение работы с ней подаётся как одна из киллер-фич...

                                                  0

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

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

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

                                                    0
                                                    Опять же о купибилете — там, насколько помню, много чего важного (по крайней мере там, куда я собеседовался) переносилось на Rust.

                                                    Вообще, насколько я понял за время работы с этим языком — не имеет смысла переносить на него небольшие сервисы или утилиты — время разработки не окупится плюшками, получаемыми от использования Rust.
                                                    А вот там, где время отладки и доработки потенциально может быть большим (в сравнении с полным жизненным циклом) — там он очень даже может быть полезен, т.к. сам принцип написания программ на этом языке смещает время с отладки и вылавливания битых поинтеров на архитектуру и построение продуманных интерфейсов (иначе, утрированно говоря, не скомпилится).
                                                    Но это уже ИМХО
                                                      +2

                                                      Сотрудники Купибилет мне лично говорили, что полностью переписывают свой бекенд с Ruby на Rust.

                                                        –4

                                                        Ну переписать то это полдела. Нужно, чтобы оно потом работало

                                                          +1

                                                          К чему этот комментарий? ЕМНИП, переписываются отдельные модули, которые сразу же интегрируются в систему.

                                                            0

                                                            К тому что стоимость разработки и стоимость поддержки — разные вещи.
                                                            И для разных языков соотношение отличается.


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


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


                                                            Ответил, к чему комментарий?

                                                              0

                                                              К тому, что, по Вашему мнению, Ruby — из вторых, а Rust — из первых?

                                                                0

                                                                Понятия не имею, ни на одном из них не писал. Но судя по тому, что говорит сообщество одного и второго — да, как-то так.

                                                                  0

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


                                                                  Это не потому что "в языке куча магии и неявных конструкций, преобразований и додумываний, которые значительно ускоряют разработку, но потом сиди и думай, "это автор так хотел, или компилятор/интерпретатор так додумал".". Это потому что Раст-разработчиков сегодня очень мало и стоят они дорого.


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


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

                                                                    0

                                                                    Хорошо, если так. Я в свое время не осилил раст и поэтому ушел в го с красивым конкарренси и сборщиком мусора. Про раст ничего плохого сказать не могу, но про продуктивные проекты на нем слышал негативные отзывы, откуда и интерес к тем, кто больше в теме.

                                                                      0

                                                                      Я перешел на Раст как раз из-за большей его подуктивности: могу писать широкий диапазон программ на нем, у него отличная модульная и компонентная системы — легко переиспользовать свой и чужой код, а мощная система типов сильно облегчает поддержку, делает рефакторинг безболезненным (благодаря ей и эволюционное прототипирование в Расте хорошо работает).


                                                                      В Rust я могу справляться со значительно большей кодовой базой и большим числом проектов, чем в других языках (Java, JavaScript, Python, PHP, C++).


                                                                      Для меня решающим плюсом Раста стала автоматизация рутины (!), которую он дает. Да, рутинный код все еще приходится писать, когда ты пытаешься выразить логику в отношениях типов, но однажды написав — можно смело выкинуть из головы, ибо проверять ее будет компилятор, а тебе не за чем. Тогда как в других языках тебе приходится постоянно проигрывать в голове рутинную логику, так как их системы типов не способны ее зафиксировать.

                                                                      –1
                                                                      Язык макросов в Расте отличается от обычного Растовского синтаксиса, и я бы поостерегся их использовать.

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

                                                                      Раст для 100% надежности требует 100% инфраструктуры на Расте, без компромиссов. А такая появится нескоро.

                                                                      С Руби сравнивать нельзя — разные во всем — от области применения, до требований к квалификации. Ну и конечно сравнивать компилятор с динамической интерпретацией это…
                                                                        0
                                                                        Язык макросов в Расте отличается от обычного Растовского синтаксиса, и я бы поостерегся их использовать.

                                                                        Чем отличается? Как цикл while от цикла for? Это такая же часть языка. Да, у макросов много проблем, но без них было бы хуже.


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

                                                                        Я ни слова не писал о проблемах взаимодействия с С. Да, возможно это для кого-то сюрприз, но это сложно делать в абсолютно любом языке, но это не говорит о том что абсолютно все языки кроме С — плохие. Я не понаслышке знаю о проблемах взаимодействия с С из Раста, поверьте. Проблемы ли это Раста? Не думаю. Мешает ли это писать поддерживаемый код? Точно нет. В чем ваш аргумент?


                                                                        Раст для 100% надежности требует 100% инфраструктуры на Расте, без компромиссов. А такая появится нескоро.

                                                                        Спорно, но соглашусь. А что вы выберете — 90% надежности или 0%? Не вижу причин не внедрять дополнительную надежность с помощью инструментов, которые это позволяют.


                                                                        С Руби сравнивать нельзя — разные во всем — от области применения, до требований к квалификации. Ну и конечно сравнивать компилятор с динамической интерпретацией это…

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

                                                                      0

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


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

                                                    +1
                                                    Ну, например, если Вы читаете этот текст в браузере Firefox, то очень большая часть работы по его выводу на экран сделана именно кодом на Rust. Процентов 20% минимум.
                                                    +1

                                                    Я когда искал работу на Rust рассматривал сразу 3 вакансии, причем все — удаленная работа и в русскоязычном сегменте (работу в офисе не рассматривал, хотя там были еще вакансии). Я соглашусь с тем, что пока нет регулярного, стабильного спроса на Rust-разработчиков. Но если у вас есть пара месяцев на поиск работы и вы достаточно опытны (джунам найти работу на Rust тяжелее), то выбор у вас будет.

                                                    +6
                                                    Elixir прекрасен. Можно сказать два языка которые спасли меня от выгорания, это F# и Elixir.
                                                    Жаль, что вакансий на Elixir практически нет, но хоть больше, чем на F#, на котором их нет совсем. Последнее время хочется соскочить с иглы C#, на один из этих двух языков. Elixir пока забросил, а на F# даже пишу небольшие пет-проекты, но вот открываю HH и МойКруг и грустно становится.
                                                      +1

                                                      Согласен. F# — тоже весьма приятный язык. А по поводу вакансий, для Elixir есть: https://elixirjob.ru/
                                                      Возможно, для F# тоже есть подобный агрегатор вакансий?

                                                        +1
                                                        Ого, за сайт огромное спасибо! Появился стимул начать подтягивать Elixir:)
                                                          0

                                                          Это здорово :)
                                                          Вы только не подумайте, что там все 20+ страниц актуальные вакансии, актуальные — первые 2-3 страницы, что, впрочем, тоже неплохо.

                                                            +2
                                                            10-20 вакансий, это тоже очень и очень достойно. Порадовало, что даже на малой родине пишут на Elixir, под их требования я конечно не подхожу, но если придется возвращаться, буду стучаться всеми частями тела:)
                                                      +3

                                                      И dart-a нет, не зачёт. ತ_ʖತ

                                                        +2
                                                        3 года подождём… посмотрим…
                                                          +1

                                                          Кстати, про Dart я вспоминал, перечитывая комментарии к прошлой статье. Тогда Vilyx сокрушался по тому же поводу.


                                                          Стоит отметить, что за 3 года он продвинулся на ощутимые +11% по графику Redmonk. Но он 3 года назад уже был устоявшимся языком, поэтому и не попал в исходную статью, а как следствие и в эту.

                                                            0
                                                            Dart по абсолютному возрасту моложе Rust. Kotlin можно считать ровесником или старше от момента начала разработки. Устоявшимся Dart мог показаться из-за удачной реализации, недавно вторую версию представили, значит меняется. За три года, по моим ощущениям, сильно расширилась область применения, появилась возможность полноценно разрабатывать под мобильные платформы и одной ножкой язык наступил в область разработки под десктоп.

                                                            Жаль, что язык не попал в статьи, ему тут самое место.
                                                              +1

                                                              Я согласен, что Dart идёт примерно в той же области, что и тройка лидеров из статьи. Будет классно, если Вы примерно в том же стиле, как в статье, чуть подробнее распишете, что произошло с Dart за 3 года. Я думаю, многим будет это интересно. А посколько вы его используете на практике, то и информация будет более полной, чем от стороннего наблюдателя.


                                                              P.S. На мой взгляд, помимо Dart ещё Julia незаслуженно обделена вниманием оказалась. У неё и версия 1.0 год назад вышла и рост популярности она показала почти такой же как Elixir.

                                                                +1

                                                                С Dart случился Flutter.

                                                          0
                                                          Так что если Oracle продолжит закапывать Java,

                                                          Ни разу не против Kotlin (и только за), но ткните меня лицом, где Oracle закапывает именно Java.

                                                            +2

                                                            Я имел в виду, что закручивая гайки по патентам, связанным с Java, Oracle делает из JVM платформу, с которой крупные компании не захотят больше связываться. Само собой, миллионы компаний уже связались, поэтому у Oracle пока что есть широкое пространство для манипуляций текущей ситуацией.

                                                              +2
                                                              Воу, воу, подождите, разве OpenJDK уже похоронили?
                                                                +1

                                                                Пока нет. Но всё равно стойкое ощущение, что Oracle гребёт против тенденций и непонятно, куда его занесёт.

                                                                –1
                                                                > Я имел в виду, что закручивая гайки по патентам, связанным с Java

                                                                моё мнение — вы заблуждаетесь. В споре Google vs Oracle используется слово «Java», только вывод вы делаете неправильный из этого. Чуваки из Google получили нахаляву программистов для программ для своей ОС, решив использовать API от Java SE. Oracle задала вопрос: «Какого фига? Давайте лицензируйтесь!» Это не имеет никакого отношения к использованию Java всеми остальными компаниями как ЯП с компилятором и рантаймом.
                                                                  +4
                                                                  Это не имеет никакого отношения к использованию Java всеми остальными компаниями как ЯП с компилятором и рантаймом.
                                                                  Это имеет прямое отношение ко всем остальным компаниям. Из веба Java, довольно-таки бесцеремонно, выпилили и уж явно никто и никуда её больше продвигать не будет. Хотя, конечно, выпилить её из тех мест, где она укоренилась непросто… но, в принципе, Native Kotlin даёт шанс.

                                                                  Oracle задала вопрос: «Какого фига? Давайте лицензируйтесь!»
                                                                  Лучшего способа загнать язык программирования куда-то в малозаметных нишу придумать просто нельзя. Если у тебя есть куча бесплатных альтернатив — то какой смысл выбирать что-то, за что нужно платить?

                                                                  То есть да, вы абсолютно правы: Oracle не хочет убить Java, они всего лишь хотят заработать денег… но де-факто — они могут это сделать только за счёт популярности Java.

                                                                  Впрочем популярность Java (за счёт периода «до Oracle») такова, что Oracle потребуется изрядно постараться, чтобы её убить…
                                                                    –1
                                                                    > Из веба Java, довольно-таки бесцеремонно, выпилили

                                                                    Java из web — это UI в браузере?

                                                                    > и уж явно никто и никуда её больше продвигать не будет.
                                                                    > Впрочем популярность Java (за счёт периода «до Oracle») такова, что Oracle потребуется изрядно постараться, чтобы её убить…

                                                                    ну вы и зануда =)
                                                                    на серверах она живёт и новые проекты на ней писались и в 2010, 2015, и пишутся без проблем сейчас в 2018, 2019: lamoda.ru, cian.ru, domclick.ru, sberbank.ru, revolut.com, игровые сервера… да много где. Вот вы играете в мобильные игры на своём смартфоне, а сервак этих игр без проблем бежит под JVM. Никаких проблем использовать Java нет, Камооон это же просто ЯП и крутой рантайм со сборщиком мусора и JIT =)
                                                                    Кто хочет использует Python/PHP/Go или что-то другое, нет проблем.
                                                                      +1
                                                                      > Из веба Java, довольно-таки бесцеремонно, выпилили

                                                                      Java из web — это UI в браузере?
                                                                      Угу. До того, как Oracle развил свою активность были планы сделать Java вторым языком, наравне с JavaScript. После — убили и то, что было.
                                                                        0
                                                                        В этом вы правы, не думаю, что кто-то сожалеет.
                                                                      –1
                                                                      > Это имеет прямое отношение ко всем остальным компаниям.
                                                                      Какое? Вы же не аргументируете свои слова ничем.

                                                                      Я привёл объяснение, что ваш довод — это неправильное понимание вопроса. Плохо ли поступает Oracle, что судится за API — отдельная тема. На Java это никак не влияет, серьёзно.
                                                                        +2

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


                                                                        Шумиха есть? Есть. Google заставят платить? Заставят. Oracle хочет монетизировать JVM за счёт её пользователей? Хочет.
                                                                        Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.

                                                                          0
                                                                          > Я не думаю, что каждая первая компаний будет читать юридическое разбирательство в десятке томов

                                                                          Вы на полном серьёзе считаете, что ведя разработку с использованием Java, никто: ни ТехДиректор, ни ТимЛид, ни программисты не будут в курсе про то, что я вам рассказал? Это ведь не секрет.

                                                                          > Вы же тоже материалы дела, наверняка, не читали…
                                                                          пары хороших статей на Хабре и англоязычных блогеров, найденных в сети, достаточно, чтобы свести информацию из разных источников для понимания, а потом пойти на сайт Oracle, чтобы узнать причину дискуссии
                                                                          www.oracle.com/downloads/licenses/standard-license.html

                                                                          в хороших статьях указываются цитаты, например как здесь habr.com/ru/post/424579

                                                                          > Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.

                                                                          Пожалуйста используйте то, что вам нравится. Главное не вводите людей в заблуждение или добавляйте «как мне известно» или «по моему мнению» к тому, что пишите. Ваши же слова очень категоричны
                                                                          — «Так что если Oracle продолжит закапывать Java, есть вероятность, что Android Team со временем откажется и от JVM»

                                                                          что вызывают только одну эмоцию: рука-лицо.
                                                                            0

                                                                            Убедили. Убрал это предложение.

                                                                  +2
                                                                  но ткните меня лицом, где Oracle закапывает именно Java
                                                                  например навязывая платную техподдержку
                                                                    +3
                                                                    Перед этим отдав Oracle JVM весь в OpenJDK. Наверное всё-таки им стоит сказать спасибо?
                                                                    Поэтому я поддержу вопрос: «где Oracle закапывает именно Java?»
                                                                      0

                                                                      И где же они её навязывают? На jdk.java.net можно свободно качнуть любую сборку, "без регистрации и смс". Ни слова о ТП или что-то там купить. Да, есть отсылка к платным сборкам, но кмк, оракл имеет право на это, владея сайтом

                                                                  • UFO just landed and posted this here
                                                                      +1

                                                                      И как оно? Не тянет что-то ещё попробовать?

                                                                        0

                                                                        А почему бы и нет? Приложения на Дельфи намного шустрее многих аналогичных на електроне к примеру.

                                                                        +3

                                                                        Хаскелевское avoid success at all costs — это не про avoid success, а про at all costs. То есть, при выборе того или иного решения успех у широкой публики не должен являться решающим фактором.

                                                                          +10

                                                                          Иначе говоря, не "любой ценой избегать успеха", а "избегать "успеха любой ценой""?

                                                                        0

                                                                        Clojure

                                                                          0

                                                                          Судя по графику, Clojure за 3 года потерял около 5% популярности. Язык всё ещё высоко, но тенденция не слишком обнадёживающая. Примерно такая же ситуация с D, он сполз на 4%.


                                                                          А Вы используете Clojure в работе? Поделитесь опытом и впечатлениями от изменений за предыдущие 2-3 года.

                                                                            +1

                                                                            Я пишу на ней за деньги последние 4 года. После удобств Clojure вернуться в императивный язык уже невозможно. Популярность это очень условная вещь. Если стало меньше вопросов на SO, это на значит, что язык загибается.

                                                                              0

                                                                              Clojure больше по оси Github растерял, но так то да, это всё относительно. Но косвенно говорит о том, что язык уже занял свою нишу.
                                                                              Впрочем, всё равно интересна ретроспектива от человека, который использует Clojure на практике. Поделитесь наиболее значимыми событиями в мире Clojure на пути c 1.8.0 до 1.10.1?

                                                                              0
                                                                              Мы сконтрабандили проект на Clojure втихую, но оказалось, что любителей на нем программировать в нашей компании раз-два и обчелся. В итоге после долгих обсуждений переписали проект на Python c Luigi. А так вообще проблем не было, кто не боится Clojure, код читается легко и приятно программировать.
                                                                            –1
                                                                            Очень неправильно сравнивать популярность языков по количеству проектов на GitHub. Во-первых там миллион проектов от учеников курсов и тп., куда завлекают «новым и самым прогрессивным» языком, а во-вторых там почти нет проектов серьезных компаний, которые предпочитают использовать проверенные временем языки. Из всех перечисленных реально выстрелил Котлин и Свифт. Вот только первый дальше Андроида не пошёл, куда был практически вбит Гуглом, а второй по-сути безальтернативный для яблочных девайсов. Из всех остальных, которым пророчили великое будущее, особо ничего и не выстрелило. Как был JS, Java, Phyton, C++/C# — так и остались.
                                                                              +2
                                                                              В смысле Котлин «не пошёл»? Довольно много компаний уже в том или ином объёме используют Котлин в бэкэнд-разработке, вакансий хватает.
                                                                                +3
                                                                                Очень неправильно сравнивать популярность языков по количеству проектов на GitHub.

                                                                                RedMonk сравнивает не по кол-ву репозиториев. Это я дополнительно этот критерий привёл, чтобы сравнительную динамику языков посмотреть. Ну и если вы не согласны с методологией RedMonk, то получается, что вы не согласны и с тем, что JavaScript, Java, Python, PHP, C++ и C# сейчас в мейнстриме, но при этом приводите практически идентичный список.


                                                                                миллион проектов от учеников курсов

                                                                                На которых преподают JS, Java, Python и чуть реже Ruby и C#.


                                                                                там почти нет проектов серьезных компаний

                                                                                Назовите хоть одну серьёзную компанию, которая в 2019 году не имеет OpenSource-активности.


                                                                                Как был JS, Java, Phyton, C++/C# — так и остались.

                                                                                Что значит "как был"? 15 лет назад никакого Python и C# в мейнстриме не было, а 20 лет назад там не было ни JS, ни Java. Всё течёт, всё изменяется. Естественно, языки из Top-10 набрали уже критическую массу популярности и даже если с завтрашнего дня перестанут начинать новые проекты на каком-то из них, пройдёт много лет пока он выпадет из 10-ки. Запаздывание рейтингов в этом плане огромно. Вон у Objective-C заняло 3 года, чтобы с 10-го места опуститься на 12-е. Поэтому интерес представляет именно движение за пределами Top-10, но в правой верхней четверти графика.

                                                                                  +3
                                                                                  Я, раньше всегда начинал проекты на Java. Энтерпрайз проекты. После того, как Pivotal заявил о своей поддержке Kotlin в Spring, а сделали они эту интеграцию, на мой взгляд, идеально — я попробовал этот язык в новом проекте и ни секунды не пожалел. Проект развивается, разработка ускорилась в разы. Поэтому зря вы про то, что дальше андроида он не пошел. Давно подумывал поменять деревянную Java на что-то более приятное и котлин оказался лучшим выбором.
                                                                                    0

                                                                                    Мне всегда странно когда говорят, что новый язык увеличил скорость разработки в разы.
                                                                                    Может я чем то не тем занимаюсь. но 60..80% в разработке ПО времени это не кодирование как таковое.
                                                                                    А кодирование… пусть Java до 8 уступала Kotlin. Пусть текста кода поменьше получается.
                                                                                    Но сказать что в разы ускоряет кодирование — то же как то перебор.
                                                                                    В сущности какая разница на чем. Нормальные IDE — ускоряют.

                                                                                      +4

                                                                                      Если на новом языке удаётся при прочих равных писать код с меньшим количеством багов и/или более простой отладкой — он вполне может сократить эти самые 60..80%.

                                                                                        +1
                                                                                        Еще добавлю. Я, как тим лид, и мне очень часто приходится проводить код ревью — я перестал видеть эти громоздкие конструкции Java. Код читается легко и быстро. И согласен, что отладка опять же легче, когда меньше кодовой лапши. Количество багов уменьшилось по этомй же причине. Поэтому я заявляю, что разработка ускорилась в разы. Я доволен как слон своим выбором, хотя раньше скептически относился к котлину, считая его очередной Scala (ничего против Scala не имею, приятный язык, но к сожалению, по многим причинам, он у нас в энтерпрайзе не пошел)
                                                                                  0
                                                                                  Мне кажется, что в случае Kotlin и (особенно) Swift сложно отделить популярность языка от популярности платформы.
                                                                                    0

                                                                                    Вообще, у Apple была идея сделать как раз таки язык не привязанный к платформе. Но может в силу инертности мышления разработчиков, а может в силу нестабильности ABI вплоть до 5-й версии, Swift пока не выстрелил как язык для веб-разработки, хотя у него всё для этого есть.


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

                                                                                      +2
                                                                                      > хотя у него всё для этого есть.
                                                                                      И что у него есть чтобы потеснить мейнстрим в этом секторе? Почему я должен перейти на Swift?
                                                                                        +1

                                                                                        Например, если вам нужен быстрый микросервис, но вам не нравится Go. Почему бы не рассмотреть Swift, как вариант?
                                                                                        А так вообще никто никому не должен. Да и вы даже не написали на чём сейчас программируете.

                                                                                          –2
                                                                                          А зачем мне переходить на Go.
                                                                                          Если мне нужен быстрый микросервис, то просто берем быстрое железо. ;)
                                                                                          Да и вы даже не написали на чём сейчас программируете.

                                                                                          JS,PHP, иногда Tcl.
                                                                                            0
                                                                                            Почему бы не рассмотреть Swift, как вариант?

                                                                                            Потому что есть сомнения, что быстрее хотя бы даже NodeJS. Или .Net Core. Или Java/Scala/Kotlin. При этом у любого из них экосистема не хуже Swift.
                                                                                              0

                                                                                              Так я и говорю, что не взлетело в этой области, взлетело бы — была бы и экосистема.
                                                                                              А не взлетело не из-за Swift как такового, а потому что и так выбор широкий, а тут ещё предрассудки, что язык от Apple == язык только для MacOS.

                                                                                          0
                                                                                          Objective C тоже, теоретически, можно где угодно применять. А практически — только в MacOS X (ну и её форке — iOS).
                                                                                            +1
                                                                                            Интересно было бы увидеть отношение популярности Kotlin\Java до майского анонса Google о приоритете Kotlin для Android и после.

                                                                                            Obj-C же совершенно не привязан к платформе Apple, но его популярность вне платформ Apple совершенно иная — в разы(или порядки) отличается. Вполне возможно, со Swift ситуация будет аналогичная и после стабилизации ABI.
                                                                                              0

                                                                                              Скоро обновление рейтинга опубликуют, можно будет сравнить. Текущий — по состоянию на июнь 2019. Вряд ли майский анонс на него успел сильно повлиять.

                                                                                            +1
                                                                                            А хуже всего то, что их и (особенно) Swift практическая ценность зависит от судьбы этой платформы.
                                                                                            Если она завтра по какой-то причине станет ненужной, то и язык ждет незавидная судьба.
                                                                                              +1

                                                                                              Почему? Swift работает и под GNU/Linux, и под Android, и даже под Windows.
                                                                                              Да и Mac OS X и iOS никуда исчезать не собираются, а значит Apple ещё будет выпускать новые версии и без того уже вполне стабильного языка. Код открыт под Apache License 2.0.
                                                                                              Т.е. по всем фронтам Swift в очень шоколадно-безопасных условиях находится. Даже если когда-нибудь настанет эплокапец, любая заинтересованная компания сможет взять Swift под своё крыло.

                                                                                                0
                                                                                                Почему? Swift работает и под GNU/Linux, и под Android, и даже под Windows.
                                                                                                Swift-то работает… а все фреймворки — нет. То же, что и с Objective C.

                                                                                                Т.е. по всем фронтам Swift в очень шоколадно-безопасных условиях находится. Даже если когда-нибудь настанет эплокапец, любая заинтересованная компания сможет взять Swift под своё крыло.
                                                                                                Но… зачем?
                                                                                                  0
                                                                                                  Swift-то работает… а все фреймворки — нет.

                                                                                                  Я не пробовал, честно говоря, но заявлено, что фреймворки на линуксе работают:
                                                                                                  https://github.com/vapor/apt
                                                                                                  https://www.kitura.io/docs/getting-started/installation-linux.html


                                                                                                  Да и что в них такого платформоспецифичного может быть?

                                                                                                    0
                                                                                                    Да и что в них такого платформоспецифичного может быть?
                                                                                                    Весь Cocoa?

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

                                                                                                    Это «запирает» язык на вашей платформе. Ровно та же история с C#, кстати: много вы проектов, не привязанных к Windows, на C# знаете? Разве что Unity 3D… А ведь там, теоретически, в кроссплатформенность куча усилий вбухана…
                                                                                                      +1
                                                                                                      вот Cocoa и привязан к платформе, зачем он нужен на других ОС? Там свои UI библиотеки (а то и нет их вообще, за отсутствием визуального UI как такового). Ситуация сильно лучше по сравнению с ObjC который даже кроссплатформенным толком не был (все сильно на рантайм было завязано, даже основы типа выделения памяти).
                                                                                                      В этом плане все похоже на C#, Kotlin, Go, где есть компания которая двигает язык, и если с ней что-то случится, то будущее языка становится туманно, потому что некому будет вбухивать деньги, развивать его дальше. В то же время не мало языков за которыми никогда и не стояло богатых компаний, типа Rust и Haskell, и которые никогда не станут мэинстримом, просто живут в своей нише со своими преданными фанатами. В этом плане у Swift (или C# и тд) больше шансов на видное место под солнцем, его уже знают больше людей.
                                                                                                        0

                                                                                                        Я имел в виду, что платформоспецифичного в веб-фреймворках… Зачем в них Cocoa?

                                                                                                          0
                                                                                                          Затем что основная фишка, которой мог бы быть интересен Swift — это перенос программ (в первую очередь игр), на нём написанных, на другую платформу. А для этого нужна Cocoa.

                                                                                                          Проблема курицы и яйца: имеющегося Swift-кода без использования Cocoa — исчезающе малое количество, а без имеющихся библиотек и фреймворков — что за преимущество у Swift'а перед каким-нибудь D или Rust'ом?
                                                                                                            0

                                                                                                            Мы просто о разных вещах говорим… Я про потенциальную возможность писать на Swift какие-то новые проекты, а вы про перенос существующих.


                                                                                                            что за преимущество у Swift'а перед каким-нибудь D или Rust'ом?

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

                                                                                                              0
                                                                                                              Ну все таки разработка UI и разработка бекенда довольно разные вещи. Проще все таки новый язык изучить чем переключиться с фронта на бек, все равно в сравнении со всеми необходимыми библиотеками и подходами язык небольшую долю времени отгрызет.
                                                                                            • UFO just landed and posted this here
                                                                                                +1
                                                                                                Веб-отдельно, десктопные приложения — отдельно, ондроид/иФоне тоже отдельно.

                                                                                                Только языки то так не делятся… они, за редким исключением, все общего назначения.


                                                                                                Ну и великий Фортран взирает на всю эту возню с олипийским спокойствием.
                                                                                                В топе500 у него конкурентов нету.

                                                                                                А как же R и Julia? xD

                                                                                                  0

                                                                                                  И куда вы отнесёте JavaScript, например? На нём всё пишут.

                                                                                                  0
                                                                                                  “А для Crystal остаётся узкая ниша компаний, чьи программисты недостаточно квалифицированы, чтобы осилить входной порог этих языков.” это ты как-то жестковато. Особенно с параллелизмом, который появился две недели назад.
                                                                                                    0

                                                                                                    При всей моей любви к Crystal, это, к сожалению, реально так. Основная фишка Crystal — это синтаксическая похожесть на Ruby. Зная Ruby, можно за день начать писать на Crystal. А карту производительности он уже может не успеть разыграть.


                                                                                                    Есть Go, Rust, D, да тот же обсуждаемый выше Swift… Все они имеют примерно одинаковый с Crystal performance, но при этом стабильны. Есть Elixir, Kotlin, Scala, Clojure, Haskell, C#, F#, которые на одном ядре чуть помедленнее, зато легко и непринужденно масштабируются и тоже стабильны. А чем может ответить Crystal? Параллелизмом, который появился две недели назад? Да и где он появился то, в master-ветке? И релизом 1.0 в 202x году? Прикинь, 733 задачи на 4 человек, сколько времени займёт всё это разгрести и дойти до фазы стабилизации?


                                                                                                    Как бы мне ни нравился Ruby-like синтаксис, не может это быть основным критерием при выборе языка. А какая ещё киллер-фича у Crystal, чтобы предпочесть его 10 вышеперечисленным языкам? Так то я надеюсь, что через следующие 2-3 года Crystal всё-таки сможет стабилизироваться и составить им компанию.

                                                                                                      0
                                                                                                      А какая ещё киллер-фича у Crystal, чтобы предпочесть его 10 вышеперечисленным языкам?
                                                                                                      Алгебраические типы при общей простоте языка. Из Go, Rust, D, Swift ими может похвастаться только Rust, но там нужно следить за управлением памятью, что по сути означает необходимость переучиваться по сравнению с условным Ruby или C#, что не сильно отличается от освоения скажем Haskell
                                                                                                        0

                                                                                                        Ну как-то маловато для киллер-фичи. Штука приятная, но этого мало, чтобы побудить к использованию нестабильной технологии. На мой взгляд, судьба Crystal напрямую зависит от того, когда они смогут 1.0 выпустить. Все философские разговоры на эту тему бессмысленны. Невозможно поддерживать интерес к языку 10 лет, не дав сообществу стабильную версию. А Crystal уже 7 лет исполнилось.

                                                                                                          +1
                                                                                                          Ну как-то маловато для киллер-фичи
                                                                                                          Хорошо, что хоть кто-то до этого наконец-то додумался, а то крупные корпорации только костыли делают.
                                                                                                          Невозможно поддерживать интерес к языку 10 лет, не дав сообществу стабильную версию.
                                                                                                          Это да
                                                                                                    +1
                                                                                                    Elixir — очень приятный язык, было бы на нём больше вакансий…

                                                                                                    Ещё очень хочется дальнейшего роста Nim, отличная замена питону получается.
                                                                                                      0
                                                                                                      Elixir — очень приятный язык, было бы на нём больше вакансий…

                                                                                                      Кол-во вакансий постепенно растёт. Я выше уже скидывал ссылку на https://elixirjob.ru/


                                                                                                      А у Nim те же проблемы, что и у Crystal, мало core-разработчиков и постоянно растущее кол-во issues.
                                                                                                      В итоге, конца и края нестабильной фазе не видно.

                                                                                                      0
                                                                                                      — «Так что если Oracle продолжит закапывать Java, есть вероятность, что Android Team со временем откажется и от JVM», — говорит автор.
                                                                                                      — «О какой ещё JVM на Android вы говорите? Ку-ку, *пта, проснитесь! Java Virtual Machine там и не было», — говорю ему я.

                                                                                                      Вы хоть темой поинтересовались бы перед тем как написать. Oracle развивает и Java, и JVM как сам Sun даже не делал, а к Android/DalvikVM это не относится ну вообще никак.

                                                                                                      Kotlin крут на Android тем, что поддерживает(ал) совместимость трансляции исходного кода в синтаксис Java SE 1.6, который когда-то выбрали в Google. Версии Java давно ушли вперёд, но Google не могут их поддерживать. Kotlin появился в нужное время и стал альтернативой, решившей проблему в желании писать меньше кода «на модном синтаксисе». IDEA давала большой бонус к использованию языка.

                                                                                                      Писать меньше кода хотят и на серверах, поэтому Kotlin становится популярнее и там, запускаясь на JVM. Kotlin входит в экосистему Java и не может существовать без неё. Говорить о Kotlin Native, как о замене, сейчас просто бессмысленно.
                                                                                                        0

                                                                                                        Ok. Убрал это предложение. У каждого из нас своя специализация и я, действительно, ничего не писал под Android, поэтому был не в курсе, что от JVM они изначально отказались.

                                                                                                          0
                                                                                                          Oracle действительно ведёт себя глупо. Глупо потому что ради цели заставить Google подписать лицензию, они стали пробовать разные тактики: «приводить куски кода, которые 1 к 1 были/есть в Sun/Oracle JDK». После того как это не получилось пошли по пути «вы украли весь наш API», который опасен прецендентым правом и может в будущем выйти боком всему рынку IT.

                                                                                                          Не глупо здесь только одно, желание заработать на труде, вложенном в развитие API, развитие платформы Java силами Sun и уже самого Oracle.
                                                                                                        0
                                                                                                        При таком раскладе, Elm остаётся чисто экспериментальным языком с теперь уже сомнительным будущим. Хотя есть люди, которые по-прежнему смотрят на Elm c оптимизмом. С их доводами можно ознакомиться тут.

                                                                                                        Стоит отметить, что ещё в комментариях к исходной статье dimsmol, fshp и hellosandrik высказывались в пользу PureScript, как более жизнеспособной альтернативы Elm. И хотя он тоже до сих пор не достиг версии 1.0, динамика релизов выглядит более обнадёживающей.
                                                                                                        Elm уже не падает во время исполнения в отличии от js или purescript, уже хорошо сжимается минификаторами, что purescript или js не светит по определению, уже имеет быстрый компилятор, уже имеет довольно понятные сообщения об ошибках. Чем purescript превосходит Elm?
                                                                                                          0
                                                                                                          Verilog и VHDL… Ну в каком-то смысле они тоже «языки», но где тогда System Verilog?
                                                                                                            0

                                                                                                            Судя по Github, System Verilog примерно в 6 раз менее популярен, чем Verilog, так что, видимо, не попал в Top-100.

                                                                                                          Only users with full accounts can post comments. Log in, please.