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

Original author: Mitch Pronschinske
  • Translation

КДПВ


Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.


Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.


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


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



Перспективные языки: почему эти пять?


Пять языков программирования, о которых пойдёт речь, весьма новы (не исключено, что о каком-то вы услышите впервые), и они явно имеют отличные шансы пробиться во второй эшелон в ближайшие 2-3 года. Может быть, когда-нибудь один из этих языков сможет потеснить и языки первого эшелона.


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


Elm набирает популярность в сообществе JavaScript, в первую очередь среди тех, кто предпочитает функциональное программирование, которое находится на подъеме. Как и TypeScript или Dart, Elm транспилируется в JavaScript.


Rust является языком системного программирования, предназначенным в основном для ниш, где применяют С и С++. Поэтому удивительно видеть, что популярность этого языка быстрее растёт среди веб-разработчиков. Этот факт становится более осмысленным, когда вы выясняете, что язык был создан в Mozilla, которая хотела дать лучший вариант веб-разработчикам, которые вынуждены писать низкоуровневый код, и при этом более производительный, чем PHP, Ruby, Python или JavaScript. Rust был также признан лучшим в номинации ”сама любимая технология” по результатам опроса разработчиков, проведённом StackOverflow в 2016 году (это означает, что большинство пользователей хотели бы продолжать использовать этот язык).


Kotlin существует уже около пяти лет, но только в этом году он достиг production-ready версии 1.0. Несмотря на то, что он ещё не достиг популярности Scala, Groovy или Clojure — три самых популярных и зрелых (не считая Java) языков под JVM — он выделяется из множества других JVM-языков и, кажется, готов занять свое место среди лидеров этой группы. Язык возник в JetBrains (создатель популярной IntelliJ IDEA IDE). Так что он продуман с упором на производительность труда разработчиков.


Crystal — ещё один язык, который надеется принести производительность программ на уровне C в высокоуровневый мир веб-разработчиков. Crystal нацелен на Ruby-сообщество, т.к. его синтаксис подобен, а порой идентичен, Ruby. И без того большое количество стартапов на Ruby продолжает расти, и Crystal может сыграть ключевую роль, помогая поднять производительность этих приложений на следующий уровень.


Elixir также черпал вдохновение из экосистемы Ruby, но вместо того, чтобы пытаться принести C-подобные преимущества, он ориентирован на создание высокодоступных, отзывчивых систем, т.е. на то, с чем Rails имеет проблемы по мнению критиков. Elixir достигает этих преимуществ при помощи Erlang VM, которая имеет прочную репутацию, основанную на 25 годах успешного применения в телекоммуникационной отрасли. Phoenix (веб-фреймворк для Elixir), наряду с большой и цветущей экосистемой, придаёт этому языку дополнительную привлекательность.


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


RedMonk stats


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


Elm


Elm — функциональный язык программирования, ориентированный на удобство и простоту использования, который компилируется в высокопроизводительный JavaScript-код. Вы можете использовать его, в том числе и совместно с JavaScript, для создания пользовательских интерфейсов в интернете. Основными преимуществами Elm по сравнению с JavaScript являются надёжность, лёгкость в поддержке и нацеленность на удовольствие от программирования. Более конкретно:


  • Нет runtime-исключений: Elm-код имеет репутацию никогда не выбрасывающего исключений во время выполнения. Совсем не то, что "undefined is not a function."
  • Легендарно любезный компилятор: компилятор Elm часто хвалят за наиболее полезные сообщения об ошибках среди конкурентов. "Если он компилируется, то, как правило, всё просто работает" — это распространённое мнение, даже после серьёзного рефакторинга. Это делает большие проекты на Elm гораздо легче в поддержке, чем соразмерные проекты на JS.
  • Семантическое версионирование: elm-package обеспечивает соблюдение семантических версий автоматически. Если автор пакета пытается сделать ломающие API изменения, не поднимая основной номер версии, elm-package обнаружит это и откажет в публикации новой версии пакета. Ни один другой известный менеджер пакетов не обеспечивает соблюдение семантического версионирования настолько надёжно.
  • Быстрый и функциональный: Elm является чистым функциональным языком, который гарантирует отсутствие мутаций и побочных эффектов. Это не только обеспечивает прекрасную масштабируемость Elm-кода, но также помогает ему рендерить UI приложения быстрее, чем React, Angular или Ember.
  • Мощные инструменты: elm-format форматирует исходный код в соответствии со стандартом сообщества. Нет больше споров по конвенциям оформления кода. Просто нажимаете кнопку “Сохранить” в вашем редакторе и ваш код становится красивым. elm-test поставляется с “батарейками” для поддержки как модульного, так и случайного тестирования. elm-css позволяет писать Elm-код, который компилируется в css-файл, так что вы можете разделять код между приложением и таблицами стилей, чтобы гарантировать, что ваши константы никогда не рассинхронизируются.

Elm код также может взаимодействовать с JavaScript. То есть вы можете вводить его в малых дозах в ваш JS код, и вы всё ещё можете использовать огромную экосистему JS и не изобретать колесо.


Посмотрите guide.elm-lang.org, чтобы начать, Elm in Action для более глубокого ознакомления и How to Use Elm at Work, если вам интересно, как можно было бы использовать Elm на работе.


Этот раздел написал Richard Feldman — автор Elm in Action и создатель elm-css, CSS-препроцессора для Elm.


Rust


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


Основными целями при проектировании языка были:


  • Безопасность: Многие C-подобные языки открывают путь к ошибкам в результате ручного управления памятью (например, висячие указатели или двойные освобождения). Rust перенимает передовые практики современного C++, такие как RAII и смарт-указатели и делает их применение обязательным, систематически гарантируя, что чистый код на Rust безопасен по памяти.
  • Скорость: Почти все языки работают медленнее, чем C, поскольку они обеспечивают абстракции, которые упрощают разработку программного обеспечения. Но это даётся ценой существенного увеличения накладных расходов во время выполнения (например, сборка мусора и динамическая диспетчеризация). Rust фокусируется на "абстракциях нулевой стоимости”, т.е. таких методах упрощения программирования, которые не требуют дополнительных затрат во время выполнения. Например, Rust управляет памятью во время компиляции и использует статическую диспетчеризацию для дженериков (по аналогии с шаблонами C++, но более безопасно по отношению к типам).
  • Конкурентность: Конкурентный код в системных языках часто хрупок и подвержен ошибкам, учитывая нетривиальность многопоточного программирования. Rust пытается смягчить эти проблемы путем предоставления гарантий на уровне типа какие значения могут быть разделены между потоками и как именно.

Rust также имеет несколько отличительных особенностей:


  • Проверка владения: прославленная возможность Rust — инструмент статического анализа, который считывает код и прекращает компиляцию, если он может привести к ошибке памяти. Это работает путем закрепления понятия, что значения либо принадлежат одному месту, либо используются во многих местах, и ​​последующего анализа того, как владение значением меняется во время выполнения программы. Проверка владения также исключает состояние гонки в конкурентном коде, используя тот же набор правил.
  • Композиция вместо наследования: Вместо того, чтобы использовать систему наследования классов подобно C++ или Java, Rust использует трейты или компонуемые интерфейсы для поддержки модульного программирования. Вместо того, чтобы указывать, что конкретный тип является частью иерархии классов, программист может описать тип на основе его возможностей, например, говоря о том, что тип должен быть Printable и Hashable вместо наследования от класса PrintableHashable.
  • Крутые инструменты: Любой C/C++ ветеран знает боль установки зависимостей, компиляции кода на нескольких платформах и борьбы с тайнами конфигурации CMake. Rust экономит бесконечные часы, проведенные в криках на GCC, предоставляя разумный менеджер пакетов и кросс-платформенные API.

Для получения дополнительной информации, ознакомьтесь с The Rust Book и Rust by Example.


Этот раздел написал Will Crichton — аспирант Стэнфордского университета, который специализируется на параллельных и конкурентных системах, визуальных вычислениях и архитектуре компиляторов и языков программирования. Он часто пишет о Rust в своем блоге.


Kotlin


Kotlin представляет собой статически типизированный язык, который ориентирован на JVM и JavaScript. Kotlin родился из потребности JetBrains, которая искала новый язык для разработки своего набора инструментов (который был в основном написан на Java). Что-то, что позволило бы им использовать существующую кодовую базу и в то же время решить некоторые проблемы, которые возникали из-за Java. И именно решения этих распространенных недочётов, встречающихся при написании программного обеспечения, определили большую часть характеристик Kotlin.


  • Лаконичность: уменьшить количество шаблонного кода, необходимого для выражения определенных конструкций.
  • Универсальность: создать язык, который подходит для любого типа промышленного применения, будь то веб, мобильная разработка, desktop или серверные приложения.
  • Безопасность: пусть язык сам обрабатывает некоторые из распространенных ошибок, связанные с такими вопросами, как null reference exceptions.
  • Взаимодействие: разрешить языку взаимодействие с существующими базами кода на Java, библиотеками и фреймворками, что обеспечивает возможность постепенного внедрения и использования результатов уже вложенных инвестиций.
  • Инструменты: JetBrains делает инструменты и делает их, исходя из убеждения, что многие рутинные задачи можно автоматизировать и привести к более эффективной и продуктивной разработке. Таким образом, язык должен легко позволять применять вспомогательные инструменты.

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


  • Null-safe по умолчанию: типы Kotlin по умолчанию не обнуляемы, что позволяет избежать назойливых исключений, связанных с пустыми ссылками/указателями.
  • Делегация первого класса: возможность делегировать функциональность члена класса внешней функции, что облегчает повторное использование и улучшает композицию.
  • Соглашения: ряд соглашений, которые позволяют писать выразительный код, открывая путь к созданию сильно типизированного DSL, который улучшает читабельность и упрощает рефакторинг.
    html {
    head {
      title {+"XML encoding with Kotlin"}
    }
    body {
        p { + "This is some HTML" }
    }
    }

Kotlin 1.0 был выпущен в феврале 2016 года, спустя более пяти лет разработки и тщательного тестирования в реальных проектах. В настоящее время более десяти продуктов JetBrains используют Kotlin. Также его используют такие компании, как Amex, NBC Digital, Expedia и Gradle.


Для получения дополнительной информации посетите kotlinlang.org


Этот раздел написал Hadi Hariri — вице-президент JetBrains, редактор блога Kotlin и главный докладчик на темы, посвящённые этому языку.


Crystal


Crystal является языком программирования общего назначения с девизом “Быстр как C, привлекателен как Ruby."


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


Архитектурные цели Crystal:


  • Синтаксис похожий на Ruby (но совместимость с ним не является целью).
  • Статическая типизация, но без необходимости указания типа переменных или аргументов метода.
  • Возможность вызывать C-код, написав биндинги к нему на Crystal.
  • Возможность выполнения и генерации кода во время компиляции, чтобы избежать шаблонного кода (boilerplate).
  • Компиляция в эффективный машинный код.

Crystal имеет уникальные функции, такие как:


  • Каналы: Crystal использует каналы, вдохновленные CSP (так же, как Go) для достижения конкурентности. Он использует согласованные легковесные потоки, называемые Fibers, для достижения этой цели. Fiber легко создать с помощью ключевого слова spawn и сделать выполнение асинхронным/неблокирующим.
  • Макросы: Crystal использует макросы, чтобы избежать шаблонного кода и обеспечить возможности метапрограммирования. Макросы очень мощные и раскрываются во время компиляции, то есть они не приводят к потери производительности.
  • crystal: Команда crystal сама по себе полнофунциональна и поставляется с большим количеством встроенных инструментов. Она используется для создания нового проекта, компиляции, запуска тестов и многого другого. Там также есть встроенная утилита для автоматического форматирования кода. А ещё crystal play представляет интерактивную среду для быстрого прототипирования, подобно irb.

Бонус:


Выразительность: Код читают гораздо чаще, чем пишут. Благодаря Ruby, Crystal действительно выразителен и лёгок для понимания. Это облегчает обучение для новичков и окупается в долгосрочной перспективе, благодаря упрощению сопровождения кода.


Для получения дополнительной информации вы можете обратить внимание на официальную Crystal Book и Crystal for Rubyists.


Этот раздел был написан Serdar Doğruyol — автор Crystal for Rubyists, создатель Kemal, веб-фреймворка для Crystal, куратор Crystal Weekly.


Elixir


Впервые представленный в 2012 году, Elixir является функциональным языком общего назначения, предназначенным для повышения производительности, масштабируемости и эксплуатационной надежности. В то время как язык является относительно новым, он компилируется в байт-код, который выполняется на виртуальной машине Erlang (BEAM). Erlang VM родилась в телекоммуникационной отрасли, развивается в течение почти 25 лет и стоит за многими сложными системами с высокой доступностью и низкой задержкой.


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


Синтаксис Elixir и набор инструментов черпали вдохновение от Ruby. В то время как синтаксические сходства только поверхностны, набор инструментов будет ощущаться знакомым каждому, кто знает Ruby. Команды хорошо продуманы, просты в использовании и обеспечивают прекрасную производительность труда разработчиков.


Цели языка:


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

Пример Phoenix-контроллера, написанного на Elixir
Пример Phoenix-контроллера, написанного на Elixir


Отличительные особенности:


  • Иммутабельные структуры данных и отсутствие побочных эффектов помогают сделать большие системы проще в обслуживании и понимании.
  • Супервизоры позволяют определить внутреннее дерево процессов и установить правила для автоматического восстановления от ошибок.
  • Сопоставление с образцом обеспечивает альтернативу условными и сторожевым операторам.
  • Конкурентность, основанная на акторах и отсутствии разделяемых данных, хорошо подходит для решения сегодняшних проблем конкурентности при масштабировании. См. Путь к 2 миллионам подключений.
  • Очень эффективное управление ресурсами означает, что вы можете обслуживать множество пользователей ограниченными аппаратными средствами. См. Почему WhatsApp требуется только 50 инженеров для обслуживания 900 миллионов пользователей.
  • Горячая замена кода позволяет проводить деплои без даунтайма.
  • Lisp-подобная система макросов позволяет напрямую манипулировать AST, обеспечивая очень широкие возможности метапрограммирования, вплоть до поддержки кастомного синтаксиса. (этот пункт добавлен переводчиком)

Elixir и Phoenix набирают популярность, поскольку это сочетание позволяет легко создавать сложные надёжные веб-приложения и API с хорошей поддерживаемостью, отличной производительностью и масштабируемостью. Вот почему Pinterest, Bleacher Reports и многие другие компании выбирают Elixir для ключевых частей инфраструктуры своих продуктов. Вы можете получить продуктивность без ущерба для производительности (или наоборот), чего не скажешь о большинстве других языков.


Этот раздел написан Christian Nelson — партнер и директор по разработке в Carbon Five.


P.S. Каков ваш Top-5 перспективных языков программирования?
P.P.S. От переводчика: На мой взгляд в список перспективных языков можно было бы включить ещё Nim. Если кто-то из хабровчан уже применяет этот ЯП и готов написать о нём подобное краткое эссе, то я с удовольствием добавлю его в статью (само собой, с указанием авторства).
Если Вы нашли неточность в переводе, относительно своего любимого ЯП, — пишите в личку, всё поправим.

Share post

Comments 146

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

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

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

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

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

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


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

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

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

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

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

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

                  В общем начить спорить на тему Kotlin (+ Java Platform естенствено) vs С# не вижу смысла.
                +5
                Разделяю ваш справедливый гнев по поводу тормознутости сборки под андроид, но время компиляции медленное, безотносительно к котлину. Java + gradle будет так же медленно, как и kotlin + gradle. Из этого сравнения видно, что те же яйца только в профиль.
              –3
              по моему на сегодняшний момент C# конкурентов нет, а учитывая что он все более становиться мультиплатформенным — есть все шансы что он обгонит и Java, и C++
                +2

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

                  0
                  Ну средний уровень сообщества не всегда отражается на среднем уровне программистов в конкретном месте, так что корреляции между ним и необходимостью учить/руководить может и не быть.
              +2

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

                0
                А разве PureScript не является диалектом Haskell?
                  +2
                  не более, чем Elm
                    0
                    Спасибо, видимо, я его с GHCJS спутал.
                  –1

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

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

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


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

                        +10
                        Знаете ли, таки путаете. Я занимался оценкой применимости всех трех подходов (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 и концепциям, которые были в нем изобретены.
                          +3

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

                            +1

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


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


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

                              +5
                              Давайте сначала разберемся, с какой целью вы спрашиваете.
                              Если у вас намечается конкретный проект и вам непременно нужен типизированный 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 придумали идеал, лучше которого быть уже в принципе не может.
                                +5
                                «язык слабее Хаскеля» — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

                                Переписывал на 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.

                                  0

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

                                    0

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

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

                                        В большинстве случаев можно и без макросов обойтись, вот например шаблон, который ведёт себя также как и функция 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 становится не намного многословнее баша.

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

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

                                      0

                                      А они и взяли 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
                                  +3
                                  А мне кажется, что сама по себе линия — не очень удачный фактор. Я б искал языки, которые имеют значительный перевес ГитХаба в сравнении с СО — ибо в них меньше ВТФ или лучше литература и при высокой популярности. Например, D. Проектов значительно больше, чем в Расте или Еликсире, а вопросов по нему меньше или равно. Видимо, хороший язык.
                                    +5
                                    Понимаете, D уже сложно назвать молодым и перспективным… Всё-таки языки, которым больше 10 лет, уже заняли свои ниши и вероятность их бурного роста или падения не высока. Должен быть какой-то мощный фактор.
                                    Для примера, появление Rails было фактором роста для Ruby (которому на тот момент было около 10 лет). С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.) потеряли рынок, потому что их пытались продолжать продавать.
                                    Каков же фактор для D, которому 15 лет в этом году исполнилось?
                                      0
                                      С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.)

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

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

                                        Рядом карабкаются Ada,Pascal и Smalltalk.
                                        Я бы назвал другие, не 5 конечно но хотя бы 3: Go, TypeScript, Swift.
                                        Первое что приходит на ум. Первые 2 потому что в продакшене спасают, третий… Ну вы сами понимаете.
                                          +2
                                          Я бы назвал другие, не 5 конечно но хотя бы 3: Go, TypeScript, Swift.

                                          статья все-таки про взлетающие языки, а эти 3 уже уверенно взлетели. Много вакансий, активно используются в продакшне

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

                                                    –1

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

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

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

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

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

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

                                                                +2
                                                                С тем, что 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-семейства.

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

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


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

                                                                    +1
                                                                    Я 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 поглубже копнуть )
                                                          0
                                                          завтра выйдет версия Phoenix, работающая поверх другого веб-сервера

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


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

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

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

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

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

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

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

                                                                0

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

                                                                            Наконец-то разработчики получили замену Java, а не скриптовый язык (Groovy) или вообще фп (Clojure, Frege, Scala).
                                                                            • UFO just landed and posted this here
                                                                                +3
                                                                                Эм, вы не сходили в доку и хотите чтобы я вам перечислил фичи языка которы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 разработчику.
                                                                                  0
                                                                                  А Java 8 всё еще далек от современного языка, Котлин на голову выше, но всё еще прост и понятен любому Java разработчику

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                            +3

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

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

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

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

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


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

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


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

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

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

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

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

                                                                                                    +3

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


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


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

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

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

                                                                                                        0

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

                                                                                                          0
                                                                                                          У 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…
                                                                                                            0

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

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

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


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

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

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

                                                                                                  Интересно, куда бы автор отнес Haxe — к полудохлой маргинальщине, мейнстриму, «второму эшелону» или «перспективным языкам» (как по мне, так это та же маргинальщина).
                                                                                                    0

                                                                                                    Ток от создателей, интересно слышать их позицию и прогнозы, и насколько все оправдалось теперь.
                                                                                                    LangNext 2014 (C++, Rust, D, Go)

                                                                                                      0
                                                                                                      Я бы перспективным назвал Clojurescript. Я пробовал многие разные языки транспилирующие в JS, настоящее удовольствие я стал получать от работы именно с него.

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