В 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:
Чтобы оценить продвижение языков по графику, я взял их координаты и посчитал дельту:
((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 перспективных языков?
MooNDeaR
Много голосов о применении Rust на практике, а вакансий всё нет и нет))
UPD:
А я хочу такие.
domix32
Так никто не спрашивал про работу, вопрос был про применение на практике. Вот и крафтил народ свои хомяки на актиксе.
Source Автор
Так бывает, когда программистов, которые хотят использовать язык, больше, чем вакансий от компаний, которые его уже применяют. Получается, что вакансии есть, но они быстро закрываются. И когда смотришь список открытых вакансий, кажется, что их совсем мало.
neon1ks
Вакансии висят месяцами. Компании ведут конкурсный отбор. Так что если открытых вакансий мало, то их реально мало.
Source Автор
Что касается Rust, он ещё часто идёт как вспомогательный язык в вакансии, типа
"Написание high-load сервисов на Go и Python с реализацией CPU-bound задач на Rust."
"Работать в основном с Go с небольшим количеством Java / Kotlin (Spring), Elixir и Rust в архитектуре микросервисов"
Т.е. компании уже пишут на Go, но пробуют Rust в качестве альтернативы.
Прям вот таких, чтобы нужен Rust-программист, действительно, пока маловато.
neon1ks
Второе допущение, ты анализируешь глобально. Локально всё может быть по другому. Например, в иркутской области ты вряд ли найдешь такие вакансии.
Source Автор
Локальные тренды всегда запаздывают. Когда вакансии дойдут до отделённых регионов России уже бессмысленно будет что-то анализировать. Поэтому да, начинается всё с глобального анализа и анализа рынка в США.
Color
Если в проекте есть го, то не совсем понятно, что там растом делать. Разве что если какие-то дикие проблемы с gc, но с этим вроде уже научились справляться.
Source Автор
Это цитаты из реальных вакансий с hh.ru, можете им написать — спросить о мотивах.
А судя по написанному, у одних Rust для CPU-bound задач, а у других микросервисы на нём.
NetBUG
У нас в компании, когда я приходит, стек был основан на JS/TS.
Появились задачи для нативного кода, они были решены на Rust.
Вакансия не сформировалась ни на секунду (и не факт, что появится: код небольшой, стабильный, и если аналогичные проблемы не появятся в будущем и не изменятся требования, маловероятно, что придётся с ним что-то делать).
Alexey2005
Потому что нет проектов, целиком написанных на Rust. Если же нам нужно сопрягаться с основной частью проекта, написанной на C/C++, то Rust — это как бы не худший выбор из возможных.
Вопрос: что напечатает эта программа? А она вне зависимости от действий внешней функции c_func выдаст… 0x0. Чтобы всё работало как надо, указатель нужно описать вот так:Работа с «сырой» памятью там настолько затруднена, и поверх наброшено столько мозголомных абстракций, что допустить ошибку при прописывании ffi-биндингов очень просто, а вот её отлов потом может занять буквально недели, и всё равно не будет полной уверенности, что на всех платформах программа будет стабильно работать.
Вот классический пример:
Да, вот такое вот мозговыносящее месиво, и если где-то в нём ткнул не тот символ, то компилятор сделает неявное копирование, и будет работать с копией, которая к тому же когда функция вернётся, станет невалидной и рано или поздно память будет чем-то переписана. Отлаживать такое — просто адский ад, особенно когда программа потом падает совсем не там, где «портится» долбанный указатель, да ещё и один раз из десяти, так что даже воспроизвести баг с трудом выходит.
И это ещё ничего. Куда веселее, когда вам нужно собрать программу под 32 и 64 бита, и вот вдруг оказывается, что сишный компилятор и Rust не сошлись во мнениях, как при разной битности должны выглядеть выравнивания внутри структур/union'ов либо разрядности отдельных элементов. И тоже где-то кем-то портятся данные, и ведь хрен поймёшь, почему так. Доходит до того, что приходится в отладчике смотреть ассемблерный код, разбираясь, как интерпретируются структуры внутри функций.
Если кто-то хочет без особых усилий пощупать все эти «замечательные» особенности Rust'а, могу предложить отладить вот эту программку. Это — маленькое приложение-пример, демонстрирующее использование из-под Rust'а сишного GUI-фреймворка Nuklear с GDI+ бэкендом. Бинарник при правильной сборке получается менее 300 Кб. Так вот, если вы попытаетесь собрать это не под 64-битную винду, а под 32 бита, полученный exe свалится с сегфолтом. Задача: разобраться, почему 64 бита компилируется нормально, а 32 дают нерабочий бинарник.
red75prim
Для справки: bindgen генерит и тесты. Конечно, очень бы не помешала поддержка генерации биндингов сразу для нескольких целей.
snuk182
Это не проблема языка, а лично моя, поскольку я не проверял бинды под 32-битность. Баг есть, времени на его ковыряние — нет.
Также bindgen сам по себе рассадник сегфолтов, произведенное им надо править руками в случае любого сложного заголовка.
Да, и очень интересно узнать, как дела с кроссплатформенными биндами в си у других языков. Без сарказма — я просто не интересуюсь.
0xd34df00d
То ли у меня парсер сломался, то ли это взаимоисключающие параграфы, ну да ладно.
А вообще — у моего любимого хаскеля есть штатный FFI в language report'е, но он скучный и не очень безопасный (можно опечататься в сигнатуре сишной функции, и никто это не поймает). Есть чуть более интересный inline-c для мелких штуковин, которые можно написать вот прям, как подсказывает имя, инлайн в исходнике.
Есть более тяжеловесный c2hs — там пусть у вас есть, например, хедер, тогда вы пишете специальный файл, который включает этот хедер, c2hs его парсит, генерирует внутри описания структур, понимает сишные типы, и так далее. Это если вкратце. Могу развернуть, если вдруг что заинтересовало.
snuk182
Но в этих случаях ничего автоматически и без бубна не делается, если платформ больше одной?
зы: я имел в виду, что не интересуюсь биндами к си в других языках, потому спрашиваю без сарказма.
0xd34df00d
Я сходу не вижу необходимости для бубна. В частности, почти наверняка тот код соберётся под маком, хотя я писал и тестировал это всё под линуксом. На одной из прошлых работ коллеги вообще что-то там делали то ли для спарка, то ли для aix'а.
snuk182
С юниксом вроде все просто и понятно, а вот с виндой у Rust тяжелые отношения. Потому и автогенеренные бинды внезапны чуть менее чем полностью.
0xd34df00d
С виндой и у хаскеля тяжелые отношения так-то, так что про неё я сказать ничего не могу.
red75prim
Если выравнивание (alignment) так же будет прописано константами, то тоже может сегфолтиться для структур/объединений с разным выравниванием на разных платформах.
snuk182
А что там у Rust untagged unions? Я чет совсем потерял контакт с их статусом.
red75prim
В той, части, что необходима для FFI (кроме unnamed unions) они были стабилизированы в Rust 1.19. Сейчас решают, как они должны взаимодействовать с non-Copy и Drop типами.
0xd34df00d
Там оно вроде как при сборке парсится и вычисляется. Но я не уверен в этом на 100%, надо перепроверить.
red75prim
То есть биндинги генерируются при каждой сборке? Тогда — да, сегфолтов не будет. Возможно будут трудности с кросс-компиляцией. В принципе такое можно организовать и в Rust с помощью build.rs.
0xd34df00d
Да.
Вообще, судя по этому (и следующей сотне строк) там относительно честный расчёт структуры. Интересно, как оно работает с
#pragma pack.Chamie
snuk182
Потому что возник вопрос, очевидно же. Это не значит, что я начну ими интересоваться в достаточной для компетенции мере.
GrimMaple
D вообще бинарно совместим с C — просто влинковываем объектник и всё работает.
В C# есть атрибут DllImport — можно делать биндинги к любой нативной dll. Есть некоторые проблемы с маршалингом — базовые типы (int, float, string) работают более-менее, более сложное нужно разруливать руками. В целом терпимо :)
За другие языки не скажу.
gotozero
А если в обратную сторону использовать? Вызывать раст и С
valis
Год назад мониторил. В основном предложения есть у криптовалютных стартапов. Rust мне самому безумно нравится, но боюсь что он останется крайне нишевым языком.
Source Автор
Есть ещё надежда на WebAssembly, под который он идеально подходит. Ну и, в принципе, можно было бы как альтернативу Go его продвигать.
JekaMas
А под webassembly не проще ли на typescript писать? Или есть онисничения?
Source Автор
Для typescript пока экспериментальные варианты только есть. А Rust, в принципе, изначально под WebAssembly делался. А как по факту будет, поживём — увидим :-)
JekaMas
Посмотрел, народ вроде применяет уже ts вполне себе https://github.com/GuildOfWeavers/genSTARK
JekaMas
Как го альтернативу вряд ли. Как c++ да. Но вот на одном проекте столкнулся с довольно обоснованным возражением и этому от руководства: думали сделать сервис на rust, но поняли, что кто умеет rust, тот и c++ умеет. Только c++ грабли известные, бизнес процессы отработанные, разработчиков искать легче. Выгода от rust оказалась неоднозначной для руководства.
0xd34df00d
Это они только думают, что C++ умеют. Я первые десять лет практики на C++ тоже так думал.
JekaMas
Да, конечно, в любом хоть сколько-то сложном языке есть уровни и уровни Мастерства.
alsoijw
Когда мастер совершает детские ошибки, то мастер ли он?
JekaMas
Вы о чём?
alsoijw
Ошибки управления памятью совершают даже мастера.
jlogv
До 70% всех CVE можно устранить при помощи Rust. Для некоторых руководителей это весомый аргумент.
JekaMas
Ценой сложности и новых неочевидных ошибок — пример выше просто отличный.
Color
А раст разве уже production-ready?
Siemargl
Нет. И пока не ожидается.
Например, потому что последний релиз компилятора ломает тысячи библиотек кода
Ну и потому что это синтаксический ад, как выше привели пример
freecoder_xx
Да. А с чего бы нет? Знаю компании, которые используют его в продакшене и вроде как довольны.
Color
Я бы с интересом почитал про опыт на расте в проде. Пока все, что я слышал про реально сложные задачи на расте, негативно. Конкаренси там, работа с сетью, с io
vitvakatu
Думаю что проблемы с сетью в основном из-за малого количества готовых библиотек (из активно развивающихся я могу сейчас назвать только actix). Плюс подходы к разработке еще не вполне устоялись, люди тащат код из других языков и пытаются писать в привычном стиле.
Но concurrency — это большая проблема в любом языке, и я не вижу причин, почему Раст тут может быть "хуже".
Про проблемы с io я в целом не слышал. Что конкретно имеется в виду?
Кстати возможно будет интересно сравнение производительности Rust и десятка других языков в реальной задаче: https://github.com/ixy-languages/ixy-languages
Color
Не знаю, я с го сравниваю, а в го с конкарренси все ок. После го вообще многие языки кажутся ущербными в плане конкаренси и некоторых вещей, хотя это, конечно, не так.
vitvakatu
Да, в Го действительно легко писать параллельный код на горутинах. Не буду набрасывать, но Го хорош в одних задачах, Раст — в других. И эти задачи пересекаются только если люди плохо понимают отличия этих языков.
snuk182
Каналы из Go прекрасно работают и в Rust, дословно, включая свичи. Корутины в Rust слегка подзакинуты, но пока и без них все прекрасно. Я бы в плане конкурентного программирования сильно эти языки не противопоставлял, различий там минимум. Но типизация пока решает. Ждем дженерики в Go.
Color
Тушите свет, жереников при жизни Роба Пайка не будет
Cerberuser
Ну, так-то у Rust упрощение работы с ней подаётся как одна из киллер-фич...
vitvakatu
Да, с моей точки зрения с concurrency в Rust все в полном порядке — и уж точно не хуже, чем в остальных языках. Я лишь говорил о том, что если у кого-то возникают сложности с написанием такого кода — это не означает наличия проблемы в языке, просто это действительно сложно, и нужны правильные инструменты и правильные подходы к разработке.
irsdkv
Бэк купибилета вроде как на расте (вакансия, подтверждающая это гуглится довольно легко).
Когда проходил туда собеседование — впечатление от него были в целом положительные.
На тот момент (около года назад) была небольшая проблема только с наличием библиотек, но в остальном всё, по их словам, устраивало и даже приносило удовольствие.
Color
Действительно. Нашел несколько известных названий в списке продакшен-пользователей. Но не ясно, что там на беке — вся логика, или один замшелый сервис по генерации айди.
irsdkv
Опять же о купибилете — там, насколько помню, много чего важного (по крайней мере там, куда я собеседовался) переносилось на Rust.
Вообще, насколько я понял за время работы с этим языком — не имеет смысла переносить на него небольшие сервисы или утилиты — время разработки не окупится плюшками, получаемыми от использования Rust.
А вот там, где время отладки и доработки потенциально может быть большим (в сравнении с полным жизненным циклом) — там он очень даже может быть полезен, т.к. сам принцип написания программ на этом языке смещает время с отладки и вылавливания битых поинтеров на архитектуру и построение продуманных интерфейсов (иначе, утрированно говоря, не скомпилится).
Но это уже ИМХО
vitvakatu
Сотрудники Купибилет мне лично говорили, что полностью переписывают свой бекенд с Ruby на Rust.
Color
Ну переписать то это полдела. Нужно, чтобы оно потом работало
vitvakatu
К чему этот комментарий? ЕМНИП, переписываются отдельные модули, которые сразу же интегрируются в систему.
Color
К тому что стоимость разработки и стоимость поддержки — разные вещи.
И для разных языков соотношение отличается.
Есть языки, где написать что-то можно за день, а поддержка потом ногу сломит, потому что в языке куча магии и неявных конструкций, преобразований и додумываний, которые значительно ускоряют разработку, но потом сиди и думай, "это автор так хотел, или компилятор/интерпретатор так додумал".
Есть же и наоборот — языки, черезчур многословные и прямолинейные, где при разработке приходится очень много времени тратить на всякого рода бойлерплейтный код, но зато поддерживать одно удовольствие.
Ответил, к чему комментарий?
Cerberuser
К тому, что, по Вашему мнению, Ruby — из вторых, а Rust — из первых?
Color
Понятия не имею, ни на одном из них не писал. Но судя по тому, что говорит сообщество одного и второго — да, как-то так.
vitvakatu
Я полностью согласен с тем, что важно учитывать стоимость поддержки. Без конкретных цифр обсуждать это смысла нет, а цифр у меня нет, поэтому я предпочту согласится с тем, что поддерживать код на Расте выходит дороже, чем на некоторых других языках.
Это не потому что "в языке куча магии и неявных конструкций, преобразований и додумываний, которые значительно ускоряют разработку, но потом сиди и думай, "это автор так хотел, или компилятор/интерпретатор так додумал".". Это потому что Раст-разработчиков сегодня очень мало и стоят они дорого.
Не знаю про какой язык вы писали фразу выше, но если про Раст — на всякий случай скажу, что вы очень сильно заблуждаетесь. Раст как раз таки относится ко второй категории — той, где разработка долгая из-за непривычных подходов и бьющего по рукам компилятора, где для простейших паттернов из современной разработки нужно написать много строчек бойлерплейта, где использование макросов — залог выживания, потому что перегрузки функций нет, где синтаксического сахара немного (мы же сейчас частично про Руби говорим, да?), где девиз языка "явное лучше неявного" и тебе приходится тратить время, чтобы явно выразить свои намерения компилятору.
Ну а в результате ты получаешь простой, хорошо поддерживаемый код, с гарантией безопасности памяти и производительностью на уровне С/С++. И при этом тебе не обязательно тратить годы на изучение тонкостей языка.
Color
Хорошо, если так. Я в свое время не осилил раст и поэтому ушел в го с красивым конкарренси и сборщиком мусора. Про раст ничего плохого сказать не могу, но про продуктивные проекты на нем слышал негативные отзывы, откуда и интерес к тем, кто больше в теме.
freecoder_xx
Я перешел на Раст как раз из-за большей его подуктивности: могу писать широкий диапазон программ на нем, у него отличная модульная и компонентная системы — легко переиспользовать свой и чужой код, а мощная система типов сильно облегчает поддержку, делает рефакторинг безболезненным (благодаря ей и эволюционное прототипирование в Расте хорошо работает).
В Rust я могу справляться со значительно большей кодовой базой и большим числом проектов, чем в других языках (Java, JavaScript, Python, PHP, C++).
Для меня решающим плюсом Раста стала автоматизация рутины (!), которую он дает. Да, рутинный код все еще приходится писать, когда ты пытаешься выразить логику в отношениях типов, но однажды написав — можно смело выкинуть из головы, ибо проверять ее будет компилятор, а тебе не за чем. Тогда как в других языках тебе приходится постоянно проигрывать в голове рутинную логику, так как их системы типов не способны ее зафиксировать.
Siemargl
Язык макросов в Расте отличается от обычного Растовского синтаксиса, и я бы поостерегся их использовать.
Что касается хорошо поддерживаемого кода, то попытка интегрировать С-библиотеки в Раст бывает весьма болезненна, неперспективна и небезопасна, что ставит его в изначальную поул-позицию наравне с обычными языками (ну типа Паскаля, где тоже с С-интерфейсингом проблемы).
Раст для 100% надежности требует 100% инфраструктуры на Расте, без компромиссов. А такая появится нескоро.
С Руби сравнивать нельзя — разные во всем — от области применения, до требований к квалификации. Ну и конечно сравнивать компилятор с динамической интерпретацией это…
vitvakatu
Чем отличается? Как цикл while от цикла for? Это такая же часть языка. Да, у макросов много проблем, но без них было бы хуже.
Я ни слова не писал о проблемах взаимодействия с С. Да, возможно это для кого-то сюрприз, но это сложно делать в абсолютно любом языке, но это не говорит о том что абсолютно все языки кроме С — плохие. Я не понаслышке знаю о проблемах взаимодействия с С из Раста, поверьте. Проблемы ли это Раста? Не думаю. Мешает ли это писать поддерживаемый код? Точно нет. В чем ваш аргумент?
Спорно, но соглашусь. А что вы выберете — 90% надежности или 0%? Не вижу причин не внедрять дополнительную надежность с помощью инструментов, которые это позволяют.
Да я особо не сравнивал, мне просто в контексте упоминания синтаксического сахара вспомнился Ruby (как раз недавно много времени потратил на попытки разобраться в документации одной софтины на нем).
tangro
Ну, например, если Вы читаете этот текст в браузере Firefox, то очень большая часть работы по его выводу на экран сделана именно кодом на Rust. Процентов 20% минимум.
freecoder_xx
Я когда искал работу на Rust рассматривал сразу 3 вакансии, причем все — удаленная работа и в русскоязычном сегменте (работу в офисе не рассматривал, хотя там были еще вакансии). Я соглашусь с тем, что пока нет регулярного, стабильного спроса на Rust-разработчиков. Но если у вас есть пара месяцев на поиск работы и вы достаточно опытны (джунам найти работу на Rust тяжелее), то выбор у вас будет.
danilstepa
Elixir прекрасен. Можно сказать два языка которые спасли меня от выгорания, это F# и Elixir.
Жаль, что вакансий на Elixir практически нет, но хоть больше, чем на F#, на котором их нет совсем. Последнее время хочется соскочить с иглы C#, на один из этих двух языков. Elixir пока забросил, а на F# даже пишу небольшие пет-проекты, но вот открываю HH и МойКруг и грустно становится.
Source Автор
Согласен. F# — тоже весьма приятный язык. А по поводу вакансий, для Elixir есть: https://elixirjob.ru/
Возможно, для F# тоже есть подобный агрегатор вакансий?
danilstepa
Ого, за сайт огромное спасибо! Появился стимул начать подтягивать Elixir:)
Source Автор
Это здорово :)
Вы только не подумайте, что там все 20+ страниц актуальные вакансии, актуальные — первые 2-3 страницы, что, впрочем, тоже неплохо.
danilstepa
10-20 вакансий, это тоже очень и очень достойно. Порадовало, что даже на малой родине пишут на Elixir, под их требования я конечно не подхожу, но если придется возвращаться, буду стучаться всеми частями тела:)
smind
И dart-a нет, не зачёт. ?_??
mokhin-denis
3 года подождём… посмотрим…
Source Автор
Кстати, про Dart я вспоминал, перечитывая комментарии к прошлой статье. Тогда Vilyx сокрушался по тому же поводу.
Стоит отметить, что за 3 года он продвинулся на ощутимые +11% по графику Redmonk. Но он 3 года назад уже был устоявшимся языком, поэтому и не попал в исходную статью, а как следствие и в эту.
Vilyx
Dart по абсолютному возрасту моложе Rust. Kotlin можно считать ровесником или старше от момента начала разработки. Устоявшимся Dart мог показаться из-за удачной реализации, недавно вторую версию представили, значит меняется. За три года, по моим ощущениям, сильно расширилась область применения, появилась возможность полноценно разрабатывать под мобильные платформы и одной ножкой язык наступил в область разработки под десктоп.
Жаль, что язык не попал в статьи, ему тут самое место.
Source Автор
Я согласен, что Dart идёт примерно в той же области, что и тройка лидеров из статьи. Будет классно, если Вы примерно в том же стиле, как в статье, чуть подробнее распишете, что произошло с Dart за 3 года. Я думаю, многим будет это интересно. А посколько вы его используете на практике, то и информация будет более полной, чем от стороннего наблюдателя.
P.S. На мой взгляд, помимо Dart ещё Julia незаслуженно обделена вниманием оказалась. У неё и версия 1.0 год назад вышла и рост популярности она показала почти такой же как Elixir.
aleki
С Dart случился Flutter.
CyberSoft
Ни разу не против Kotlin (и только за), но ткните меня лицом, где Oracle закапывает именно Java.
Source Автор
Я имел в виду, что закручивая гайки по патентам, связанным с Java, Oracle делает из JVM платформу, с которой крупные компании не захотят больше связываться. Само собой, миллионы компаний уже связались, поэтому у Oracle пока что есть широкое пространство для манипуляций текущей ситуацией.
roswell
Воу, воу, подождите, разве OpenJDK уже похоронили?
Source Автор
Пока нет. Но всё равно стойкое ощущение, что Oracle гребёт против тенденций и непонятно, куда его занесёт.
shishmakov
> Я имел в виду, что закручивая гайки по патентам, связанным с Java
моё мнение — вы заблуждаетесь. В споре Google vs Oracle используется слово «Java», только вывод вы делаете неправильный из этого. Чуваки из Google получили нахаляву программистов для программ для своей ОС, решив использовать API от Java SE. Oracle задала вопрос: «Какого фига? Давайте лицензируйтесь!» Это не имеет никакого отношения к использованию Java всеми остальными компаниями как ЯП с компилятором и рантаймом.
khim
Лучшего способа загнать язык программирования куда-то в малозаметных нишу придумать просто нельзя. Если у тебя есть куча бесплатных альтернатив — то какой смысл выбирать что-то, за что нужно платить?
То есть да, вы абсолютно правы: Oracle не хочет убить Java, они всего лишь хотят заработать денег… но де-факто — они могут это сделать только за счёт популярности Java.
Впрочем популярность Java (за счёт периода «до Oracle») такова, что Oracle потребуется изрядно постараться, чтобы её убить…
shishmakov
> Из веба 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 или что-то другое, нет проблем.
khim
shishmakov
В этом вы правы, не думаю, что кто-то сожалеет.
shishmakov
> Это имеет прямое отношение ко всем остальным компаниям.
Какое? Вы же не аргументируете свои слова ничем.
Я привёл объяснение, что ваш довод — это неправильное понимание вопроса. Плохо ли поступает Oracle, что судится за API — отдельная тема. На Java это никак не влияет, серьёзно.
Source Автор
Я не думаю, что каждая первая компаний будет читать юридическое разбирательство в десятке томов, чтобы сформировать правильное понимание вопроса. Вы же тоже материалы дела, наверняка, не читали… А опираясь на пересказы пересказов, сложно быть уверенным в правильности своего понимания вопроса.
Шумиха есть? Есть. Google заставят платить? Заставят. Oracle хочет монетизировать JVM за счёт её пользователей? Хочет.
Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.
shishmakov
> Я не думаю, что каждая первая компаний будет читать юридическое разбирательство в десятке томов
Вы на полном серьёзе считаете, что ведя разработку с использованием Java, никто: ни ТехДиректор, ни ТимЛид, ни программисты не будут в курсе про то, что я вам рассказал? Это ведь не секрет.
> Вы же тоже материалы дела, наверняка, не читали…
пары хороших статей на Хабре и англоязычных блогеров, найденных в сети, достаточно, чтобы свести информацию из разных источников для понимания, а потом пойти на сайт Oracle, чтобы узнать причину дискуссии
www.oracle.com/downloads/licenses/standard-license.html
в хороших статьях указываются цитаты, например как здесь habr.com/ru/post/424579
> Этого уже многим будет достаточно, чтобы при старте нового проекта выбрать условно C# вместо Java.
Пожалуйста используйте то, что вам нравится. Главное не вводите людей в заблуждение или добавляйте «как мне известно» или «по моему мнению» к тому, что пишите. Ваши же слова очень категоричны
— «Так что если Oracle продолжит закапывать Java, есть вероятность, что Android Team со временем откажется и от JVM»
что вызывают только одну эмоцию: рука-лицо.
Source Автор
Убедили. Убрал это предложение.
Siemargl
shishmakov
Перед этим отдав Oracle JVM весь в OpenJDK. Наверное всё-таки им стоит сказать спасибо?
Поэтому я поддержу вопрос: «где Oracle закапывает именно Java?»
CyberSoft
И где же они её навязывают? На jdk.java.net можно свободно качнуть любую сборку, "без регистрации и смс". Ни слова о ТП или что-то там купить. Да, есть отсылка к платным сборкам, но кмк, оракл имеет право на это, владея сайтом
TurboPascal55
А некоторые всё еще на Дельфи пишут… :) Причем за хорошую зарплату.
Source Автор
И как оно? Не тянет что-то ещё попробовать?
Tarik02
А почему бы и нет? Приложения на Дельфи намного шустрее многих аналогичных на електроне к примеру.
0xd34df00d
Хаскелевское avoid success at all costs — это не про avoid success, а про at all costs. То есть, при выборе того или иного решения успех у широкой публики не должен являться решающим фактором.
Cerberuser
Иначе говоря, не "любой ценой избегать успеха", а "избегать "успеха любой ценой""?
0xd34df00d
Да.
igrishaev
Clojure
Source Автор
Судя по графику, Clojure за 3 года потерял около 5% популярности. Язык всё ещё высоко, но тенденция не слишком обнадёживающая. Примерно такая же ситуация с D, он сполз на 4%.
А Вы используете Clojure в работе? Поделитесь опытом и впечатлениями от изменений за предыдущие 2-3 года.
igrishaev
Я пишу на ней за деньги последние 4 года. После удобств Clojure вернуться в императивный язык уже невозможно. Популярность это очень условная вещь. Если стало меньше вопросов на SO, это на значит, что язык загибается.
Source Автор
Clojure больше по оси Github растерял, но так то да, это всё относительно. Но косвенно говорит о том, что язык уже занял свою нишу.
Впрочем, всё равно интересна ретроспектива от человека, который использует Clojure на практике. Поделитесь наиболее значимыми событиями в мире Clojure на пути c 1.8.0 до 1.10.1?
Kirhgoff
Мы сконтрабандили проект на Clojure втихую, но оказалось, что любителей на нем программировать в нашей компании раз-два и обчелся. В итоге после долгих обсуждений переписали проект на Python c Luigi. А так вообще проблем не было, кто не боится Clojure, код читается легко и приятно программировать.
aPiks
Очень неправильно сравнивать популярность языков по количеству проектов на GitHub. Во-первых там миллион проектов от учеников курсов и тп., куда завлекают «новым и самым прогрессивным» языком, а во-вторых там почти нет проектов серьезных компаний, которые предпочитают использовать проверенные временем языки. Из всех перечисленных реально выстрелил Котлин и Свифт. Вот только первый дальше Андроида не пошёл, куда был практически вбит Гуглом, а второй по-сути безальтернативный для яблочных девайсов. Из всех остальных, которым пророчили великое будущее, особо ничего и не выстрелило. Как был JS, Java, Phyton, C++/C# — так и остались.
siziyman
В смысле Котлин «не пошёл»? Довольно много компаний уже в том или ином объёме используют Котлин в бэкэнд-разработке, вакансий хватает.
Source Автор
RedMonk сравнивает не по кол-ву репозиториев. Это я дополнительно этот критерий привёл, чтобы сравнительную динамику языков посмотреть. Ну и если вы не согласны с методологией RedMonk, то получается, что вы не согласны и с тем, что JavaScript, Java, Python, PHP, C++ и C# сейчас в мейнстриме, но при этом приводите практически идентичный список.
На которых преподают JS, Java, Python и чуть реже Ruby и C#.
Назовите хоть одну серьёзную компанию, которая в 2019 году не имеет OpenSource-активности.
Что значит "как был"? 15 лет назад никакого Python и C# в мейнстриме не было, а 20 лет назад там не было ни JS, ни Java. Всё течёт, всё изменяется. Естественно, языки из Top-10 набрали уже критическую массу популярности и даже если с завтрашнего дня перестанут начинать новые проекты на каком-то из них, пройдёт много лет пока он выпадет из 10-ки. Запаздывание рейтингов в этом плане огромно. Вон у Objective-C заняло 3 года, чтобы с 10-го места опуститься на 12-е. Поэтому интерес представляет именно движение за пределами Top-10, но в правой верхней четверти графика.
Sigest
Я, раньше всегда начинал проекты на Java. Энтерпрайз проекты. После того, как Pivotal заявил о своей поддержке Kotlin в Spring, а сделали они эту интеграцию, на мой взгляд, идеально — я попробовал этот язык в новом проекте и ни секунды не пожалел. Проект развивается, разработка ускорилась в разы. Поэтому зря вы про то, что дальше андроида он не пошел. Давно подумывал поменять деревянную Java на что-то более приятное и котлин оказался лучшим выбором.
mmMike
Мне всегда странно когда говорят, что новый язык увеличил скорость разработки в разы.
Может я чем то не тем занимаюсь. но 60..80% в разработке ПО времени это не кодирование как таковое.
А кодирование… пусть Java до 8 уступала Kotlin. Пусть текста кода поменьше получается.
Но сказать что в разы ускоряет кодирование — то же как то перебор.
В сущности какая разница на чем. Нормальные IDE — ускоряют.
Cerberuser
Если на новом языке удаётся при прочих равных писать код с меньшим количеством багов и/или более простой отладкой — он вполне может сократить эти самые 60..80%.
akaAzazello
Мне кажется, что в случае Kotlin и (особенно) Swift сложно отделить популярность языка от популярности платформы.
Source Автор
Вообще, у Apple была идея сделать как раз таки язык не привязанный к платформе. Но может в силу инертности мышления разработчиков, а может в силу нестабильности ABI вплоть до 5-й версии, Swift пока не выстрелил как язык для веб-разработки, хотя у него всё для этого есть.
Да и Kotlin тоже никак к Android не привязан. Ну т.е. корреляция с мобильной разработкой безусловно есть у обоих языков, но ни один из них мобильной разработкой не ограничен.
Suntechnic
> хотя у него всё для этого есть.
И что у него есть чтобы потеснить мейнстрим в этом секторе? Почему я должен перейти на Swift?
Source Автор
Например, если вам нужен быстрый микросервис, но вам не нравится Go. Почему бы не рассмотреть Swift, как вариант?
А так вообще никто никому не должен. Да и вы даже не написали на чём сейчас программируете.
Suntechnic
А зачем мне переходить на Go.
Если мне нужен быстрый микросервис, то просто берем быстрое железо. ;)
JS,PHP, иногда Tcl.
DarthVictor
Потому что есть сомнения, что быстрее хотя бы даже NodeJS. Или .Net Core. Или Java/Scala/Kotlin. При этом у любого из них экосистема не хуже Swift.
Source Автор
Так я и говорю, что не взлетело в этой области, взлетело бы — была бы и экосистема.
А не взлетело не из-за Swift как такового, а потому что и так выбор широкий, а тут ещё предрассудки, что язык от Apple == язык только для MacOS.
khim
Objective C тоже, теоретически, можно где угодно применять. А практически — только в MacOS X (ну и её форке — iOS).
akaAzazello
Интересно было бы увидеть отношение популярности Kotlin\Java до майского анонса Google о приоритете Kotlin для Android и после.
Obj-C же совершенно не привязан к платформе Apple, но его популярность вне платформ Apple совершенно иная — в разы(или порядки) отличается. Вполне возможно, со Swift ситуация будет аналогичная и после стабилизации ABI.
Source Автор
Скоро обновление рейтинга опубликуют, можно будет сравнить. Текущий — по состоянию на июнь 2019. Вряд ли майский анонс на него успел сильно повлиять.
Suntechnic
А хуже всего то, что их и (особенно) Swift практическая ценность зависит от судьбы этой платформы.
Если она завтра по какой-то причине станет ненужной, то и язык ждет незавидная судьба.
Source Автор
Почему? Swift работает и под GNU/Linux, и под Android, и даже под Windows.
Да и Mac OS X и iOS никуда исчезать не собираются, а значит Apple ещё будет выпускать новые версии и без того уже вполне стабильного языка. Код открыт под Apache License 2.0.
Т.е. по всем фронтам Swift в очень шоколадно-безопасных условиях находится. Даже если когда-нибудь настанет эплокапец, любая заинтересованная компания сможет взять Swift под своё крыло.
khim
Но… зачем?
Source Автор
Я не пробовал, честно говоря, но заявлено, что фреймворки на линуксе работают:
https://github.com/vapor/apt
https://www.kitura.io/docs/getting-started/installation-linux.html
Да и что в них такого платформоспецифичного может быть?
khim
Когда у вас есть обширные проприетарные библиотеки на платформе, то автоматически теряется смысл выпускать что-то кроссплатформенное.
Это «запирает» язык на вашей платформе. Ровно та же история с C#, кстати: много вы проектов, не привязанных к Windows, на C# знаете? Разве что Unity 3D… А ведь там, теоретически, в кроссплатформенность куча усилий вбухана…
progn
вот Cocoa и привязан к платформе, зачем он нужен на других ОС? Там свои UI библиотеки (а то и нет их вообще, за отсутствием визуального UI как такового). Ситуация сильно лучше по сравнению с ObjC который даже кроссплатформенным толком не был (все сильно на рантайм было завязано, даже основы типа выделения памяти).
В этом плане все похоже на C#, Kotlin, Go, где есть компания которая двигает язык, и если с ней что-то случится, то будущее языка становится туманно, потому что некому будет вбухивать деньги, развивать его дальше. В то же время не мало языков за которыми никогда и не стояло богатых компаний, типа Rust и Haskell, и которые никогда не станут мэинстримом, просто живут в своей нише со своими преданными фанатами. В этом плане у Swift (или C# и тд) больше шансов на видное место под солнцем, его уже знают больше людей.
Source Автор
Я имел в виду, что платформоспецифичного в веб-фреймворках… Зачем в них Cocoa?
khim
Затем что основная фишка, которой мог бы быть интересен Swift — это перенос программ (в первую очередь игр), на нём написанных, на другую платформу. А для этого нужна Cocoa.
Проблема курицы и яйца: имеющегося Swift-кода без использования Cocoa — исчезающе малое количество, а без имеющихся библиотек и фреймворков — что за преимущество у Swift'а перед каким-нибудь D или Rust'ом?
Source Автор
Мы просто о разных вещах говорим… Я про потенциальную возможность писать на Swift какие-то новые проекты, а вы про перенос существующих.
Программистов, которые им владеют, гораздо больше. А для бизнеса это чуть ли не основной критерий. Ну и он менее хардкорный, чем D и Rust, значит и темп разработки будет повыше.
Neikist
Ну все таки разработка UI и разработка бекенда довольно разные вещи. Проще все таки новый язык изучить чем переключиться с фронта на бек, все равно в сравнении со всеми необходимыми библиотеками и подходами язык небольшую долю времени отгрызет.
MSC6502
Да уж давно пора разделить средства для программировния веба и языки программирования общего назначения и не валить всё в одну кучу.
Никто почему-то не сравнивает wolfram и С.
Веб-отдельно, десктопные приложения — отдельно, ондроид/иФоне тоже отдельно.
Ну и великий Фортран взирает на всю эту возню с олипийским спокойствием.
В топе500 у него конкурентов нету.
Source Автор
Только языки то так не делятся… они, за редким исключением, все общего назначения.
А как же R и Julia? xD
aleki
И куда вы отнесёте JavaScript, например? На нём всё пишут.
alexandrov
“А для Crystal остаётся узкая ниша компаний, чьи программисты недостаточно квалифицированы, чтобы осилить входной порог этих языков.” это ты как-то жестковато. Особенно с параллелизмом, который появился две недели назад.
Source Автор
При всей моей любви к 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 всё-таки сможет стабилизироваться и составить им компанию.
alsoijw
Source Автор
Ну как-то маловато для киллер-фичи. Штука приятная, но этого мало, чтобы побудить к использованию нестабильной технологии. На мой взгляд, судьба Crystal напрямую зависит от того, когда они смогут 1.0 выпустить. Все философские разговоры на эту тему бессмысленны. Невозможно поддерживать интерес к языку 10 лет, не дав сообществу стабильную версию. А Crystal уже 7 лет исполнилось.
alsoijw
Это да
Fenzales
Elixir — очень приятный язык, было бы на нём больше вакансий…
Ещё очень хочется дальнейшего роста Nim, отличная замена питону получается.
Source Автор
Кол-во вакансий постепенно растёт. Я выше уже скидывал ссылку на https://elixirjob.ru/
А у Nim те же проблемы, что и у Crystal, мало core-разработчиков и постоянно растущее кол-во issues.
В итоге, конца и края нестабильной фазе не видно.
shishmakov
— «Так что если 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, как о замене, сейчас просто бессмысленно.
Source Автор
Ok. Убрал это предложение. У каждого из нас своя специализация и я, действительно, ничего не писал под Android, поэтому был не в курсе, что от JVM они изначально отказались.
shishmakov
Oracle действительно ведёт себя глупо. Глупо потому что ради цели заставить Google подписать лицензию, они стали пробовать разные тактики: «приводить куски кода, которые 1 к 1 были/есть в Sun/Oracle JDK». После того как это не получилось пошли по пути «вы украли весь наш API», который опасен прецендентым правом и может в будущем выйти боком всему рынку IT.
Не глупо здесь только одно, желание заработать на труде, вложенном в развитие API, развитие платформы Java силами Sun и уже самого Oracle.
alsoijw
yatanai
Verilog и VHDL… Ну в каком-то смысле они тоже «языки», но где тогда System Verilog?
Source Автор
Судя по Github, System Verilog примерно в 6 раз менее популярен, чем Verilog, так что, видимо, не попал в Top-100.