Pull to refresh

Comments 146

Языки то конечно может перспективные. Но им далеко до повседневного использования. А «увядающие .NET/C#» еще много кого переживут.

P.S. Говорю как постоянный пользователь как C#, так и например Kotlin
Я согласен, что позиции C# прочны. Впрочем, MS не зря зашевелилась в сторону кроссплатформенности. Разработка приложений чисто под Windows сейчас уже далеко не так популярна, как лет 10 назад.

Самый популярный геймдев инструмент? Unity. На каком языке там пишут? :) Ну и по сути C# один из немногих не низкоуровневых языков, который позволяет (и имеет хороший тулинг) писать под всё и везде: back-end, десктопные нативные приложения под Windows, macOS, Linux. Нативные приложения под Android, iOS (с поддержкой любых нативных 3rd party), приставки и даже микроконтроллеры :-). В свежем отчете гитхаба C# за год в популярности подрос в два раза. В общем, я бы не назвал его увядающим.

Самый популярный геймдев инструмент?
C++ xD

Что ж Вы так резко реагируете то? Статья ведь вообще не об этом… Я, честно говоря, статью про увядающие языки вообще только после комментария прочитал )))
И хоть я бы лично не назвал C# увядающим, но с аргументами из той статьи тоже можно согласиться… Рынок веб- и mobile-приложений MS, мягко говоря, упустила из-за своей же близорукости. Никто им не мешал поддержать Mono ещё во времена .NET 2.0. И то, что они этого не сделали, по масштабности просчёта аналогично отказу от продолжения разработки браузера после победы над Netscape. Теперь приходится в спешке догонять конкурентов в упущенных нишах.
C++ xD

Инструмент, а не язык. Да и среди языков уже трудно сказать, кто на данный момент популярнее в геймдеве. На каждый один ААА-проект на PC и консолях, написанный на С++ с примесями Питона и Lua, приходится сотня небольших проектов на тех же PC и консолях и тысяча на мобилках. А они уже написанны на чём угодно, чаще всего на C# в Unity. И чем дальше, тем больше.


Microsoft, конечно, много лет тормозил, но спасибо, что не мешал. На рынке mobile-приложений, приносящих деньги (= игр), C# справился без Microsoft.

Инструмент, а не язык.
Язык — это тоже инструмент и ещё там смайлик был.
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
Ну сейчас и под комп пишут на Юнити. Тот же прекрасный KSP
Но им далеко до повседневного использования.

Например пользуюсь активно elixir, для новых проектов отличный вариант. Crystal — в глубокой альфе, его действительно не скоро можно будет по настоящему использовать. Kotlin — слышу об отдельных командах что на него переходят (как правило смесь старого кода на java + новый на котлин)

В принципе логично, что до выхода версии 1.0 язык не может активно использоваться в production.
Поэтому в повседневном использовании можно найти Rust, Elixir и Kotlin. А Crystal (0.19) и Elm (0.17) пока только для early birds. Хотя их версии уже намекают о близости RC, думаю, очень высока вероятность, что в 2017 году они выйдут в стабильной версии.
Котлин как раз таки повседневно используется. Сильно взлетел в мире андроид. А еще начали пилить Kotlin Native.
Kotlin Native — это на сколько я знаю, только слухи, ничем не подтвержденные, и даже вроде как опровергнутые JetBrains, не?

P.S. Сам использую Kotlin для своего opensource проекта, язык да, прикольный. Но время компиляции помноженное на тормоза gradle — это конечно ад :)
Уже подтвердили, Дмитрий Жемеров в одном из последних выступлений.

Какие тормоза? По сравнению с Java не ощущаю никакой разницы, тесты это в общем-то подтверждают: https://kotlin.link/articles/Kotlin-vs-Java-Compilation-speed.html
Kotlin vs Java — это возможно да. Но я, по правде говоря, сравниваю с C#, которым пользуюсь на работе как одним из основных языков (плюс C++ — процентов 25 кода). И вот если сравнивать с шарповыми проектами, Kotlin / Android Studio — это просто такой тормоз :( Нажимаешь «Run», уходишь делать чай, возвращаешся, оно только делает «installing apk...»
Сравнивать нужно одинаковые вещи, компиляция и запуск веб-приложения на Котлин занимает на моем ульрабуке 4-7 секунд. Сборка и деплой на замарине скорее всего не отличается по скорости от Java/Kotlin, потому что львиная доля этого времени — старт эмулятора.

В общем начить спорить на тему Kotlin (+ Java Platform естенствено) vs С# не вижу смысла.
Разделяю ваш справедливый гнев по поводу тормознутости сборки под андроид, но время компиляции медленное, безотносительно к котлину. Java + gradle будет так же медленно, как и kotlin + gradle. Из этого сравнения видно, что те же яйца только в профиль.
UFO just landed and posted this here

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

UFO just landed and posted this here

Где-то рядом с Elm, но на ступеньку повыше, я бы поставил PureScript.

А разве PureScript не является диалектом Haskell?
Спасибо, видимо, я его с GHCJS спутал.

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

Вы путаете PureScript и GHCJS.
PureScript — отдельный язык, причем гораздо более зрелый, чем Elm, но менее разрекламированный.
Elm по сравнению с PureScript выглядит «игрушечным» — хорошо решает отдельные задачи, но не очень-то универсальный.

Знаете ли, я не путаю. Я занимался и первым, и вторым, и третьим. Отличия PureScript от хаскеля в большой степени косметические. Поставляется он без стандартной библиотеки, то есть вообще без всего, даже Prelude нет.


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

Знаете ли, таки путаете. Я занимался оценкой применимости всех трех подходов (Elm, GHCJS, PureScript) для коммерческого проекта и пишу на PureScript прямо сейчас.

Да, PureScript близок к Haskell (за исключением не-ленивости) и по духу, и по синтаксису, и по мощности. До такой степени, что замечательную книгу PureScript by Example можно использовать для изучения некоторых концепций Haskell (они там иногда описаны понятнее, чем в книгах по самому Haskell, рекомендую). Но это не помешало в нужных местах срезать углы, чтобы генерировать более разумный/эффективный JS. Так что PureScript таки заточен на работу в JS-окружении. И очень неплохо заточен.

Поставляется он без стандартной библиотеки, то есть вообще без всего, даже Prelude нет

Вы не правы, либо ваша информация устарела. Вот PureScript Prelude, а вот и прочие пакеты, как правило они весьма высокого качества. То, что Prelude лежит в отдельном пакете, не делает ее менее стандартной, просто дает дополнительную гибкость. Если вы работали с Haskell, то знаете тамошнюю моду заменять стандартную Prelude на кастомную. В PureScript, кажется, просто учли, что люди любят так делать.

Elm же был построен вокруг реактивного программирования, с введением сигналов и адресов

Да, Elm построен вокруг определенного набора концепций и они вшиты в язык насмерть. Реализовать их на самом Elm не представляется возможным, как раз из-за «игрушечности» языка. В PureScript те же самые концепции можно реализовать самому, в виде обычной библиотеки. И много других концепций можно реализовать, которые окажется невозможно представить в Elm.

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

  • Package manager отказывается работать в Docker
  • Отсутствие нормальной поддержки приватных пакетов
  • Практически невозможно опубликовать пакет с использованием FFI (требует approve, а все кто может его делать, давно забили на это, пакеты ждут апрува по полгода и дольше)
  • Модель обработки сигналов требует проброса всех эффектов до самого корня иерархии компонент, это просто ад, когда часто нужны асинхронные вызовы
  • Практическая невозможность использовать альтернативные подходы, если их поддержка не встроена в язык
  • Elm сделан по подобию Haskell, но в нем часто не помогает ни опыт в Haskell, ни поддержка Haskell-сообщества, потому что в Elm многие вещи тупо не работают. Язык гораздо слабее, ему еще предстоит набивать свои шишки и наращивать мускулы там, где они решили отбросить что-то важное, на это уйдет много времени. Даже в Scala JS с этим лучше.

GHCJS был отброшен именно по той причине, что вы назвали — это тупо компилятор Haskell в JS, с поддержкой ленивости и всего-всего. Получаемый код выглядит ужасно, работает медленно, весит много, а про отладку даже думать страшно. Возможно, развитие WebAssembly когда-нибудь изменит это, но точно не в ближайшие годы.

У PureScript нет ни одной проблемы из приведенных выше. Более того, местами он выглядит более идиоматично, чем сам Haskell (поправлены некоторые нестыковки, которые в Haskell так просто не поправить из-за требований обратной совместимости). Работа с FFI и асинхронщиной — вообще сказка. Вызовы из JS — тоже, что важно, если у вас уже большой проект на JS и нужен постепенный переход. Большинство привычных подходов из других FP языков (Haskell, Scala) — просто работают. Очень интересно выглядит Halogen, но тут пока особо сказать нечего, надо еще испытывать на практике. Для более консервативных, есть неплохие биндинги к React, что тоже облегчает плавный переход, если он нужен. Есть прекрасная интеграция с WebPack, включающая оптимизацию сборки (выкидываются неиспользуемые функции и типы, что делает PureScript часть компактной).

Все это делает PureScript гораздо более production ready, при всем моем уважении к Elm и концепциям, которые были в нем изобретены.

Большое спасибо за это сравнение! Давно присматриваюсь к обоим языкам (Elm и PureScript), хочется попробовать что-то чистое функциональное на фронтенде. Но не мог определиться с выбором, вроде оба достаточно популярны в своих кругах, оба имеют сообщество. Сложно выбрать со стороны, не зная приведённых вами нюансов.

Особенности реализации сигналов в Purescript малоинтересны, поскольку в Elm 0.17 их выкинули за ненадобностью. А как на счёт реализации Elm Architecture в Purescript, она там есть? встроенная поддержка WebGL, чтобы компилятор мог распарсить текст шейдеров на GLSL и проверить согласованность используемых типов между шейдерами и основной программой?


О каких альтернативных подходах идёт речь и зачем их использовать?


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

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

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

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

То же самое касается прочих встроенных вещей, типа WebGL. На Haskell то же самое реализовали бы в виде DSL, в крайнем случае с использованием Template Haskell. Для PureScript аналога Template Haskell еще нет, но вполне можно использовать WebPack для кодегенерации.

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

Есть ли реализация текущей Elm Architecture для PureScript, я не знаю. Знаю что можно сделать, было бы кому-то надо. При этом в PureScript есть свои интересные вещи. Например, Halogen позволяет компонентам иметь локальное состояние и использовать эффекты, если надо. Это очень интересные возможности для наших проектов. Интересна ли нам Elm Architecture — не уверен, надо смотреть.

О каких альтернативных подходах идёт речь и зачем их использовать?

Например, в старом Elm использовались сигналы, теперь их заменили на что-то другое. Это вполне себе альтернативный подход с точки зрения старого. Зачем его используют? Наверное, потому что он лучше.

Есть и другие подходы, разумеется. Есть тот же React, Halogen, новые появятся. Какие-то окажутся лучше. Какие-то будут лучше для каких-то конкретных случаев. Вряд ли в Elm придумали идеал, лучше которого быть уже в принципе не может.
«язык слабее Хаскеля» — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.

Это очень наивно, полагать, что Haskell переусложнен ради самой сложности и что если от него отгрызть подмножество, то все станет лучше. Все его «сложности» появились постепенно, принося с собой весьма востребованные возможности. Если выкинуть все это и свести к этакому «functional basic», разумеется порог входа понизится, но и возможности пропадут.

Более того, использовать те возможности, что останутся, тоже станет сложнее. Ведь многие фишки языка появились как раз, чтобы упростить некоторые вещи. Никто не мешает взять PureScript или Haskell и просто не использовать то, выходит за пределы возможностей Elm. Но тогда придется либо оставаться в рамках более простых вещей, либо все станет только сложнее.

Да и язык не так уж сложен, сложно научиться его эффективно использовать — все эти монады, теория категорий, etc. Все это не часть самого языка, а то, что с его помощью можно делать. Можно все это отбросить, порог входа станет ниже, но делать что-то полезное станет сложнее.

Мне сложно привести конкретные примеры, где Elm ограничен в возможностях по сравнению с Haskell и PureScript, просто потому что последний раз я писал на нем очень давно и уже не помню, во что конкретно упирался. Навскидку, вот пример про Higher-kinded types. Либо можно посмотреть список расширений Haskell и прикинуть, чего из этого нет в Elm (скорее всего ничего). Вот тут можно почитать о них подробнее. PureScript включает некоторое подмножество этих расширений.
Правда, если вы никогда не писали на полновесном функциональном языке, то все это может выглядеть абстрактно и не очень понятно.
Прошелся по докам Elm, чтобы ответить конкретнее.
Оказывается, я забыл, насколько он игрушечный. В нем же вообще ничего толком нет.
Самый простой способ это увидеть — сравнить Elm Guide с PureScript by Example.
Из фундаментальных вещей нет Type Classes, newtype и еще много чего.
Из более прикладных STRef, Aff, operators, Generic, derive, etc.

Надо понимать, что многих вещей в Elm нет не потому, что так задумано, а потому что руки не дошли сделать, см., например, type system extensions.
С одной стороны, хорошо, что планы есть, но с другой — отставание от PureScript грандиозное.
Не уверен, что его вообще можно нагнать.

Кстати, тот факт, что в Elm до сих пор не работает нормально package manager и нет базовых элементов языка, зато втюхана поддержка GLSL, очень многое говорит о приоритетах авторов. Для кого-то, возможно, это хорошие новости, но очевидно не для всех.

Зря вы так пренебрежительно о PureScript отзываетесь :( В соседнем топике я уже писал об этом, но все же, PureScript — это самый прагматичный подход на данный момент. Если говорить по-честному, то экосистема у обоих языков пока недостаточно развита, чтобы целиком писать на них продакшен, поэтому сейчас очень важна простота взаимодействия с существующим js кодом (и тут Elm пока сильно проигрывает). Я попробовал оба варианта и заметил, что если у меня проблема с реализацией чего-то в PureScript я легко могу откатиться в старый добрый JS, но если у меня проблема с Elm, то как правило это значит, что я сильно влип. C PureScript я могу целиком использовать всю мощь экосистемы Node.js и знакомых инструментов, не говоря уж о том, что его можно легко использовать на сервере. Elm хороший язык, но подойдет только для специфических задач (шаг влево, шаг вправо — расстрел), PureScript более универсальный. И то, что это не молодой язык, а проверенный временем Haskell (почти), я считаю скорее плюсом. P.S: Не имею ничего против Elm, но мне грустно, когда хороший инструмент (PureScript) называют "поделкой". Elm получил внимание на волне популярности React/Redux и получил спонсорство от компании в которой работал Эван, а PureScript достиг всего только благодаря сообществу.

Несправедливо обделили вниманием Dart. Этот язык по линейке Git/Overflow обгоняет даже Rust.
Одно плохо. Он мертв по факту. А потуги Гугла запилить мобильную ОС с ним, очередные гвозди в его гроб и пустая трата времени.
Ну это гугл. Возьмут и закроют. Да и где этот дарт можно запустить кроме специальной сборки хрома?
А трансляция в js мне кажется сомнительным вариантом. Сначала решать проблемы в коде дарт, а потом в коде жс.
Вы описали надуманную проблему, а есть что-то более существенное, чем ваше мнение не основанное даже на опыте использования этого языка? У меня есть пара коммерческих проектов, которыми я занимался несколько лет назад, живы до сих пор, прекрасно работают. За всё время использования при компиляции в JS была проблема один единственный раз, да и то связано со сторонней библиотекой. Это ни в какое сравнение не идёт даже с разработкой Android приложений нативными средствами, когда проверка объекта на null даёт NPE. Я бы посоветовал ознакомиться с Dart, попробовать его своими руками и только после этого делать выводы.
Нет, опыта использования у меня нет. Я могу только экстраполировать свой опыт в других экосистемах на dart и также делать выводы из количества вакансий. Вакансий или 0, или предлагают опечатку в запросе исправить. То есть используется он в основном там где исполнителю хочется прокачать скилл изучая что-то новое, а заказчик не в курсе, что за его счёт качают скилл, или ему без разницы где он потом будет искать людей на поддержку.
Экстраполяцию надо делать аккуратно, вчера у меня не было жены, сегодня одна, а завтра будет две, так что ли? Про вакансии тоже надо внимательнее смотреть, часто они сопряжены с требованием знания JS, ибо на сегодня одно без другого никак. Хотя бы спросите Wrike зачем они используют Dart в своих проектах.
Вы делаете выводы исходя из ложных посылов.
Ну и хорошо, если будет находить применение.
когда проверка объекта на null даёт NPE

А можно подробнее? :)

        Intent intent = this.getIntent();
        if(intent!=null) {
            Bundle bundle = intent.getExtras();
            if(bundle != null)
            {
                Log.d("OK",bundle.toString());
            }
        }

Вот в этом коде у меня выскакивал NPE на 4ой строке. Возможно дело было в конкретной версии SDK, а может в каких-то моих действиях при передачи extras, потому как сейчас, чтобы не соврать, я перепроверил на свежем проекте и этой ошибки уже не получил.

Ну так у вас NPE упал внтутри getExtras очевидно, а не из-за того, что intent магическим образом стал наллом.

Ошибка вылетала именно на if'e, а не на getExtras. Специально проверял и удалял по одной строке. Очень был удивлён такой ошибке, почему о ней и упомянул.
Nim хорош, но до того чтобы попробовать на нем какой-то продакшен все никак руки не дойдут. Кто-то пробовал на нем писать больше чем пару хелловорлдов? :)

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


Что понравилось:


  • классы, объекты — всё это практически имеет нулевой оверхэд
  • сборка мусора работает довольно быстро
  • такой извращённой (в хорошем смысле) системы шаблонов и макросов я нигде не встречал
  • сборка через трансляцию в С, всегда можно его потюнить до производительности, сравнимой с C. К тому же можно распространять исходники в виде, оттранслированном в C — обфускация кода из коробки с неплохой переносимостью
  • хорош для разбора всевозможных xml/json и прочих разношёрстных конфигов с целью генерации отчётов
  • сравнительно безопасен, отстрелить ногу можно, но примерно с той же вероятностью, что и в питоне — по незнанию особенностей языка
  • легко подцепить функцию/библиотеку из C, если чего-то не хватает
  • очень легко собирается и самодостаточен, в плане переносимости лучшего варианта не сыскать
  • оптимизирующие шаблоны — отдельная песня. Можно целые куски кода, вроде "разделить строку по пробелам, взять подстроку длиной 10 символов от первого элемента" по мере необходимости переписывать на более оптимальные, с меньшей нагрузкой на сборщик мусора, при этом читаемость кода никак не пострадает. Эти шаблоны прячутся где-нибудь и ждут подходящего паттерна.

Что не понравилось:


  • баги — проклятье данного проекта. Их уже более 700, количество растёт, сообщество не успевает их фиксить.
  • удручающие решения в стандартной библиотеке. Ещё недавно чтение файлов работало посимвольно, через fgetc. Потоки (streams) — до сих пор небуферизованные, работают посимвольно и не спеша.
  • печальное состояние поддержки юникода и вообще какой-либо работы с языками, отличными от английского, отдельного упоминания достойна полная отсутствия поддержки переводов (по типу gettext)
  • биндинги к библиотекам сделаны на коленке любителями (см. GTK)
  • его пилит полтора человека, и ситуация не спешит меняться
  • регулярки прикручены наспех и работают медленнее, чем perl в десятки раз. Редкий язык, где реализация "в лоб" быстрее regexp.
  • отсутствует возможность использования рантайма, чтобы бинарники не пухли. Всё компилируется статически
  • сомнительная реализация исключений через longjump
  • из-за сборщика мусора нетривиально на нём разрабатывать библиотеки и модули к другим программам — требуется обязательное выполнение NimMain где-нибудь
  • коллеги смотрят на вас как на ненормального

Несмотря на недостатки, хороший язык "для себя" и можно на нём переписать что-то, что раньше было написано на Баше или Питоне, где нужна скорость. Продакшн даже не пробуйте — где вы потом программиста на Nim искать будете?:)


P.S. Подписываюсь на эссе по Nim от автора. Crystal пробовал — осталось впечатление, что он ещё более сырой, чем Nim.

А можете про макросы Nim подробнее рассказать? При беглом взгляде на документацию выглядит действительно извращенно (но не в хорошем смысле) по сравнению с макросами аля LISP. Просто обернуть код в макрос без вереницы newCall, newIdentNode, etc. никак нельзя?

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

Да это понятно, просто в доке Nim эти манипуляции выглядят как-то излишне многословными.

В большинстве случаев можно и без макросов обойтись, вот например шаблон, который ведёт себя также как и функция print в Питоне:


template print*(x: varargs[string, `$`], file: File = stdout) =
  var res = ""
  for i in x:
    addSep(res, " ")
    if i != nil:
      res.add(i)
    else:
      res.add("(nil)")
  file.writeLine(res)

или withFile, который сам закрывает дескриптор после выхода из блока:


template withFile*(filename, body) {.immediate, dirty.} =
  block:
    var outfile: File
    template put(x: varargs[string, `$`]) = 
      outfile.writeLine(x)
    if open(outfile, filename, fmWrite):
      defer: close(outfile)
      body
    else:
      raise newException(OSError, "cannot open: " & filename)

В результате Nim становится не намного многословнее баша.

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

Странно, что при нормальном ffi не взяли просто pcre, который по функциональности более-менее on par с perl'ом и по скорости очень даже ничего.

А они и взяли pcre, но я никогда ещё такого медленного pcre не видел:


# 4.5 sec
import re
let exp = re"agggtaaa|tttaccct"
var c = 0
for line in "in.txt".lines:
  if line.find(exp) != -1:
    c += 1
echo (c)

# 2 sec
import pegs
let exp = peg"'agggtaaa'/'tttaccct'"
var c = 0
for line in "in.txt".lines:
  if line.find(exp) != -1:
    c += 1
echo (c)

# 0.2 sec
grep -cE 'agggtaaa|tttaccct' in.txt
# 0.4 sec
grep -cP 'agggtaaa|tttaccct' in.txt
А мне кажется, что сама по себе линия — не очень удачный фактор. Я б искал языки, которые имеют значительный перевес ГитХаба в сравнении с СО — ибо в них меньше ВТФ или лучше литература и при высокой популярности. Например, D. Проектов значительно больше, чем в Расте или Еликсире, а вопросов по нему меньше или равно. Видимо, хороший язык.
Понимаете, D уже сложно назвать молодым и перспективным… Всё-таки языки, которым больше 10 лет, уже заняли свои ниши и вероятность их бурного роста или падения не высока. Должен быть какой-то мощный фактор.
Для примера, появление Rails было фактором роста для Ruby (которому на тот момент было около 10 лет). С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.) потеряли рынок, потому что их пытались продолжать продавать.
Каков же фактор для D, которому 15 лет в этом году исполнилось?
С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.)

Продавали не язык, а IDE (Delphi). Да и какая альтернатива Delphi? MCVC? Но он платный. :)
Также, как сейчас под бесплатный PHP продают PHPStorm и PHPEd, ибо бесплатные ИДЕ унылые.
Точнее сказать продавали комплектом. Бесплатно скачать компилятор и стандартную библиотеку(VCL) возможности не было, насколько я помню. Для того же C++ такая возможность была.
UFO just landed and posted this here
Там надо цифры в столбце слева смотреть:
5146 репозиториев и 1935 пользователей у Rust, и 5031 / 2491 — у D.
Для истории выпишу данные с Github по всем языкам из статьи:
Elm — 433 / 194
Rust — 5146 / 1935
Kotlin — 960 / 1541
Crystal — 150 / 52
Elixir — 2668 / 861

Через годик посмотрим динамику.
Теперь взгляните, как четыре из этих пяти языков карабкаются по лестнице популярности (на основе данных StackOverflow и GitHub):

Рядом карабкаются Ada,Pascal и Smalltalk.
Я бы назвал другие, не 5 конечно но хотя бы 3: Go, TypeScript, Swift.
Первое что приходит на ум. Первые 2 потому что в продакшене спасают, третий… Ну вы сами понимаете.
UFO just landed and posted this here
Ага, тем более, что Go и Swift в статье упомянуты, как перспективные для перехода уже в первый, а не во второй эшелон.
Рядом карабкаются Ada, Pascal и Smalltalk.
И что с того? Языки, которым больше 10 лет, уже заняли свои ниши и особо никуда не двигаются. Ada и Pascal очень медленно сползают вниз, а Smalltalk начал шевелиться с появлением Pharo, но тоже с туманными пока перспективами, т.к. момент был упущен лет 15 назад.
Язык программирования — это инструмент. Как сварочный аппарат, например. Если все в основном, скрепляют детали на сварку, то зачем вам осваивать использование заклёпок? Со сваркой вы всегда найдете работу. Да, на заклепки тоже есть пару мест в стране — это производство военных самолетов, но стоит ли оно того? Платят столько же, зато если сократят, то останетесь совсем без работы.
Некоторые говорят, что за заклепками будущее. Но я им не верю. Мне кажется, рынок труда очень неплохо расставляет все по своим местам.
А с будущим на самом деле особо не угадаешь. Другой вопрос, что обычно тенденции прослеживаются сильно заранее, давая время на изучение «заклепок», не бросая любимую «сварку».
Впрочем рынок труда может резко перестроиться и расставить все по «своим» местам совершенно другим образом.
Правда для таких резких перестроек нужен серьезный технологический прорыв, но в истории они уже случались. Единственное, что пока радует, в области программирования не бьло резкого умирания какого-либо языка. А вот резкий рост практически с нуля случался. Например, после появления первых языков высокого уровня резко потребовалось большое колличество специалистов для этих языков, в то время как потребность в знании ассемблера затухала достаточно медленно (ассемблер сам по себе использовался в разработке программ под процессоры 80386, а может быть, что и существенно позже).
Вот именно, что не было резкого умирания какого-либо языка. Обычно происходит плавное угасание интереса работодателя — новые проекты делают на чем-то новом, старые продолжают поддерживать. И есть время перейти на новый язык — несколько лет минимум, пока работы совсем не останется.
Поставьте себя на место работодателя. Почему новый проект нужно делать на технологии Х? На рынке больше всего опытных специалистов, умеющих с ней работать. При этом они дешевле. Если кого-то нужно уволить, то легко можно найти замену без ущерба для бизнеса.
Так можно сказать про C#, Java. Но не про Elm или Rust.
Если вы решили стать специалистом в том же Rust, подумайте, наняли бы вы себе программистов на ваш личный новый проект на нем?
Вас послушать, так до сих пор все программировали бы исключительно на Fortran, Lisp и Algol, ну и изредка на Smalltalk, Simula и Forth.
Но почему то из этих шести на плаву только Lisp и Smalltalk, и то работу на них найти ещё сложнее, чем на Elm или Rust.
Ну и в целом, работа — это же не главная мотивация в программировании, что-то можно изучать из любви к искусству, а не только в корыстных интересах ;-)
Все очень просто. Есть кривая, которая показывает вовлечение целевой аудитории в какое-либо дело.

Так вот там на новаторов и ранних последователей приходится всего 15% от всей потенциальной аудитории. Причем на новаторов всего 2,5 %. Это означает, что только 2,5 из 100 программистов будет интересно учить что-то новое и «неизвестное».

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

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

Есть кривая, которая показывает вовлечение целевой аудитории в какое-либо дело.
Верно. Этот вопрос освещён в книге «Профессиональная разработка программного обеспечения» Макконнелла.

Причем на новаторов всего 2,5 %. Это означает, что только 2,5 из 100 программистов будет интересно учить что-то новое и «неизвестное».
А вот это уже не совсем верно. Новых технологий много, допустим, на 1 устоявшуюся приходится 10 новых, и вот уже получается, что 25 из 100 программистов интересно учить что-то новое.

Поэтому сейчас у человека выбор учить непонятную хрень, которая то ли будет работать, то ли нет. Либо можно выучить c#, который уже даст тебе работу.
Про это сказано в начале статьи… Если есть проблема с работой, то лучше бы выучить что-то из мейнстрим языков. Но для опытных программистов это уже неинтересно… Ну сколько лет можно учить C#? Там со времён C# 3.0 изменения весьма минорны, даже странно, что мажорную версию языка поднимают постоянно.

И фактически все усилия будут напрасны.
Если Вам это через силу, то не надо конечно. Учить что-то новое надо в удовольствие, потому что интересно, потому что обогащает опыт, расширяет кругозор, а не для того, чтобы в резюме больше строчек было.
Если новаторов всего 2.5%, то они между собой разберут эти 10 новых технологий. Остальные 97.5% не парятся.

Учить можно не C#, а например, весь .Net фрейворк + веб фреймворки. Я не спец, но кажется, он весьма обширен.

А если очень хочется поучить непонятную ненужную хрень, то зачем ограничивать себя программированием?
Изучите испанский, готовку, ковку, сварку, параплан… Банальный C# вас накормит, зато в старости будет что вспомнить.
Учить можно не C#, а например, весь .Net фрейворк + веб фреймворки. Я не спец, но кажется, он весьма обширен.
Вы уж определитесь, либо всё, что не нужно на текущем месте работы для текущих задач, — это непонятная ненужная хрень, либо можно не ограничивать себя одним языком/платформой.

А если очень хочется поучить непонятную ненужную хрень, то зачем ограничивать себя программированием?
А я разве писал, что нужно ограничивать себя программированием?
Ну и если Вам лично что-то непонятно или не нужно, то это не значит, что это хрень. Кстати, исторический факт: люди, подобные Вам, лет 10-12 назад носились с криками, что .NET — это никому ненужная хрень xD
Поскольку я начинал активно разрабатывать примерно в то время, когда многие кричали, что ".NET — это никому ненужная хрень", я хочу уточнить. Эти споры относились на 90% к разработке десктоп приложений, а не WEB. И при всем моем искреннем уважении к C# и .NET аргументы против .NET имели место. По моим наблюдениям сейчас для GUI приложений лучше использовать, например, Qt. Это и кроссплатформенно и быстро и красиво. Использовать WPF для десктопных приложений сейчас решаются не многие.
Эти споры относились на 90% к разработке десктоп приложений, а не WEB.

Ахах, это да, на тему того, что ASP.NET — неюзабельная хрень, практически все были единодушно согласны. Но спустя годы сделали порт Rails, назвали ASP.NET MVC и ничего, стало можно и под веб на C# комфортно разработку вести. Так что это ещё и исторический пример того, как реальная хрень может быть замещена чем-то путным в рамках одной и той же платформы.


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

А, кстати, почему? Боятся ограничить себя рамками Windows?
Я как-то давно отошёл от разработки десктопных приложений, поэтому не в курсе. Вообще Qt с .NET — это интересное сочетание, почему тогда не GTK или wxWidgets?

Там со времён C# 3.0 изменения весьма минорны, даже странно, что мажорную версию языка поднимают постоянно.

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


А чем dynamic и async/await не новая концепция? И какие тогда по вашему изменения тянут на изменение мажорной версии?

Понимаете, если программировать только на C#, то это всё может выглядеть круто. Но по факту это просто заимствование идей из других языков. C#, начиная с 3-й версии, начал путь в функциональщину. Это классно, но совсем не ново.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.

После шестой версии, например, C# 5 воспринимается многословным и неудобным.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.

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

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

Особенно при набирающих популярность микросервисах.
> Также Elixir достигает прироста производительности при помощи Erlang VM
Также? Прироста?

> с использованием либо Cowboy (низкоуровневый HTTP-сервер), либо Phoenix
Бутерброд достигает вкуса с использованием либо масла, либо хлеба.

Минимальное знакомство с предметом перестало быть необходимым для написания т. н. статеек на хабр?

Это перевод. Непрофессиональный.

Хоть формулировки у Кристиана Нельсона и странные местами, я не вижу в них чего-то криминального и показывающего, что он не знаком с предметом.
Прирост производительности очевидно имеется в виду по сравнению с Ruby :-)
То, что Phoenix работает поверх Cowboy — это факт, но это совсем другой уровень абстракции.
Если завтра выйдет версия Phoenix, работающая поверх другого веб-сервера, Вы очень долго не заметите что что-то поменялось.
Поправил формулировки на более точные по смыслу. А вообще для этого ЛС есть ;-)
И да, и нет. В куске про отличия эликсира единственный внятный и грамотный пункт, отличающий именно эликсир — «добавлен переводчиком» :). Весь остальной кусок — каша из «где-то слышал про эрланг» и «Валим из пятерки руби-коммитеров».

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

С отличиями всегда есть вопрос: относительно чего? По сравнению с Erlang основная отличительная особенность Elixir — это макросы, даже синтаксис и сокращение boilerplate-кода — это всё следствия. А если говорить об отличиях среди всей массы языков программирования, то они на 90% cовпадут с отличительными особенностями Erlang и это естественно.
Я просто не очень понимаю, с чем конкретно Вы не согласны в этом куске?
С тем, что ErlangVM — не язык, и приписывать преимущества виртуальной машины тридцатилетнего возраста эликсиру — довольно странно.

Макросы эликсира — это гениальный гигантский прыжок вперед по сравнению со всеми остальными «новшествами» остальных сравниваемых языков (для тех, кто не RMS и хочет, чтобы язык был не write-only, а LISP, к сожалению, очень быстро им становится на заметных объемах). Я всегда привожу в пример имплементацию строк и регулярок: они из коробки поддерживают актуальный UTF-8, потому что эликсир парсит спецификацию консорциума на стадии компиляции.

Все остальное — либо преимущества ВМ эрланга (которые неоспоримы: 15 девяток и т. д.), либо не очень понятные кивки в сторону синтаксиса, который близок и понятен рубистам, но традиционно недолюбливается питонистами, например.

С тем, что ErlangVM — не язык, и приписывать преимущества виртуальной машины тридцатилетнего возраста эликсиру — довольно странно.

Разумеется, преимущества BEAM — это не заслуга Elixir, но ведь он позволяет ими пользоваться. А таких языков не так уж и много, я осведомлён только об Erlang, Elixir и LFE. Вот и получается, что отличительными особенностями этих 3 языков являются преимущества BEAM :-)


Это из той же серии, что отличительные черты Kotlin — это преимущества JVM и возможность использовать Java-библиотеки. У Rust и Crystal — возможность легко подключать сишные либы. А у Elm — встраиваться в существующие JS-проекты.


И это понятно, никому сейчас не нужен язык-бука, который тупо проигнорит текущее состояние отрасли и будет делать абсолютно всё с нуля. Сложность заключается в выборе наиболее крутых достижений прошлого, их гармоничном комбинировании и дальнейшем развитии. Elixir в этом плане сделал ставку на возможности BEAM, интероперабельность с Erlang, макросы LISP и синтаксис Ruby. На мой взгляд, первые 2 пункта выполнены на отлично. Остальные 2 взяты за ориентир, но видимо не являлись самоцелью. Поэтому синтаксис только отдалённо похож на Ruby, а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.

а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.

Очень напомнило скорее Scheme, чем CL, в частности наличием hygienic macros. Но с elixir не знаком и не возьмусь судить о мощности их реализации макросов, например, в сравнении с Scheme или Rust. Будет прекрасно, если проведёте сравнение с Scheme или CL.


Макросы в Rust базируются на тех же принципах (и той же работе Macro-by-Example — Kohlbecker, Wand // 1986), что и в Scheme.

Я Scheme тоже отношу к LISP-семейству, как и все остальные диалекты.
Я немного знаком с CL и мне кажется очень похоже в плане макросов с Elixir. Да, в CL для гигиеничности нужно использовать gensym, а в Elixir для нарушения гигиеничности var!.. Т.е. в этом плане поведение по умолчанию отличается, но в остальном… те же quote(`), unquote(,), unquote_splicing(@,), те же манипуляции с AST при необходимости.
Со Scheme я не настолько знаком, чтобы всерьёз о нём рассуждать, но Racket, на мой взгляд, выглядит очень круто.

Что касается границ гибкости макросов Elixir, они пролегают по территории довольно редкой для практического применения, например, Вы не можете расширять синтаксис языка произвольным образом, т.к. разрешенный набор небуквенных символов ограничен. Если хотите принципиально кастомный синтаксис, то придётся оборачивать весь код, который будет его использовать, в один вызов макроса, внутри которого можно будет преобразовывать AST как угодно. Но это, в принципе, не велика проблема, т.к. для таких преобразований есть очень удобные средства типа Macro.prewalk/3.
А вот единственным принципиальным ограничением, в которое я однажды упёрся, было то, что в общем случае невозможно внутрь quote подставить кусочек сырого AST (кому интересно, могу в личку скинуть подробное описание этого случая). Это вытекает из двойственного представления кода, тогда как в LISP кроме AST другой записи кода нет. Но это реально очень экзотические случаи.

P.S. Вообще тема интересная, надо Rust и Racket поглубже копнуть )
завтра выйдет версия Phoenix, работающая поверх другого веб-сервера

Вероятность этого события стремится к нулю.


  • cowboy это фактически единственный живой веб-сервер для erlang.
  • Plug так интересно задизайнен, что у них нет ни своей реализации websockets, ни даже API для protocol upgrade. plug-websocket использует cowboy напрямую, как работает Phoenix.Transports.WebSocket я навскидку не могу разобраться.
  • адаптер для более-менее живого elli висит в PR уже 2.5 года и тоже никому не интересен.
Очень не хватает инфы про поддержку этих языков в популярных IDE.
Несколько лет назад брался за изучения питона и был поражён различиями в удобстве работы в разных IDE по сравнению даже с php. На тот момент самой умной (на взгляд новичка) оказалась eclipse, значительно обойдя даже pycharm. Это для python, что уж говорить про «новичков»…
Для Kotlin, Elixir, Elm и Rust есть плагины под IntelliJ IDEA, которые работают в том числе и с бесплатной Community Edition.
Также есть плагины под популярные редакторы: Sublime, Atom, VS Code. Ну и само собой под Emacs и Vim. Это уже и к Crystal относится, вот по нему инфа.

Плагин для Elixir бесполезен чуть менее, чем полностью. Pure Elixir проектов не бывает, а сосуществовать с erlang-плагином нормально elixir-плагин не умеет толком.

Pure Elixir проектов не бывает

С чего бы это? У меня уже 3-й такой.

Elm уникален и определённо имеет шанс взлететь, поскольку ориентирован на самую востребованную платформу, и предстовляет собой очень простой язык без хаскелизмов. Он собственно уже частично взлетел, так как React и Redux — это не что иное как кривой порт Elm для js

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

Что вы подразумеваете под "веб"? Программы, связывающие передачу данных через http в браузер и базу данных? Мне кажется на сегодняшний день веб это что-то большее. И поэтому MVC уже не "наше всё". И для веба нужны чуть более гибкие инструменты чем %мой_любимый_веб_фреймворк%.

Ваша мысль ушла не туда. Я про то, что


В настоящее время Elixir в основном используется для создания веб-приложений с использованием как Cowboy (низкоуровневый HTTP-сервер), так и Phoenix (полнофункциональный фреймворк для разработки веб-приложений). Кроме того, Elixir пробивается в нишу встраиваемых систем благодаря фреймворку Nerves.

Так вот это полная ерунда в сравнении со сферой применении Erlang, на котором написан софт, обрабатывающий 50% всего сотового трафика.

Это не 5 «перспективных», это 5 «интересных» языков программирования. Из них перспективные только Kotlin из-за «совместимости» с Java. Остальные Ок для поиграться и завести пару реп на гитхабе для толерантности к другим языкам. Писатели статей иногда забываются, и считают IT автономной и независимой областью, но это совсем не так. Не будет заказчика — не будет IT. А заказчику решение нужно вчера, а не «давайте перепишем на Elixir, он такой ня!».
Именно по этой причине перспективными являются kotlin, go и swift — так как за ними стоит «большой» заказчик, который обеспечивает языку задачи и ресурсы для их выполнения.

Другие языки — это дело случая и некоторой удачи. Например, захочет какая-то большая компания сделать что-то грандиозное и выделит ресурсы, то дело пойдет, а нет. Так все будет в полудохлом состоянии.
Именно по этой причине перспективными являются kotlin, go и swift — так как за ними стоит «большой» заказчик, который обеспечивает языку задачи и ресурсы для их выполнения.
По-моему только Swift может похвастаться заботливым отношением от большой компании. Google не особо запаривается поддержкой своих языков. Ну а JetBrains наверняка будет приятно, что Вы их в один ряд с Google и Apple поставили.
Интересно вы JetBrains считаете большой компанией, а Mozilla'у нет?
Я не могу сказать про все языки, но Crystal и Elixir появились именно потому, что в этом есть потребность у крупных проектов на Ruby. После чего и создатели Ruby активнее зашевелились в сторону производительности. Но, как мы знаем, обещанного 3 года ждут, а нагрузку надо держать уже сегодня и в этом Elixir отлично помогает. А кому-то возможно и Crystal уже помогает.
Ну CoffeeScript тоже когда-то «потребность у крупных проектов на Ruby», а потом хипстерам надоело и где он теперь?) Не такой уж и нужен.

CoffeeScript, точнее большинство его фич, уже в ES6.

Ну разве что stage0 =) Да и угас хайп на него уже несколько лет как, до того как ES6 вошел в мейнстрим с популяризацией Бабеля.

Могли и дальше добавлять сахар. Там ведь не только классы и стрелко-функции были, а синтаксис из питона, синоним @ для this, убран var, несколько синонимов для boolean значений, много важных вещей, короче.

Так что мне кажется, что им просто надоело, а не в JS6 дело.

Хайп сбило решение не включать его в Rails по умолчанию. Впрочем, CoffeeScript в любом случае сыграл весомую роль в популяризации идеи транспиляции в JS. Сейчас уже этих транспилеров столько, что всех и не упомнишь…

А где C, почему он ни в первом, ни во втором эшелоне? :)

Первый и второй эшелон представлены в формате «X, Y, Z и т.д.». Целиком их выписывать не вижу смысла… Тем более, что вчера уже была статья про Top-15.
Почему не включили Swift в первый эшелон? На нем уже можно писать server-side + есть компиляция под linux и android.
Вы начало статьи прочитали? Swift уже в одной ногой в мейнстриме, а статья про языки, которые ещё только набирают обороты.
Rust тоже выбивается на фоне остальных в таком случае. У него отрыв поплуряности сильно больше всех представленных.
В комментах выше считали кол-во репозиториев на Github, у Rust — чуть больше 5 тыс.
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
Можно не значит, что это кто-то делает. Swift в ближайшее время не выберется за пределы Apple. Хотя даже с учетом одной iOS его можно в мейнстрим вписать, все равно как-то по мне не очень он тянет, будучи все еще замкнутым в экосистеме Apple. Как и с Obj-C было. Он вроде популярен из-за айфонов, но всерьез его все равно не рассматривают в таких рейтингах.
Obj-C слишком зависел от Foundation, именно поэтому он не вышел за пределы iOS. У Swift таких проблем нет.
UFO just landed and posted this here

Про vs java у них написано хорошо на сайте (да тот же nullsafe). По своему (небольшому) опыту vs scala:


  • ниже порог вхождения
  • меньше стандартная библиотека (по максимум используется стандартная библиотека java). Когда я пытался добавлять к проекту на java scala код, то везде сталкивался с тем что приходилось шаманить с типами данных (не сложно, но надоедает — как пример http://stackoverflow.com/questions/6356465/how-to-get-scala-list-from-java-list). В kotlin по идее такого нет
Новое например то, что с первой версии у него отличная поддержка IDE, для Scala IDE до сих пор тормозит.
Новое то, что много его абстракций «бесплатные» в рантайме: null типы, немутабльные коллекции, экстеншен функции, лямбды.
Котлин достиг скорости сборки такой же как у Java (реверанс в сторону Scala)
Для андроида у Котлина есть подаркок: малое количество методов в std, маленький вес std и Anko.

При полном интеропе с Java язык быстро развивается.

Наконец-то разработчики получили замену Java, а не скриптовый язык (Groovy) или вообще фп (Clojure, Frege, Scala).
UFO just landed and posted this here
Эм, вы не сходили в доку и хотите чтобы я вам перечислил фичи языка которыe могли бы сами почитать по содержанию в доке? http://kotlinlang.org/docs/reference/

А в Котлин 1.1 еще вот это всё: https://blog.jetbrains.com/kotlin/2016/07/first-glimpse-of-kotlin-1-1-coroutines-type-aliases-and-more/

А Java 8 всё еще далек от современного языка, Котлин на голову выше, но всё еще прост и понятен любому Java разработчику.
А Java 8 всё еще далек от современного языка, Котлин на голову выше, но всё еще прост и понятен любому Java разработчику

Я дико извиняюсь и не хочу показаться излишне консервативным, но все-таки, а что делает язык современным и чего такого нет в Java?)
Новое то, что много его абстракций «бесплатные» в рантайме: null типы, немутабльные коллекции, экстеншен функции, лямбды.

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


  • Non-null генерируют проверки на null, которых в аналогичном java-коде может не быть вполне осознанно.
  • Read-only коллекции (я б не стал называть их immutable, т. к. это несколько иное) — просто сахар над конструкторами (+ может быть, реализации в стандартной библиотеке).
  • Вызовы extension methods (как и implicit classes в Scala) порождали объекты, хотя, возможно, они теперь делают инлайнинг, который тоже далеко не всегда полезен (с т. з. JIT'а).
Non-null не генерируют такие проверки повсеместно, а только когда идет интероп с Java кодом. На чистом Котлине их практически нету.

Read-only коллекции (справедливо) — это не сахар, это просто интерфейс, а реализация подкладывается JDK. Сейчас готовят именно immutable реализацию коллекций.

Вызовы extension методы не порождают обектов, это просто статические методы. Инлайн может сделать джит в этом случае.

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

UFO just landed and posted this here
Подскажите же, покажите же! Кто же эта темная лошадка в мире JVM для которой всё это не новое?
UFO just landed and posted this here
Kotlin — практичный язык для тех, кто привык с Java, но смог осознать ее недостатки.
Но что в нем «emergin»?

Остальные языки под этот эпитет подходят, хотя и не единственные в своей нише. Например Crystal конкурирует с Nim.
Не хочу огорчать автора и переводчика, но язык в принципе не может быть перспективным, если о нём большинство аудитории слышит В ПЕРВЫЙ РАЗ.
Кроме того, следует сразу диагностировать «функциональщину головного мозга», прежде чем строить предположения. ФП — оно так же забавно и интересно, как и логическое п-е, но с практической точки зрения — это айтсайдер мэйнстрима. Как только описание языка начинается с фразы «это фун-ый язык п-я», можете сразу листать дальше — этот бред никогда не будет популярным.

С практической точки зрения, имеет смысл очень небольшой круг языков: прежде всего, это D как первоклассный преемник С++. Библиотеки — дело наживное, главное — у Ди великолепная, вылизанная база — писать на нём не просто удобно — ПРИЯТНО! Далее я бы поставил Nemerle, но ему нужно слегка отполировать синтаксис — не везде он удобен/очевиден. Зато не нужно писать библиотеки — весь .NET сразу в кармане. Конечно же, C# — через пень-колоду, но всё же развиваемый под крики и мольбы чайников :) В стане JVM, безусловно, Kotlin. Ну и всякие некритичные порносайтеги — я бы заюзал там Ruby, интересный язык и удобный для динамических приколов.
А вот и всё! Остальные языки как-то там движутся, но желания их касаться не вызывают. Особенно последние выскочки типа Go/Rust'ов.
язык в принципе не может быть перспективным, если о нём большинство аудитории слышит В ПЕРВЫЙ РАЗ.

прежде всего, это D как первоклассный преемник С++

Далее я бы поставил Nemerle

По вашей же логике, D и Nemerle не перспективны.

последние выскочки типа Go/Rust'ов.

По вашей же логике, они перспективны, потому что уже многие годы на слуху.
Если человек не слышал про Ди (зная про С++), обычно говорят «вон из профессии!». Но отдельный опрос не помешал бы — чисто поржать на местных «специалистов».
Nemerle — тут сложнее, тут надо вращаться в .NET, но дотнет — это как раз мэйнстрим и не услышать про Немерле — тоже как бы не красит программиста. Другими словами, язык может быть редкий/непопулярный, но в конкретной области про него обязательно должны были услышать. В моей (дотнет) ни про какие Эликсиры и Эльмы даже речи не шло — не представляю, о какой «перспективности» у них может идти речь. Даже у Смоллтока больше шансов!

Го/Раст — о них много трубят (спасибо гугле), но по сути это не игроки. Если вам техническое чутьё ничего не говорит, увы — убедить не смогу.

В любом случае, не понимаю ваш выпад — вы коммент зачем писали? Вы хотите меня убедить, что Эликсир и Эльм — что-то перспективное? Мне нужна ваша точка зрения, а не цепляние к словам.
Моя точка зрения — вы либо уныло вбрасываете, либо пишете ахинею на полном серьезе. Вот мое мнение. Хотя это даже не мнение, а больше фактическая характеристика. Опровергать каждый ваш тезис, который не имеет ничего общего с реальностью, у меня нет желания. Выбирайте, что вам больше подходит.
Родной, мне не надо ничего выбирать, я уже давно для себя выбрал. Кому непонятны мои комменты, может СМЕЛО проходить МИМО — не для всех умов постижимо то, что вырабатывается годами.

Хоть и знаю, что ты тролль, но всё-таки смешно выглядят рассуждения из первого абзаца вместе с упоминанием Nemerle. Язык-то интересный, но боюсь, что в среднем о нём слышало меньше народу, чем о (практически) любом языке из этой статьи. И ещё смешнее то, что и Nemerle и D и Kotlin, о которых ты столь положительно отзываешься, не гнушаются "функциональщины".

> с практической точки зрения — это айтсайдер мэйнстрима
Вы в телеком и вотсап напишите, а то пацаны мучаются и не в курсе, что они в аутсайдерах.

Вы из какого года к нам прибыли? Я про Nemerle в прошлый раз слышал лет 8 назад. Влад и компания, конечно, молодцы и тогда этот проект выглядел весьма интересно. Но, имхо, после выхода C# 3.0 и включения F# в дефолтную поставку VS 2008 интерес к Nemerle стал стремительно затухать.
Про D я уже выше спрашивал, какой фактор сможет обеспечить рост популярности 15-летнему языку?

Узнаю любимый рунет — быдлятник в байтах. Из какого я могу быть года, если знаю про Ди и Немерле? В отличии от хабровской шпаны, я в ИТ более 20 лет, уж наверное знаю побольше похапастов с апломбом вроде вас.

Даже после выхода C# 7.0 Nemerle останется в фаворитах, ибо до его фич шарпу пилить и пилить. Но т.к. вы этого не знаете, похоже и дискутировать нет смысла — вышел, пукнул, слился. Зачем оно вам?

Ди — перспективен, причём тут какие-то 15 лет? Язык устоялся буквально год-два назад. Сейчас пилятся либы. И по фичам Ди затыкает С++ туда, куда только клизму вставляют.

То, что Вы об их существовании знаете, в этом ничего удивительного нет. А вот то, что Вы пропустили момент, когда о них говорили, как о перспективных (это было лет 8-10 назад) — это странно.


Язык устоялся буквально год-два назад.

Во, теперь понятно… привет из 2009 года.


быдлятник в байтах.

Это Вы видимо про себя. На вопросы по существу отвечать научитесь, потом понтоваться будете.

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

О Nemerle впервые узнал под этой статьёй в комментариях, это при том, что о своём первом языке программирования я стал узнавать 12 лет назад это был С++. О Nemerle не говорят, он не на слуху. Этот язык может быть одной сплошной фичей, но если он не решает те проблемы, которые возникают у разработчиков, то он не нужен. Мне, как Unity3D разработчику, совсем не понятно, какую из моих задач Nemerle может решить лучше, чем C#.

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

Справедливости ради, чтобы 1 неадекват не создавал негативное мнение о языке в целом, скажу, что Nemerle — весьма интересный язык с хорошим выводом типов, с полноценным pattern matching, макросами аля LISP и ещё кучей полезных фич. В общем по идеологии он гораздо ближе к функциональному программированию, но при этом синтаксис напоминает C#. Этакий гибрид C# и F# + нормальные макросы.


К сожалению, язык этот за 10 лет существования не взлетел, потому что
1) Пиар за пределами RSDN у него был практически на нуле
2) Для многих программистов хватило функциональных возможностей, которые встроили в C#. Ну а для тех, кому хотелось больше функциональщины под .NET, взлетел F#
Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.


P.S. На самом деле, даже странно почему популярность Nemerle настолько близка к нулю… Я ожидал, что ситуация получше. Но не видно ни одного активного OpenSource-проекта на этом языке, если не считать проектов того самого Влада.

Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.

Касательно того, где кто работает не в курсе, знаю только, что какое-то время работы велись за счёт JetBrains, а сейчас оно снова перешло в разряд "хобби проекта". Если кому интересны подробности, то они есть вот тут. Да и в JetBrains они больше занимались Nitra — этакий конструктор языков/DSL. Насколько знаю, были планы сделать N2 на нитре.

Хм, значит всё-таки не будет… Единственный шанс — убедить MS в том, что им могут быть полезны эти наработки.

У MS и так уже VC++, C#, VB.NET, TypeScript. Зачем им еще 1 язык тянуть? К тому же к Nemerle будет сложно в разумные сроки прикрутить поддержу IDE, чтобы он смог хоть как-то соперничать с C#+VS+R#. А скоро еще и Rider появится, который будет быстрее, удобнее, красивее и… ну вы поняли. Так что скорее всего без поддержки JetBrains Nemerle не выжить в dotNet-среде. А у них уже есть R# и Rider(ну почти есть). А так как целевая аудитория Nemerle — это те же C# программисты, то получается JetBrains нужно будет делать еще 1 IDE, чтобы она конкурировала с другими своими продуктами? Согласистесь это было бы странно для компании, которая зарабатывает деньги на разработке IDE.

В общем, пациент скорее мертв, чем жив. Хотя, конечно печально, что ситуация стала такой. Язык достаточно итресный и мог бы сильно упростить/ускорить разработку больших продуктов, но без IDE…

Собственно, одна из фич нитры — это интеграция с IDE из коробки. Хотя мне тоже кажется, что момент упущен и уже не взлетит.

К тому же к Nemerle будет сложно в разумные сроки прикрутить поддержу IDE

Интеграция с VisualStudio у Nemerle вполне приличная ещё со времён VS 2008. Так что проблема явно не в этом.


Вообще .NET CLR — весьма авторитарная среда, по сравнению с тем же JVM. Я не знаю ни одного языка, который бы взлетел для неё кроме тех, чью разработку активно курирует Microsoft. Даже из тех разработок, которые они поддерживали, типа IronPython, IronRuby и прочие Iron*, ни одна не взлетела.

некоторые из ведущих языков возможно увядают

Я бы не стал слишком доверять статье, которая в основу своего анализа берет статистику продаж книг по разным языкам всего лишь одного из (пусть и весьма известных) книжных издательств.
В данном случае корреляция ничтожна.
Вышла новая версия языка — выпустили новую книгу — все ломанулись покупать — ура, язык то крут!
Нет новых версий, все стабильно — книг не выпускают, не покупают — все, язык загибается!
Изучение языка простое и не требует спец литературы (ну или просто создатели постарались, и выложили крутую документацию, которая заменяет большую часть книг) — почитал в онлайне и вперед, фигачить в продакшен — все, продаж книг нет, язык загибается!
Ну и например, некоторые разработчики языков/платформ имеют свои издания, что знает О'Рейли об их популярности?
Очень странно видеть Golang и Swift в компании Haskell и Clojure.
Особенно учитывая, что, по мнению автора оригинальной статьи, это языки «второго эшелона» (Swift, ага).

Интересно, куда бы автор отнес Haxe — к полудохлой маргинальщине, мейнстриму, «второму эшелону» или «перспективным языкам» (как по мне, так это та же маргинальщина).
Я бы перспективным назвал Clojurescript. Я пробовал многие разные языки транспилирующие в JS, настоящее удовольствие я стал получать от работы именно с него.
Sign up to leave a comment.

Articles