Вас послушать, так до сих пор все программировали бы исключительно на Fortran, Lisp и Algol, ну и изредка на Smalltalk, Simula и Forth.
Но почему то из этих шести на плаву только Lisp и Smalltalk, и то работу на них найти ещё сложнее, чем на Elm или Rust.
Ну и в целом, работа — это же не главная мотивация в программировании, что-то можно изучать из любви к искусству, а не только в корыстных интересах ;-)
И что с того? Языки, которым больше 10 лет, уже заняли свои ниши и особо никуда не двигаются. Ada и Pascal очень медленно сползают вниз, а Smalltalk начал шевелиться с появлением Pharo, но тоже с туманными пока перспективами, т.к. момент был упущен лет 15 назад.
Для Kotlin, Elixir, Elm и Rust есть плагины под IntelliJ IDEA, которые работают в том числе и с бесплатной Community Edition.
Также есть плагины под популярные редакторы: Sublime, Atom, VS Code. Ну и само собой под Emacs и Vim. Это уже и к Crystal относится, вот по нему инфа.
Хоть формулировки у Кристиана Нельсона и странные местами, я не вижу в них чего-то криминального и показывающего, что он не знаком с предметом.
Прирост производительности очевидно имеется в виду по сравнению с Ruby :-)
То, что Phoenix работает поверх Cowboy — это факт, но это совсем другой уровень абстракции.
Если завтра выйдет версия Phoenix, работающая поверх другого веб-сервера, Вы очень долго не заметите что что-то поменялось.
Понимаете, D уже сложно назвать молодым и перспективным… Всё-таки языки, которым больше 10 лет, уже заняли свои ниши и вероятность их бурного роста или падения не высока. Должен быть какой-то мощный фактор.
Для примера, появление Rails было фактором роста для Ruby (которому на тот момент было около 10 лет). С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.) потеряли рынок, потому что их пытались продолжать продавать.
Каков же фактор для D, которому 15 лет в этом году исполнилось?
В принципе логично, что до выхода версии 1.0 язык не может активно использоваться в production.
Поэтому в повседневном использовании можно найти Rust, Elixir и Kotlin. А Crystal (0.19) и Elm (0.17) пока только для early birds. Хотя их версии уже намекают о близости RC, думаю, очень высока вероятность, что в 2017 году они выйдут в стабильной версии.
Что ж Вы так резко реагируете то? Статья ведь вообще не об этом… Я, честно говоря, статью про увядающие языки вообще только после комментария прочитал )))
И хоть я бы лично не назвал C# увядающим, но с аргументами из той статьи тоже можно согласиться… Рынок веб- и mobile-приложений MS, мягко говоря, упустила из-за своей же близорукости. Никто им не мешал поддержать Mono ещё во времена .NET 2.0. И то, что они этого не сделали, по масштабности просчёта аналогично отказу от продолжения разработки браузера после победы над Netscape. Теперь приходится в спешке догонять конкурентов в упущенных нишах.
Так же, я считаю, что в этом случае должна быть какая-то опция, чтобы можно было контролировать уровень ошибки для такого кода: игнорить, ворнинг, эррор, со значением «ворнинг» по-умолчанию.
Я согласен, что позиции C# прочны. Впрочем, MS не зря зашевелилась в сторону кроссплатформенности. Разработка приложений чисто под Windows сейчас уже далеко не так популярна, как лет 10 назад.
Но как видим, только небольшая прослойка ценителей ФП осторожно работают с ним или со Scala.
Мне кажется, что тут дело в том, что большинство ценителей ФП на дух не переносят Java, включая JVM.
Это на самом деле странная была затея создать функциональный язык поверх императивной виртуальной машины, которая даже оптимизацию хвостовой рекурсии не поддерживает. Мало нам что-ли императивной процессорной архитектуры?
Но, как мне показалось, это то как на пхп писали еще лет 10 назад.
Нет, я 10 лет назад активно писал на PHP, и могу точно сказать, что ничего общего. Возможно, Вы не до конца поняли суть идеи…
Во-первых эти библиотеки не являются фреймворками, наоборот фреймворки (именно во множественном числе, т.е. это своеобразная спецификация, которую уважающий себя фреймворк обязан поддерживать) строятся поверх них.
Во-вторых, благодаря унификации обработчиков из их можно составлять цепочки произвольной длины, начиная с middlewares и заканчивая внутренними механизмами фреймворков. Кроме того, однажды написанную middleware можно опубликовать и люди смогут использовать её практически с любым веб-фреймворком в рамках данного ЯП, потому что никто из создателей фреймворков не стремится изобрести велосипед.
https://laravel.com/docs/5.3/routing
Прочитал… И какое-то смешанное ощущение, то ли документашка очень куцая, то ли роутинг в Laravel находится пока ещё в зачаточном состоянии. Во всяком случае описано мало возможностей и самое главное непонятно в чём профит от возможности возвращать разнородные данные из routing callbacks и как эти данные преобразуются в HTTP-ответ?
И? Вы не считаете такую архитектуру извращением?
Пока весь остальной мир идёт по пути унификации обработки веб-запросов (см. WSGI, Rack, Clack, Plug, WAI, etc.), Вы предлагаете из роутера передавать управление к разнородным функциям, которые хз что возвращают?
Ну, ok… ¯\_(ツ)_/¯
Просто у меня дух противоречия бурлит, и не нравится идея таскания большого рантайма вслед за крохотным приложением.
Так в том то и дело, что ни .NET, ни JVM не таскают большой рантайм за крохотных приложением. Рантайм ставится системно, а не в рамках приложения. Сравните, например, с Electron-based приложениями, вот там действительно рантайм засунут в приложения. И если Вам нужно 5 приложений на Electron, то Вы 5 раз вынуждены будете скачать рантайм и иметь в системе 5 его копий.
А как же Вы, простите, собираетесь Windows Update без интернета организовать?
А причём тут это? .NET можно и напрямую поставить…
P.S. Вас кто-то из программистов, использующих .NET, обидел что-ли?
Разъёмы залиты, ethernet-доступа нет, интернета нет… Ну достаньте HDD из этого несчастного компа, подключите его к нормальному и скопируйте туда эти 67 Mb (именно столько занимает инсталлятор .NET 4.5.2) xD
Но почему то из этих шести на плаву только Lisp и Smalltalk, и то работу на них найти ещё сложнее, чем на Elm или Rust.
Ну и в целом, работа — это же не главная мотивация в программировании, что-то можно изучать из любви к искусству, а не только в корыстных интересах ;-)
Также есть плагины под популярные редакторы: Sublime, Atom, VS Code. Ну и само собой под Emacs и Vim. Это уже и к Crystal относится, вот по нему инфа.
Прирост производительности очевидно имеется в виду по сравнению с Ruby :-)
То, что Phoenix работает поверх Cowboy — это факт, но это совсем другой уровень абстракции.
Если завтра выйдет версия Phoenix, работающая поверх другого веб-сервера, Вы очень долго не заметите что что-то поменялось.
Для примера, появление Rails было фактором роста для Ruby (которому на тот момент было около 10 лет). С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.) потеряли рынок, потому что их пытались продолжать продавать.
Каков же фактор для D, которому 15 лет в этом году исполнилось?
Поэтому в повседневном использовании можно найти Rust, Elixir и Kotlin. А Crystal (0.19) и Elm (0.17) пока только для early birds. Хотя их версии уже намекают о близости RC, думаю, очень высока вероятность, что в 2017 году они выйдут в стабильной версии.
Что ж Вы так резко реагируете то? Статья ведь вообще не об этом… Я, честно говоря, статью про увядающие языки вообще только после комментария прочитал )))
И хоть я бы лично не назвал C# увядающим, но с аргументами из той статьи тоже можно согласиться… Рынок веб- и mobile-приложений MS, мягко говоря, упустила из-за своей же близорукости. Никто им не мешал поддержать Mono ещё во времена .NET 2.0. И то, что они этого не сделали, по масштабности просчёта аналогично отказу от продолжения разработки браузера после победы над Netscape. Теперь приходится в спешке догонять конкурентов в упущенных нишах.
Это на самом деле странная была затея создать функциональный язык поверх императивной виртуальной машины, которая даже оптимизацию хвостовой рекурсии не поддерживает. Мало нам что-ли императивной процессорной архитектуры?
Нет, я 10 лет назад активно писал на PHP, и могу точно сказать, что ничего общего. Возможно, Вы не до конца поняли суть идеи…
Во-первых эти библиотеки не являются фреймворками, наоборот фреймворки (именно во множественном числе, т.е. это своеобразная спецификация, которую уважающий себя фреймворк обязан поддерживать) строятся поверх них.
Во-вторых, благодаря унификации обработчиков из их можно составлять цепочки произвольной длины, начиная с middlewares и заканчивая внутренними механизмами фреймворков. Кроме того, однажды написанную middleware можно опубликовать и люди смогут использовать её практически с любым веб-фреймворком в рамках данного ЯП, потому что никто из создателей фреймворков не стремится изобрести велосипед.
Прочитал… И какое-то смешанное ощущение, то ли документашка очень куцая, то ли роутинг в Laravel находится пока ещё в зачаточном состоянии. Во всяком случае описано мало возможностей и самое главное непонятно в чём профит от возможности возвращать разнородные данные из routing callbacks и как эти данные преобразуются в HTTP-ответ?
Пока весь остальной мир идёт по пути унификации обработки веб-запросов (см. WSGI, Rack, Clack, Plug, WAI, etc.), Вы предлагаете из роутера передавать управление к разнородным функциям, которые хз что возвращают?
Ну, ok… ¯\_(ツ)_/¯
P.S. Вас кто-то из программистов, использующих .NET, обидел что-ли?
Разъёмы залиты, ethernet-доступа нет, интернета нет… Ну достаньте HDD из этого несчастного компа, подключите его к нормальному и скопируйте туда эти 67 Mb (именно столько занимает инсталлятор .NET 4.5.2) xD