Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как 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):
Каждый из этих языков может похвастаться увлечённым сообществом и собственной еженедельной новостной рассылкой. Если вы подумываете об изучении молодого языка с захватывающими возможностями для будущего, прочитайте краткие презентации для каждого из этих пяти языков, написанные опытными энтузиастами и лидерами соответствующих экосистем.
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 Dogruyol — автор 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
Отличительные особенности:
- Иммутабельные структуры данных и отсутствие побочных эффектов помогают сделать большие системы проще в обслуживании и понимании.
- Супервизоры позволяют определить внутреннее дерево процессов и установить правила для автоматического восстановления от ошибок.
- Сопоставление с образцом обеспечивает альтернативу условными и сторожевым операторам.
- Конкурентность, основанная на акторах и отсутствии разделяемых данных, хорошо подходит для решения сегодняшних проблем конкурентности при масштабировании. См. Путь к 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. Если кто-то из хабровчан уже применяет этот ЯП и готов написать о нём подобное краткое эссе, то я с удовольствием добавлю его в статью (само собой, с указанием авторства).
Если Вы нашли неточность в переводе, относительно своего любимого ЯП, — пишите в личку, всё поправим.
Комментарии (146)
fshp
18.09.2016 00:37+2Где-то рядом с Elm, но на ступеньку повыше, я бы поставил PureScript.
bubuq
18.09.2016 11:31-1А я бы нет. PureScript это академическое упражнение по имплементации транспилятора хаскеля в яваскрипт, а Elm был специально создан для клиентского программирования, имеет худо-бедно экосистему и сообщество, использующее язык в продукции.
dimsmol
18.09.2016 12:05+1Вы путаете PureScript и GHCJS.
PureScript — отдельный язык, причем гораздо более зрелый, чем Elm, но менее разрекламированный.
Elm по сравнению с PureScript выглядит «игрушечным» — хорошо решает отдельные задачи, но не очень-то универсальный.bubuq
18.09.2016 12:27-2Знаете ли, я не путаю. Я занимался и первым, и вторым, и третьим. Отличия PureScript от хаскеля в большой степени косметические. Поставляется он без стандартной библиотеки, то есть вообще без всего, даже Prelude нет.
Elm же был построен вокруг реактивного программирования, с введением сигналов и адресов. Впоследствии автор от этого отказался, заменив это более простой системой подписок (Subscriptions), для того, чтобы таки да, хорошо решать отдельные задачи, и задачи эти называются выполнение в броузере, хаскель же несомненно универсален, и один из наиболее совершенных языков в принципе, но мы же решаем как раз свою отдельную задачу, зачем же его в броузер весь целиком?
dimsmol
18.09.2016 13:50+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 и концепциям, которые были в нем изобретены.
thewizardplusplus
18.09.2016 15:11+3Большое спасибо за это сравнение! Давно присматриваюсь к обоим языкам (Elm и PureScript), хочется попробовать что-то чистое функциональное на фронтенде. Но не мог определиться с выбором, вроде оба достаточно популярны в своих кругах, оба имеют сообщество. Сложно выбрать со стороны, не зная приведённых вами нюансов.
pawlo16
18.09.2016 17:35+1Особенности реализации сигналов в Purescript малоинтересны, поскольку в Elm 0.17 их выкинули за ненадобностью. А как на счёт реализации Elm Architecture в Purescript, она там есть? встроенная поддержка WebGL, чтобы компилятор мог распарсить текст шейдеров на GLSL и проверить согласованность используемых типов между шейдерами и основной программой?
О каких альтернативных подходах идёт речь и зачем их использовать?
"язык слабее Хаскеля" — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.
dimsmol
19.09.2016 00:42+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 придумали идеал, лучше которого быть уже в принципе не может.
dimsmol
19.09.2016 01:32+5«язык слабее Хаскеля» — тут не помешало бы пояснить, что вы имеете ввиду. Как по мне, так упрощение языка снизило порог вхождения и улучшило читаемость исходного кода.
Это очень наивно, полагать, что Haskell переусложнен ради самой сложности и что если от него отгрызть подмножество, то все станет лучше. Все его «сложности» появились постепенно, принося с собой весьма востребованные возможности. Если выкинуть все это и свести к этакому «functional basic», разумеется порог входа понизится, но и возможности пропадут.
Более того, использовать те возможности, что останутся, тоже станет сложнее. Ведь многие фишки языка появились как раз, чтобы упростить некоторые вещи. Никто не мешает взять PureScript или Haskell и просто не использовать то, выходит за пределы возможностей Elm. Но тогда придется либо оставаться в рамках более простых вещей, либо все станет только сложнее.
Да и язык не так уж сложен, сложно научиться его эффективно использовать — все эти монады, теория категорий, etc. Все это не часть самого языка, а то, что с его помощью можно делать. Можно все это отбросить, порог входа станет ниже, но делать что-то полезное станет сложнее.
Мне сложно привести конкретные примеры, где Elm ограничен в возможностях по сравнению с Haskell и PureScript, просто потому что последний раз я писал на нем очень давно и уже не помню, во что конкретно упирался. Навскидку, вот пример про Higher-kinded types. Либо можно посмотреть список расширений Haskell и прикинуть, чего из этого нет в Elm (скорее всего ничего). Вот тут можно почитать о них подробнее. PureScript включает некоторое подмножество этих расширений.
Правда, если вы никогда не писали на полновесном функциональном языке, то все это может выглядеть абстрактно и не очень понятно.
dimsmol
19.09.2016 03:36+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, очень многое говорит о приоритетах авторов. Для кого-то, возможно, это хорошие новости, но очевидно не для всех.
hellosandrik
18.09.2016 13:22+5Зря вы так пренебрежительно о PureScript отзываетесь :( В соседнем топике я уже писал об этом, но все же, PureScript — это самый прагматичный подход на данный момент. Если говорить по-честному, то экосистема у обоих языков пока недостаточно развита, чтобы целиком писать на них продакшен, поэтому сейчас очень важна простота взаимодействия с существующим js кодом (и тут Elm пока сильно проигрывает). Я попробовал оба варианта и заметил, что если у меня проблема с реализацией чего-то в PureScript я легко могу откатиться в старый добрый JS, но если у меня проблема с Elm, то как правило это значит, что я сильно влип. C PureScript я могу целиком использовать всю мощь экосистемы Node.js и знакомых инструментов, не говоря уж о том, что его можно легко использовать на сервере. Elm хороший язык, но подойдет только для специфических задач (шаг влево, шаг вправо — расстрел), PureScript более универсальный. И то, что это не молодой язык, а проверенный временем Haskell (почти), я считаю скорее плюсом. P.S: Не имею ничего против Elm, но мне грустно, когда хороший инструмент (PureScript) называют "поделкой". Elm получил внимание на волне популярности React/Redux и получил спонсорство от компании в которой работал Эван, а PureScript достиг всего только благодаря сообществу.
Vilyx
18.09.2016 01:56-4Несправедливо обделили вниманием Dart. Этот язык по линейке Git/Overflow обгоняет даже Rust.
DexterHD
18.09.2016 04:05+8Одно плохо. Он мертв по факту. А потуги Гугла запилить мобильную ОС с ним, очередные гвозди в его гроб и пустая трата времени.
superyarik
13.01.2017 23:35а какое он напряжение выдает? у меня есть для ардуино плата, которая конвертирует напряжение в нужное, но нет зарядника для авто аккумулятора.
зы: мотоаккум умер по той же причине :)Hayate
18.09.2016 04:23+16Ну это гугл. Возьмут и закроют. Да и где этот дарт можно запустить кроме специальной сборки хрома?
А трансляция в js мне кажется сомнительным вариантом. Сначала решать проблемы в коде дарт, а потом в коде жс.Vilyx
18.09.2016 04:42-8Вы описали надуманную проблему, а есть что-то более существенное, чем ваше мнение не основанное даже на опыте использования этого языка? У меня есть пара коммерческих проектов, которыми я занимался несколько лет назад, живы до сих пор, прекрасно работают. За всё время использования при компиляции в JS была проблема один единственный раз, да и то связано со сторонней библиотекой. Это ни в какое сравнение не идёт даже с разработкой Android приложений нативными средствами, когда проверка объекта на null даёт NPE. Я бы посоветовал ознакомиться с Dart, попробовать его своими руками и только после этого делать выводы.
Hayate
18.09.2016 04:49+5Нет, опыта использования у меня нет. Я могу только экстраполировать свой опыт в других экосистемах на dart и также делать выводы из количества вакансий. Вакансий или 0, или предлагают опечатку в запросе исправить. То есть используется он в основном там где исполнителю хочется прокачать скилл изучая что-то новое, а заказчик не в курсе, что за его счёт качают скилл, или ему без разницы где он потом будет искать людей на поддержку.
Vilyx
18.09.2016 05:08-5Экстраполяцию надо делать аккуратно, вчера у меня не было жены, сегодня одна, а завтра будет две, так что ли? Про вакансии тоже надо внимательнее смотреть, часто они сопряжены с требованием знания JS, ибо на сегодня одно без другого никак. Хотя бы спросите Wrike зачем они используют Dart в своих проектах.
Вы делаете выводы исходя из ложных посылов.
Nagg
18.09.2016 12:02+1когда проверка объекта на null даёт NPE
А можно подробнее? :)
Vilyx
18.09.2016 15:55+1Intent intent = this.getIntent(); if(intent!=null) { Bundle bundle = intent.getExtras(); if(bundle != null) { Log.d("OK",bundle.toString()); } }
Вот в этом коде у меня выскакивал NPE на 4ой строке. Возможно дело было в конкретной версии SDK, а может в каких-то моих действиях при передачи extras, потому как сейчас, чтобы не соврать, я перепроверил на свежем проекте и этой ошибки уже не получил.Nagg
18.09.2016 16:58Ну так у вас NPE упал внтутри getExtras очевидно, а не из-за того, что intent магическим образом стал наллом.
Vilyx
18.09.2016 19:41Ошибка вылетала именно на if'e, а не на getExtras. Специально проверял и удалял по одной строке. Очень был удивлён такой ошибке, почему о ней и упомянул.
wizzard0
18.09.2016 02:42+3Nim хорош, но до того чтобы попробовать на нем какой-то продакшен все никак руки не дойдут. Кто-то пробовал на нем писать больше чем пару хелловорлдов? :)
RPG
18.09.2016 19:25+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.
Source
18.09.2016 20:09А можете про макросы Nim подробнее рассказать? При беглом взгляде на документацию выглядит действительно извращенно (но не в хорошем смысле) по сравнению с макросами аля LISP. Просто обернуть код в макрос без вереницы
newCall,newIdentNode, etc. никак нельзя?RPG
18.09.2016 20:22Можно, это будет просто template. Макросы вообще позволяют манипулировать синтаксическим деревом, т. е. они не для простого оборачивания кода, а для магии. Макорс может полностью изменить переданный ему на вход кусок кода.
Source
19.09.2016 02:25Да это понятно, просто в доке Nim эти манипуляции выглядят как-то излишне многословными.
RPG
19.09.2016 09:57+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 становится не намного многословнее баша.
grossws
18.09.2016 20:52регулярки прикручены наспех и работают медленнее, чем perl в десятки раз. Редкий язык, где реализация "в лоб" быстрее regexp.
Странно, что при нормальном ffi не взяли просто pcre, который по функциональности более-менее on par с perl'ом и по скорости очень даже ничего.
RPG
18.09.2016 22:03А они и взяли 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
TheShock
18.09.2016 03:38+3А мне кажется, что сама по себе линия — не очень удачный фактор. Я б искал языки, которые имеют значительный перевес ГитХаба в сравнении с СО — ибо в них меньше ВТФ или лучше литература и при высокой популярности. Например, D. Проектов значительно больше, чем в Расте или Еликсире, а вопросов по нему меньше или равно. Видимо, хороший язык.
Source
18.09.2016 11:44+5Понимаете, D уже сложно назвать молодым и перспективным… Всё-таки языки, которым больше 10 лет, уже заняли свои ниши и вероятность их бурного роста или падения не высока. Должен быть какой-то мощный фактор.
Для примера, появление Rails было фактором роста для Ruby (которому на тот момент было около 10 лет). С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.) потеряли рынок, потому что их пытались продолжать продавать.
Каков же фактор для D, которому 15 лет в этом году исполнилось?G-M-A-X
18.09.2016 22:47С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.)
Продавали не язык, а IDE (Delphi). Да и какая альтернатива Delphi? MCVC? Но он платный. :)
Также, как сейчас под бесплатный PHP продают PHPStorm и PHPEd, ибо бесплатные ИДЕ унылые.Source
18.09.2016 23:30+2Точнее сказать продавали комплектом. Бесплатно скачать компилятор и стандартную библиотеку(VCL) возможности не было, насколько я помню. Для того же C++ такая возможность была.
stepik777
18.09.2016 16:57+3Не знаю как они там считают. Поиск по гитхабу назодит 12971 проектов на Расте и 6303 на D. Хотя каждый раз при обновлении страницы число меняется в разные стороны.
Source
18.09.2016 17:31+1Там надо цифры в столбце слева смотреть:
5146 репозиториев и 1935 пользователей у Rust, и 5031 / 2491 — у D.
Source
18.09.2016 18:02+2Для истории выпишу данные с Github по всем языкам из статьи:
Elm — 433 / 194
Rust — 5146 / 1935
Kotlin — 960 / 1541
Crystal — 150 / 52
Elixir — 2668 / 861
Через годик посмотрим динамику.
DexterHD
18.09.2016 04:07Теперь взгляните, как четыре из этих пяти языков карабкаются по лестнице популярности (на основе данных StackOverflow и GitHub):
Рядом карабкаются Ada,Pascal и Smalltalk.
Я бы назвал другие, не 5 конечно но хотя бы 3: Go, TypeScript, Swift.
Первое что приходит на ум. Первые 2 потому что в продакшене спасают, третий… Ну вы сами понимаете.Laney1
18.09.2016 09:47+2Я бы назвал другие, не 5 конечно но хотя бы 3: Go, TypeScript, Swift.
статья все-таки про взлетающие языки, а эти 3 уже уверенно взлетели. Много вакансий, активно используются в продакшне
Source
18.09.2016 12:26+3Ага, тем более, что Go и Swift в статье упомянуты, как перспективные для перехода уже в первый, а не во второй эшелон.
Source
18.09.2016 12:30+3Рядом карабкаются Ada, Pascal и Smalltalk.
И что с того? Языки, которым больше 10 лет, уже заняли свои ниши и особо никуда не двигаются. Ada и Pascal очень медленно сползают вниз, а Smalltalk начал шевелиться с появлением Pharo, но тоже с туманными пока перспективами, т.к. момент был упущен лет 15 назад.
ittakir
18.09.2016 07:34+7Язык программирования — это инструмент. Как сварочный аппарат, например. Если все в основном, скрепляют детали на сварку, то зачем вам осваивать использование заклёпок? Со сваркой вы всегда найдете работу. Да, на заклепки тоже есть пару мест в стране — это производство военных самолетов, но стоит ли оно того? Платят столько же, зато если сократят, то останетесь совсем без работы.
Некоторые говорят, что за заклепками будущее. Но я им не верю. Мне кажется, рынок труда очень неплохо расставляет все по своим местам.geher
18.09.2016 10:20+2А с будущим на самом деле особо не угадаешь. Другой вопрос, что обычно тенденции прослеживаются сильно заранее, давая время на изучение «заклепок», не бросая любимую «сварку».
Впрочем рынок труда может резко перестроиться и расставить все по «своим» местам совершенно другим образом.
Правда для таких резких перестроек нужен серьезный технологический прорыв, но в истории они уже случались. Единственное, что пока радует, в области программирования не бьло резкого умирания какого-либо языка. А вот резкий рост практически с нуля случался. Например, после появления первых языков высокого уровня резко потребовалось большое колличество специалистов для этих языков, в то время как потребность в знании ассемблера затухала достаточно медленно (ассемблер сам по себе использовался в разработке программ под процессоры 80386, а может быть, что и существенно позже).ittakir
18.09.2016 12:16-1Вот именно, что не было резкого умирания какого-либо языка. Обычно происходит плавное угасание интереса работодателя — новые проекты делают на чем-то новом, старые продолжают поддерживать. И есть время перейти на новый язык — несколько лет минимум, пока работы совсем не останется.
Поставьте себя на место работодателя. Почему новый проект нужно делать на технологии Х? На рынке больше всего опытных специалистов, умеющих с ней работать. При этом они дешевле. Если кого-то нужно уволить, то легко можно найти замену без ущерба для бизнеса.
Так можно сказать про C#, Java. Но не про Elm или Rust.
Если вы решили стать специалистом в том же Rust, подумайте, наняли бы вы себе программистов на ваш личный новый проект на нем?Source
18.09.2016 12:44+4Вас послушать, так до сих пор все программировали бы исключительно на Fortran, Lisp и Algol, ну и изредка на Smalltalk, Simula и Forth.
Но почему то из этих шести на плаву только Lisp и Smalltalk, и то работу на них найти ещё сложнее, чем на Elm или Rust.
Ну и в целом, работа — это же не главная мотивация в программировании, что-то можно изучать из любви к искусству, а не только в корыстных интересах ;-)Terras
18.09.2016 13:18+1Все очень просто. Есть кривая, которая показывает вовлечение целевой аудитории в какое-либо дело.
Так вот там на новаторов и ранних последователей приходится всего 15% от всей потенциальной аудитории. Причем на новаторов всего 2,5 %. Это означает, что только 2,5 из 100 программистов будет интересно учить что-то новое и «неизвестное».
Также эта кривая показывает нам, что если проекту не получается захватить нужное число людей, которое скажет «Да, это здорово», то он очень быстро загнется. И фактически все усилия будут напрасны.
Поэтому сейчас у человека выбор учить непонятную хрень, которая то ли будет работать, то ли нет. Либо можно выучить c#, который уже даст тебе работу.
Source
18.09.2016 14:10-1Есть кривая, которая показывает вовлечение целевой аудитории в какое-либо дело.
Верно. Этот вопрос освещён в книге «Профессиональная разработка программного обеспечения» Макконнелла.
Причем на новаторов всего 2,5 %. Это означает, что только 2,5 из 100 программистов будет интересно учить что-то новое и «неизвестное».
А вот это уже не совсем верно. Новых технологий много, допустим, на 1 устоявшуюся приходится 10 новых, и вот уже получается, что 25 из 100 программистов интересно учить что-то новое.
Поэтому сейчас у человека выбор учить непонятную хрень, которая то ли будет работать, то ли нет. Либо можно выучить c#, который уже даст тебе работу.
Про это сказано в начале статьи… Если есть проблема с работой, то лучше бы выучить что-то из мейнстрим языков. Но для опытных программистов это уже неинтересно… Ну сколько лет можно учить C#? Там со времён C# 3.0 изменения весьма минорны, даже странно, что мажорную версию языка поднимают постоянно.
И фактически все усилия будут напрасны.
Если Вам это через силу, то не надо конечно. Учить что-то новое надо в удовольствие, потому что интересно, потому что обогащает опыт, расширяет кругозор, а не для того, чтобы в резюме больше строчек было.ittakir
18.09.2016 14:43+1Если новаторов всего 2.5%, то они между собой разберут эти 10 новых технологий. Остальные 97.5% не парятся.
Учить можно не C#, а например, весь .Net фрейворк + веб фреймворки. Я не спец, но кажется, он весьма обширен.
А если очень хочется поучить непонятную ненужную хрень, то зачем ограничивать себя программированием?
Изучите испанский, готовку, ковку, сварку, параплан… Банальный C# вас накормит, зато в старости будет что вспомнить.Source
18.09.2016 15:04+1Учить можно не C#, а например, весь .Net фрейворк + веб фреймворки. Я не спец, но кажется, он весьма обширен.
Вы уж определитесь, либо всё, что не нужно на текущем месте работы для текущих задач, — это непонятная ненужная хрень, либо можно не ограничивать себя одним языком/платформой.
А если очень хочется поучить непонятную ненужную хрень, то зачем ограничивать себя программированием?
А я разве писал, что нужно ограничивать себя программированием?
Ну и если Вам лично что-то непонятно или не нужно, то это не значит, что это хрень. Кстати, исторический факт: люди, подобные Вам, лет 10-12 назад носились с криками, что .NET — это никому ненужная хрень xDxaoc80
20.09.2016 13:23+1Поскольку я начинал активно разрабатывать примерно в то время, когда многие кричали, что ".NET — это никому ненужная хрень", я хочу уточнить. Эти споры относились на 90% к разработке десктоп приложений, а не WEB. И при всем моем искреннем уважении к C# и .NET аргументы против .NET имели место. По моим наблюдениям сейчас для GUI приложений лучше использовать, например, Qt. Это и кроссплатформенно и быстро и красиво. Использовать WPF для десктопных приложений сейчас решаются не многие.
Source
20.09.2016 14:11+1Эти споры относились на 90% к разработке десктоп приложений, а не WEB.
Ахах, это да, на тему того, что ASP.NET — неюзабельная хрень, практически все были единодушно согласны. Но спустя годы сделали порт Rails, назвали ASP.NET MVC и ничего, стало можно и под веб на C# комфортно разработку вести. Так что это ещё и исторический пример того, как реальная хрень может быть замещена чем-то путным в рамках одной и той же платформы.
Использовать WPF для десктопных приложений сейчас решаются не многие.
А, кстати, почему? Боятся ограничить себя рамками Windows?
Я как-то давно отошёл от разработки десктопных приложений, поэтому не в курсе. Вообще Qt с .NET — это интересное сочетание, почему тогда не GTK или wxWidgets?
KvanTTT
19.09.2016 00:07+1Там со времён C# 3.0 изменения весьма минорны, даже странно, что мажорную версию языка поднимают постоянно.
Я бы не сказал, что минорные. После шестой версии, например, C# 5 воспринимается многословным и неудобным. Я бы не хотел переходить обратно, т.к. использую практически все возможности нового синтаксиса.
А чем dynamic и async/await не новая концепция? И какие тогда по вашему изменения тянут на изменение мажорной версии?
Source
19.09.2016 01:32+2Понимаете, если программировать только на C#, то это всё может выглядеть круто. Но по факту это просто заимствование идей из других языков. C#, начиная с 3-й версии, начал путь в функциональщину. Это классно, но совсем не ново.
Ну, добавили сначала простенький вывод типов (var) и лямбды, потом открыли возможность тип привязывать к данным, а не к переменным, а переменные ребиндить (dynamic) и возможность асинхронно код вызывать (async/await), ах да, ещё интерполяцию строк )))
Я не говорю что в этом есть что-то плохое, наоборот, мне нравится C# и направление, в котором он развивается тоже. Просто, если по-честному, ничего такого грандиозного в этом развитии нет со времён появления LINQ. Язык стабилен и просто обрастает мелкими приятными плюшками. Всё здорово.
После шестой версии, например, C# 5 воспринимается многословным и неудобным.
Ахах, это Вы просто F# не пробовали, вот где лаконичность.
И какие тогда по вашему изменения тянут на изменение мажорной версии?
Настолько глобальные, что нарушают обратную совместимость.
Gorthauer87
18.09.2016 13:05+1Ну вот не знаю, работу нужно искать над проектами в целом, а они могут состоять из множества программ на самых разных языках.
iqiaqqivik
18.09.2016 10:23+1> Также Elixir достигает прироста производительности при помощи Erlang VM
Также? Прироста?
> с использованием либо Cowboy (низкоуровневый HTTP-сервер), либо Phoenix
Бутерброд достигает вкуса с использованием либо масла, либо хлеба.
Минимальное знакомство с предметом перестало быть необходимым для написания т. н. статеек на хабр?
Source
18.09.2016 11:55+4Хоть формулировки у Кристиана Нельсона и странные местами, я не вижу в них чего-то криминального и показывающего, что он не знаком с предметом.
Прирост производительности очевидно имеется в виду по сравнению с Ruby :-)
То, что Phoenix работает поверх Cowboy — это факт, но это совсем другой уровень абстракции.
Если завтра выйдет версия Phoenix, работающая поверх другого веб-сервера, Вы очень долго не заметите что что-то поменялось.Source
18.09.2016 12:12+2Поправил формулировки на более точные по смыслу. А вообще для этого ЛС есть ;-)
iqiaqqivik
18.09.2016 15:55И да, и нет. В куске про отличия эликсира единственный внятный и грамотный пункт, отличающий именно эликсир — «добавлен переводчиком» :). Весь остальной кусок — каша из «где-то слышал про эрланг» и «Валим из пятерки руби-коммитеров».
Я хочу, чтобы интересующиеся, но далекие от эликсира читатели знали, что есть люди, считающие, что относиться к этому куску имеет смысл очень скептично.
Source
18.09.2016 18:37С отличиями всегда есть вопрос: относительно чего? По сравнению с Erlang основная отличительная особенность Elixir — это макросы, даже синтаксис и сокращение boilerplate-кода — это всё следствия. А если говорить об отличиях среди всей массы языков программирования, то они на 90% cовпадут с отличительными особенностями Erlang и это естественно.
Я просто не очень понимаю, с чем конкретно Вы не согласны в этом куске?iqiaqqivik
18.09.2016 20:06С тем, что ErlangVM — не язык, и приписывать преимущества виртуальной машины тридцатилетнего возраста эликсиру — довольно странно.
Макросы эликсира — это гениальный гигантский прыжок вперед по сравнению со всеми остальными «новшествами» остальных сравниваемых языков (для тех, кто не RMS и хочет, чтобы язык был не write-only, а LISP, к сожалению, очень быстро им становится на заметных объемах). Я всегда привожу в пример имплементацию строк и регулярок: они из коробки поддерживают актуальный UTF-8, потому что эликсир парсит спецификацию консорциума на стадии компиляции.
Все остальное — либо преимущества ВМ эрланга (которые неоспоримы: 15 девяток и т. д.), либо не очень понятные кивки в сторону синтаксиса, который близок и понятен рубистам, но традиционно недолюбливается питонистами, например.
Source
18.09.2016 20:40+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-семейства.
grossws
18.09.2016 21:31+1а макросы местами не дотягивают до гибкости LISP, но при этом являются наиболее мощными из всех известных мне языков не из LISP-семейства.
Очень напомнило скорее Scheme, чем CL, в частности наличием hygienic macros. Но с elixir не знаком и не возьмусь судить о мощности их реализации макросов, например, в сравнении с Scheme или Rust. Будет прекрасно, если проведёте сравнение с Scheme или CL.
Макросы в Rust базируются на тех же принципах (и той же работе Macro-by-Example — Kohlbecker, Wand // 1986), что и в Scheme.
Source
18.09.2016 23:18+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 поглубже копнуть )
nwalker
19.09.2016 15:10завтра выйдет версия Phoenix, работающая поверх другого веб-сервера
Вероятность этого события стремится к нулю.
- cowboy это фактически единственный живой веб-сервер для erlang.
- Plug так интересно задизайнен, что у них нет ни своей реализации websockets, ни даже API для protocol upgrade. plug-websocket использует cowboy напрямую, как работает
Phoenix.Transports.WebSocketя навскидку не могу разобраться. - адаптер для более-менее живого elli висит в PR уже 2.5 года и тоже никому не интересен.
croupier
18.09.2016 11:44Очень не хватает инфы про поддержку этих языков в популярных IDE.
Несколько лет назад брался за изучения питона и был поражён различиями в удобстве работы в разных IDE по сравнению даже с php. На тот момент самой умной (на взгляд новичка) оказалась eclipse, значительно обойдя даже pycharm. Это для python, что уж говорить про «новичков»…Source
18.09.2016 12:23+1Для Kotlin, Elixir, Elm и Rust есть плагины под IntelliJ IDEA, которые работают в том числе и с бесплатной Community Edition.
Также есть плагины под популярные редакторы: Sublime, Atom, VS Code. Ну и само собой под Emacs и Vim. Это уже и к Crystal относится, вот по нему инфа.
pawlo16
18.09.2016 12:24+2Elm уникален и определённо имеет шанс взлететь, поскольку ориентирован на самую востребованную платформу, и предстовляет собой очень простой язык без хаскелизмов. Он собственно уже частично взлетел, так как React и Redux — это не что иное как кривой порт Elm для js
Elixir тоже наверно хорошо, если его кто-то действительно будет применять в телекоммуникациях, а не только в веб.
Virviil
18.09.2016 13:10Elixir тоже наверно хорошо, если его кто-то действительно будет применять в телекоммуникациях, а не только в веб.
Что вы подразумеваете под "веб"? Программы, связывающие передачу данных через http в браузер и базу данных? Мне кажется на сегодняшний день веб это что-то большее. И поэтому MVC уже не "наше всё". И для веба нужны чуть более гибкие инструменты чем %мой_любимый_веб_фреймворк%.
pawlo16
18.09.2016 14:14Ваша мысль ушла не туда. Я про то, что
В настоящее время Elixir в основном используется для создания веб-приложений с использованием как Cowboy (низкоуровневый HTTP-сервер), так и Phoenix (полнофункциональный фреймворк для разработки веб-приложений). Кроме того, Elixir пробивается в нишу встраиваемых систем благодаря фреймворку Nerves.
Так вот это полная ерунда в сравнении со сферой применении Erlang, на котором написан софт, обрабатывающий 50% всего сотового трафика.
lookid
18.09.2016 16:53+4Это не 5 «перспективных», это 5 «интересных» языков программирования. Из них перспективные только Kotlin из-за «совместимости» с Java. Остальные Ок для поиграться и завести пару реп на гитхабе для толерантности к другим языкам. Писатели статей иногда забываются, и считают IT автономной и независимой областью, но это совсем не так. Не будет заказчика — не будет IT. А заказчику решение нужно вчера, а не «давайте перепишем на Elixir, он такой ня!».
Terras
18.09.2016 18:22Именно по этой причине перспективными являются kotlin, go и swift — так как за ними стоит «большой» заказчик, который обеспечивает языку задачи и ресурсы для их выполнения.
Другие языки — это дело случая и некоторой удачи. Например, захочет какая-то большая компания сделать что-то грандиозное и выделит ресурсы, то дело пойдет, а нет. Так все будет в полудохлом состоянии.Source
18.09.2016 19:09Именно по этой причине перспективными являются kotlin, go и swift — так как за ними стоит «большой» заказчик, который обеспечивает языку задачи и ресурсы для их выполнения.
По-моему только Swift может похвастаться заботливым отношением от большой компании. Google не особо запаривается поддержкой своих языков. Ну а JetBrains наверняка будет приятно, что Вы их в один ряд с Google и Apple поставили.
Source
18.09.2016 18:45+1Я не могу сказать про все языки, но Crystal и Elixir появились именно потому, что в этом есть потребность у крупных проектов на Ruby. После чего и создатели Ruby активнее зашевелились в сторону производительности. Но, как мы знаем, обещанного 3 года ждут, а нагрузку надо держать уже сегодня и в этом Elixir отлично помогает. А кому-то возможно и Crystal уже помогает.
TheShock
26.09.2016 16:28Ну CoffeeScript тоже когда-то «потребность у крупных проектов на Ruby», а потом хипстерам надоело и где он теперь?) Не такой уж и нужен.
Source
26.09.2016 17:03CoffeeScript, точнее большинство его фич, уже в ES6.
TheShock
26.09.2016 17:17Ну разве что stage0 =) Да и угас хайп на него уже несколько лет как, до того как ES6 вошел в мейнстрим с популяризацией Бабеля.
Могли и дальше добавлять сахар. Там ведь не только классы и стрелко-функции были, а синтаксис из питона, синоним @ для this, убран var, несколько синонимов для boolean значений, много важных вещей, короче.
Так что мне кажется, что им просто надоело, а не в JS6 дело.
s1dd0k
18.09.2016 23:17-1Почему не включили Swift в первый эшелон? На нем уже можно писать server-side + есть компиляция под linux и android.
Source
18.09.2016 23:26Вы начало статьи прочитали? Swift уже в одной ногой в мейнстриме, а статья про языки, которые ещё только набирают обороты.
s1dd0k
18.09.2016 23:32Rust тоже выбивается на фоне остальных в таком случае. У него отрыв поплуряности сильно больше всех представленных.
Source
19.09.2016 01:42В комментах выше считали кол-во репозиториев на Github, у Rust — чуть больше 5 тыс.
У Swift — порядка 38 тыс. У Objective-C — около 150 тыс. Так что Rust если и выбивается из списка, то пока не сильно. А Swift заслуженно записан во второй эшелон.
creker
18.09.2016 23:29+1Можно не значит, что это кто-то делает. Swift в ближайшее время не выберется за пределы Apple. Хотя даже с учетом одной iOS его можно в мейнстрим вписать, все равно как-то по мне не очень он тянет, будучи все еще замкнутым в экосистеме Apple. Как и с Obj-C было. Он вроде популярен из-за айфонов, но всерьез его все равно не рассматривают в таких рейтингах.
s1dd0k
18.09.2016 23:31Obj-C слишком зависел от Foundation, именно поэтому он не вышел за пределы iOS. У Swift таких проблем нет.
yamatoko
19.09.2016 07:03от чем преимущества Котлина? В том, что он легкий и что-то в нем уже есть, чего еще нет в Джаве для андроида и что уже давно есть в Скале? что в нем нового и особенного?
xander27
19.09.2016 11:11Про vs java у них написано хорошо на сайте (да тот же nullsafe). По своему (небольшому) опыту vs scala:
- ниже порог вхождения
- меньше стандартная библиотека (по максимум используется стандартная библиотека java). Когда я пытался добавлять к проекту на java scala код, то везде сталкивался с тем что приходилось шаманить с типами данных (не сложно, но надоедает — как пример http://stackoverflow.com/questions/6356465/how-to-get-scala-list-from-java-list). В kotlin по идее такого нет
UbuRus
19.09.2016 09:56+2Новое например то, что с первой версии у него отличная поддержка IDE, для Scala IDE до сих пор тормозит.
Новое то, что много его абстракций «бесплатные» в рантайме: null типы, немутабльные коллекции, экстеншен функции, лямбды.
Котлин достиг скорости сборки такой же как у Java (реверанс в сторону Scala)
Для андроида у Котлина есть подаркок: малое количество методов в std, маленький вес std и Anko.
При полном интеропе с Java язык быстро развивается.
Наконец-то разработчики получили замену Java, а не скриптовый язык (Groovy) или вообще фп (Clojure, Frege, Scala).yamatoko
19.09.2016 10:13-1еще раз: что нового в самом Котлине?
зачем заменять java, когда есть java8?UbuRus
19.09.2016 10:23+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 разработчику.xaoc80
20.09.2016 13:41А Java 8 всё еще далек от современного языка, Котлин на голову выше, но всё еще прост и понятен любому Java разработчику
Я дико извиняюсь и не хочу показаться излишне консервативным, но все-таки, а что делает язык современным и чего такого нет в Java?)
grossws
19.09.2016 12:09Новое то, что много его абстракций «бесплатные» в рантайме: null типы, немутабльные коллекции, экстеншен функции, лямбды.
Большая часть перечисленного не бесплатные, в смысле не zero-cost, что обычно понимается под бесплатным в русскоязычном сегменте.
- Non-null генерируют проверки на null, которых в аналогичном java-коде может не быть вполне осознанно.
- Read-only коллекции (я б не стал называть их immutable, т. к. это несколько иное) — просто сахар над конструкторами (+ может быть, реализации в стандартной библиотеке).
- Вызовы extension methods (как и implicit classes в Scala) порождали объекты, хотя, возможно, они теперь делают инлайнинг, который тоже далеко не всегда полезен (с т. з. JIT'а).
UbuRus
19.09.2016 18:58+1Non-null не генерируют такие проверки повсеместно, а только когда идет интероп с Java кодом. На чистом Котлине их практически нету.
Read-only коллекции (справедливо) — это не сахар, это просто интерфейс, а реализация подкладывается JDK. Сейчас готовят именно immutable реализацию коллекций.
Вызовы extension методы не порождают обектов, это просто статические методы. Инлайн может сделать джит в этом случае.
Кстати про инлайн — возможность инлайнить лямбды по месту вызова это очень круто, особенно для тех кто вынужден сидеть на старых JDK.
potan
19.09.2016 15:27+1Kotlin — практичный язык для тех, кто привык с Java, но смог осознать ее недостатки.
Но что в нем «emergin»?
Остальные языки под этот эпитет подходят, хотя и не единственные в своей нише. Например Crystal конкурирует с Nim.
geekmetwice
20.09.2016 14:23-6Не хочу огорчать автора и переводчика, но язык в принципе не может быть перспективным, если о нём большинство аудитории слышит В ПЕРВЫЙ РАЗ.
Кроме того, следует сразу диагностировать «функциональщину головного мозга», прежде чем строить предположения. ФП — оно так же забавно и интересно, как и логическое п-е, но с практической точки зрения — это айтсайдер мэйнстрима. Как только описание языка начинается с фразы «это фун-ый язык п-я», можете сразу листать дальше — этот бред никогда не будет популярным.
С практической точки зрения, имеет смысл очень небольшой круг языков: прежде всего, это D как первоклассный преемник С++. Библиотеки — дело наживное, главное — у Ди великолепная, вылизанная база — писать на нём не просто удобно — ПРИЯТНО! Далее я бы поставил Nemerle, но ему нужно слегка отполировать синтаксис — не везде он удобен/очевиден. Зато не нужно писать библиотеки — весь .NET сразу в кармане. Конечно же, C# — через пень-колоду, но всё же развиваемый под крики и мольбы чайников :) В стане JVM, безусловно, Kotlin. Ну и всякие некритичные порносайтеги — я бы заюзал там Ruby, интересный язык и удобный для динамических приколов.
А вот и всё! Остальные языки как-то там движутся, но желания их касаться не вызывают. Особенно последние выскочки типа Go/Rust'ов.creker
20.09.2016 15:08+3язык в принципе не может быть перспективным, если о нём большинство аудитории слышит В ПЕРВЫЙ РАЗ.
прежде всего, это D как первоклассный преемник С++
Далее я бы поставил Nemerle
По вашей же логике, D и Nemerle не перспективны.
последние выскочки типа Go/Rust'ов.
По вашей же логике, они перспективны, потому что уже многие годы на слуху.geekmetwice
20.09.2016 23:25-4Если человек не слышал про Ди (зная про С++), обычно говорят «вон из профессии!». Но отдельный опрос не помешал бы — чисто поржать на местных «специалистов».
Nemerle — тут сложнее, тут надо вращаться в .NET, но дотнет — это как раз мэйнстрим и не услышать про Немерле — тоже как бы не красит программиста. Другими словами, язык может быть редкий/непопулярный, но в конкретной области про него обязательно должны были услышать. В моей (дотнет) ни про какие Эликсиры и Эльмы даже речи не шло — не представляю, о какой «перспективности» у них может идти речь. Даже у Смоллтока больше шансов!
Го/Раст — о них много трубят (спасибо гугле), но по сути это не игроки. Если вам техническое чутьё ничего не говорит, увы — убедить не смогу.
В любом случае, не понимаю ваш выпад — вы коммент зачем писали? Вы хотите меня убедить, что Эликсир и Эльм — что-то перспективное? Мне нужна ваша точка зрения, а не цепляние к словам.creker
21.09.2016 00:39+5Моя точка зрения — вы либо уныло вбрасываете, либо пишете ахинею на полном серьезе. Вот мое мнение. Хотя это даже не мнение, а больше фактическая характеристика. Опровергать каждый ваш тезис, который не имеет ничего общего с реальностью, у меня нет желания. Выбирайте, что вам больше подходит.
geekmetwice
21.09.2016 03:17-4Родной, мне не надо ничего выбирать, я уже давно для себя выбрал. Кому непонятны мои комменты, может СМЕЛО проходить МИМО — не для всех умов постижимо то, что вырабатывается годами.
DarkEld3r
20.09.2016 15:21+5Хоть и знаю, что ты тролль, но всё-таки смешно выглядят рассуждения из первого абзаца вместе с упоминанием Nemerle. Язык-то интересный, но боюсь, что в среднем о нём слышало меньше народу, чем о (практически) любом языке из этой статьи. И ещё смешнее то, что и Nemerle и D и Kotlin, о которых ты столь положительно отзываешься, не гнушаются "функциональщины".
iqiaqqivik
20.09.2016 17:55+2> с практической точки зрения — это айтсайдер мэйнстрима
Вы в телеком и вотсап напишите, а то пацаны мучаются и не в курсе, что они в аутсайдерах.
Source
20.09.2016 20:59+3Вы из какого года к нам прибыли? Я про Nemerle в прошлый раз слышал лет 8 назад. Влад и компания, конечно, молодцы и тогда этот проект выглядел весьма интересно. Но, имхо, после выхода C# 3.0 и включения F# в дефолтную поставку VS 2008 интерес к Nemerle стал стремительно затухать.
Про D я уже выше спрашивал, какой фактор сможет обеспечить рост популярности 15-летнему языку?geekmetwice
20.09.2016 22:10-6Узнаю любимый рунет — быдлятник в байтах. Из какого я могу быть года, если знаю про Ди и Немерле? В отличии от хабровской шпаны, я в ИТ более 20 лет, уж наверное знаю побольше похапастов с апломбом вроде вас.
Даже после выхода C# 7.0 Nemerle останется в фаворитах, ибо до его фич шарпу пилить и пилить. Но т.к. вы этого не знаете, похоже и дискутировать нет смысла — вышел, пукнул, слился. Зачем оно вам?
Ди — перспективен, причём тут какие-то 15 лет? Язык устоялся буквально год-два назад. Сейчас пилятся либы. И по фичам Ди затыкает С++ туда, куда только клизму вставляют.Source
20.09.2016 22:37+2То, что Вы об их существовании знаете, в этом ничего удивительного нет. А вот то, что Вы пропустили момент, когда о них говорили, как о перспективных (это было лет 8-10 назад) — это странно.
Язык устоялся буквально год-два назад.
Во, теперь понятно… привет из 2009 года.
быдлятник в байтах.
Это Вы видимо про себя. На вопросы по существу отвечать научитесь, потом понтоваться будете.
Vilyx
21.09.2016 00:43+1Быдло тут только одно и это вы, иначе вы бы не позволили себе такие высказывания.
О Nemerle впервые узнал под этой статьёй в комментариях, это при том, что о своём первом языке программирования я стал узнавать 12 лет назад это был С++. О Nemerle не говорят, он не на слуху. Этот язык может быть одной сплошной фичей, но если он не решает те проблемы, которые возникают у разработчиков, то он не нужен. Мне, как Unity3D разработчику, совсем не понятно, какую из моих задач Nemerle может решить лучше, чем C#.
После беглого знакомства с языком я понял только что при его использовании меня ждёт куча странного незнакомого синтаксиса, а польза крайне неочевидна.
Source
21.09.2016 02:17+3Справедливости ради, чтобы 1 неадекват не создавал негативное мнение о языке в целом, скажу, что Nemerle — весьма интересный язык с хорошим выводом типов, с полноценным pattern matching, макросами аля LISP и ещё кучей полезных фич. В общем по идеологии он гораздо ближе к функциональному программированию, но при этом синтаксис напоминает C#. Этакий гибрид C# и F# + нормальные макросы.
К сожалению, язык этот за 10 лет существования не взлетел, потому что
1) Пиар за пределами RSDN у него был практически на нуле
2) Для многих программистов хватило функциональных возможностей, которые встроили в C#. Ну а для тех, кому хотелось больше функциональщины под .NET, взлетел F#
Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.
P.S. На самом деле, даже странно почему популярность Nemerle настолько близка к нулю… Я ожидал, что ситуация получше. Но не видно ни одного активного OpenSource-проекта на этом языке, если не считать проектов того самого Влада.
DarkEld3r
21.09.2016 13:27+1Будет ли у Nemerle второй шанс? Зависит от JetBrains, именно на них работают основные мейнтейнеры языка.
Касательно того, где кто работает не в курсе, знаю только, что какое-то время работы велись за счёт JetBrains, а сейчас оно снова перешло в разряд "хобби проекта". Если кому интересны подробности, то они есть вот тут. Да и в JetBrains они больше занимались Nitra — этакий конструктор языков/DSL. Насколько знаю, были планы сделать N2 на нитре.
Source
21.09.2016 15:19Хм, значит всё-таки не будет… Единственный шанс — убедить MS в том, что им могут быть полезны эти наработки.
asdf87
22.09.2016 15:27У 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…DarkEld3r
22.09.2016 16:16Собственно, одна из фич нитры — это интеграция с IDE из коробки. Хотя мне тоже кажется, что момент упущен и уже не взлетит.
Source
22.09.2016 18:37+1К тому же к Nemerle будет сложно в разумные сроки прикрутить поддержу IDE
Интеграция с VisualStudio у Nemerle вполне приличная ещё со времён VS 2008. Так что проблема явно не в этом.
Вообще .NET CLR — весьма авторитарная среда, по сравнению с тем же JVM. Я не знаю ни одного языка, который бы взлетел для неё кроме тех, чью разработку активно курирует Microsoft. Даже из тех разработок, которые они поддерживали, типа IronPython, IronRuby и прочие Iron*, ни одна не взлетела.
zhaparoff
20.09.2016 16:20некоторые из ведущих языков возможно увядают
Я бы не стал слишком доверять статье, которая в основу своего анализа берет статистику продаж книг по разным языкам всего лишь одного из (пусть и весьма известных) книжных издательств.
В данном случае корреляция ничтожна.
Вышла новая версия языка — выпустили новую книгу — все ломанулись покупать — ура, язык то крут!
Нет новых версий, все стабильно — книг не выпускают, не покупают — все, язык загибается!
Изучение языка простое и не требует спец литературы (ну или просто создатели постарались, и выложили крутую документацию, которая заменяет большую часть книг) — почитал в онлайне и вперед, фигачить в продакшен — все, продаж книг нет, язык загибается!
Ну и например, некоторые разработчики языков/платформ имеют свои издания, что знает О'Рейли об их популярности?
stargazr
20.09.2016 17:18Очень странно видеть Golang и Swift в компании Haskell и Clojure.
Особенно учитывая, что, по мнению автора оригинальной статьи, это языки «второго эшелона» (Swift, ага).
Интересно, куда бы автор отнес Haxe — к полудохлой маргинальщине, мейнстриму, «второму эшелону» или «перспективным языкам» (как по мне, так это та же маргинальщина).
VBauer
24.09.2016 07:45Ток от создателей, интересно слышать их позицию и прогнозы, и насколько все оправдалось теперь.
LangNext 2014 (C++, Rust, D, Go)
plotnick
24.09.2016 11:29Я бы перспективным назвал Clojurescript. Я пробовал многие разные языки транспилирующие в JS, настоящее удовольствие я стал получать от работы именно с него.
qrck13
Языки то конечно может перспективные. Но им далеко до повседневного использования. А «увядающие .NET/C#» еще много кого переживут.
P.S. Говорю как постоянный пользователь как C#, так и например Kotlin
Source
Я согласен, что позиции C# прочны. Впрочем, MS не зря зашевелилась в сторону кроссплатформенности. Разработка приложений чисто под Windows сейчас уже далеко не так популярна, как лет 10 назад.
Nagg
Самый популярный геймдев инструмент? Unity. На каком языке там пишут? :) Ну и по сути C# один из немногих не низкоуровневых языков, который позволяет (и имеет хороший тулинг) писать под всё и везде: back-end, десктопные нативные приложения под Windows, macOS, Linux. Нативные приложения под Android, iOS (с поддержкой любых нативных 3rd party), приставки и даже микроконтроллеры :-). В свежем отчете гитхаба C# за год в популярности подрос в два раза. В общем, я бы не назвал его увядающим.
Source
Что ж Вы так резко реагируете то? Статья ведь вообще не об этом… Я, честно говоря, статью про увядающие языки вообще только после комментария прочитал )))
И хоть я бы лично не назвал C# увядающим, но с аргументами из той статьи тоже можно согласиться… Рынок веб- и mobile-приложений MS, мягко говоря, упустила из-за своей же близорукости. Никто им не мешал поддержать Mono ещё во времена .NET 2.0. И то, что они этого не сделали, по масштабности просчёта аналогично отказу от продолжения разработки браузера после победы над Netscape. Теперь приходится в спешке догонять конкурентов в упущенных нишах.
alex_zzzz
Инструмент, а не язык. Да и среди языков уже трудно сказать, кто на данный момент популярнее в геймдеве. На каждый один ААА-проект на PC и консолях, написанный на С++ с примесями Питона и Lua, приходится сотня небольших проектов на тех же PC и консолях и тысяча на мобилках. А они уже написанны на чём угодно, чаще всего на C# в Unity. И чем дальше, тем больше.
Microsoft, конечно, много лет тормозил, но спасибо, что не мешал. На рынке mobile-приложений, приносящих деньги (= игр), C# справился без Microsoft.
Source
А вообще да, о количестве игр под мобилки я как-то не подумал, вот что значит наиграться в компьютерные игры ещё до появления смартфонов )))
TheShock
Ну сейчас и под комп пишут на Юнити. Тот же прекрасный KSP
thousandsofthem
Например пользуюсь активно elixir, для новых проектов отличный вариант. Crystal — в глубокой альфе, его действительно не скоро можно будет по настоящему использовать. Kotlin — слышу об отдельных командах что на него переходят (как правило смесь старого кода на java + новый на котлин)
Source
В принципе логично, что до выхода версии 1.0 язык не может активно использоваться в production.
Поэтому в повседневном использовании можно найти Rust, Elixir и Kotlin. А Crystal (0.19) и Elm (0.17) пока только для early birds. Хотя их версии уже намекают о близости RC, думаю, очень высока вероятность, что в 2017 году они выйдут в стабильной версии.
UbuRus
Котлин как раз таки повседневно используется. Сильно взлетел в мире андроид. А еще начали пилить Kotlin Native.
qrck13
Kotlin Native — это на сколько я знаю, только слухи, ничем не подтвержденные, и даже вроде как опровергнутые JetBrains, не?
P.S. Сам использую Kotlin для своего opensource проекта, язык да, прикольный. Но время компиляции помноженное на тормоза gradle — это конечно ад :)
UbuRus
Уже подтвердили, Дмитрий Жемеров в одном из последних выступлений.
Какие тормоза? По сравнению с Java не ощущаю никакой разницы, тесты это в общем-то подтверждают: https://kotlin.link/articles/Kotlin-vs-Java-Compilation-speed.html
qrck13
Kotlin vs Java — это возможно да. Но я, по правде говоря, сравниваю с C#, которым пользуюсь на работе как одним из основных языков (плюс C++ — процентов 25 кода). И вот если сравнивать с шарповыми проектами, Kotlin / Android Studio — это просто такой тормоз :( Нажимаешь «Run», уходишь делать чай, возвращаешся, оно только делает «installing apk...»
UbuRus
Сравнивать нужно одинаковые вещи, компиляция и запуск веб-приложения на Котлин занимает на моем ульрабуке 4-7 секунд. Сборка и деплой на замарине скорее всего не отличается по скорости от Java/Kotlin, потому что львиная доля этого времени — старт эмулятора.
В общем начить спорить на тему Kotlin (+ Java Platform естенствено) vs С# не вижу смысла.
Ghedeon
Разделяю ваш справедливый гнев по поводу тормознутости сборки под андроид, но время компиляции медленное, безотносительно к котлину. Java + gradle будет так же медленно, как и kotlin + gradle. Из этого сравнения видно, что те же яйца только в профиль.
alz72
по моему на сегодняшний момент C# конкурентов нет, а учитывая что он все более становиться мультиплатформенным — есть все шансы что он обгонит и Java, и C++
Source
Конкуренты есть у всех. К тому же у массовости есть и обратная сторона: средний уровень сообщества падает от массового притока новичков в программировании. Что, по факту, имеет ряд негативных последствий для профессиональных программистов, начиная от необходимости учить/руководить чуть ли не чаще, чем программировать, и заканчивая замедлением темпов индексации зарплат.
alz72
Ну средний уровень сообщества не всегда отражается на среднем уровне программистов в конкретном месте, так что корреляции между ним и необходимостью учить/руководить может и не быть.