Комментарии 47
Вы как-то о своем опыте умолчали. Какие из перечисленных языков у вас работают в проде и насколько вы ими довольны?
Периодически стараемся рассказывать, например, Как выбрать язык программирования. Ну и Tarantool никто не отменял.
> Rust продолжает стремительно меняться. Отставание в обучающих материалах на несколько месяцев может поставить ваши знания под угрозу.
После выхода 1.0 это уже совсем не так актуально. Собственно, большинство статей, написанных после середины 2015ого, вполне себе актуальны и полезны.
После выхода 1.0 это уже совсем не так актуально. Собственно, большинство статей, написанных после середины 2015ого, вполне себе актуальны и полезны.
Никто не обратил внимание что на первой картинке все книги на иврите, или mail.ru как бы намекает? :)
А как же Kotlin?
С Kotlin всё гораздо проще, по нему полторы книги всего есть:
Kotlin for Android Developers
Kotlin in Action (не только in Action, но и in Progress)
Kotlin for Android Developers
Kotlin in Action (не только in Action, но и in Progress)
Если это не реклама книжек, то все очень поверхностно, а посему полемично. Самое основное — нет ни слова о целевой задаче и платформе для каждого языка.
Swift, благодаря политике Apple, никогда не вылезет из экосистемы iOS.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Lua — вы серьезно?
Go — в последнее время сильно пиарится Корпорацией Добра. Пытается отъесть кусок у системных сервисов, где царствуют Python и C/C++. Язык очень посредственный, но простой и работает.
Rust — да, интересный язык. И что дальше?
Что действительно перспективно:
Java останется еще очень долгое время столпом программирования: кровавый энтерпрайз, экосистема и все такое.
C/C++ как платформенные языки, тоже никуда не денутся.
ECMAScript/Dart/Typescript — никто не знает чем закончится конкуренция и что будет следующим стандартом де-факто для вебплатформы. Но ясно одно — это одна из самых востребованных областей в ближайшем будущем.
Swift, благодаря политике Apple, никогда не вылезет из экосистемы iOS.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Lua — вы серьезно?
Go — в последнее время сильно пиарится Корпорацией Добра. Пытается отъесть кусок у системных сервисов, где царствуют Python и C/C++. Язык очень посредственный, но простой и работает.
Rust — да, интересный язык. И что дальше?
Что действительно перспективно:
Java останется еще очень долгое время столпом программирования: кровавый энтерпрайз, экосистема и все такое.
C/C++ как платформенные языки, тоже никуда не денутся.
ECMAScript/Dart/Typescript — никто не знает чем закончится конкуренция и что будет следующим стандартом де-факто для вебплатформы. Но ясно одно — это одна из самых востребованных областей в ближайшем будущем.
Ну не знаю даже, пока конечно на Линуксе swift неудобно юзать, нехватает биндингов, да и import Glibc vs import Darwin тоже много радости доставляет. Но это всё не фундаментальные проблемы.
Низкоуровневые и платформозависимые библиотеки обязательно напишутся и сложатся в экосистему.
Вот кого забыли, так это Kotlin.
Низкоуровневые и платформозависимые библиотеки обязательно напишутся и сложатся в экосистему.
Вот кого забыли, так это Kotlin.
Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Не обязательно, Java тоже продвигалась теми кому стал тесен C++, в принципе Scala или Kotlin могут со временем заменить Java по принципу та же Java, только лучше. Я бы поставил на Kotlin, ИМХО.
Мне очень нравится Kotlin и я желаю ему всего самого наилучшего. Но простой вопрос: что можно (будет) делать на Kotlin? Создатели утверждают: «то же самое, что и на Java (и также как на Java), только чуток лучше». Кроме того, по их словам, у Котлина не будет своего стека технологий, и что он всецело будет полагаться на джавовский (который в свою очередь далеко не идеален: либо кровавый энтерпрайз, либо спрингоподобные костыли). А раз так, то у людей возникает два вопроса: «стоит ли рисковать и подсаживать проект на Котлин?», и «а почему тогда не на Scala», которая уже имеет сформировавшийся стек?
Общая мысль такая, что язык сам по себе не несет большого смысла. Его можно рассматривать только вкупе: язык + целевые задачи + экосистема.
Общая мысль такая, что язык сам по себе не несет большого смысла. Его можно рассматривать только вкупе: язык + целевые задачи + экосистема.
По поводу ECMAScript/Dart/Typescript, WebAssembly разве не позволяет избавиться от самой идеи стандарта де-факто, которым сейчас является JavaScript?
А что несерьезного с Lua? У Lua своя ниша, где он вне конкуренции — как встроенный язык для скриптинга/автоматизации в различных движках. Вот только работают с ним чаще всего не профессиональные программисты, а администраторы или даже конечные пользователи.
ECMAScript/Dart/Typescript — никто не знает чем закончится конкуренция и что будет следующим стандартом де-факто для вебплатформы.
Вы серьёзно?
> Scala — продвигается в основном теми, кому стала тесна Java, а посему всегда будет вторична к ней.
Пока что на практике Java как язык вторична по отношению к Scala. Лямбды, REPL, теперь вот автовывод типов предлагают… Ждем когда они у себя «изобретут» кейс-классы и паттерн-матчинг.
Пока что на практике Java как язык вторична по отношению к Scala. Лямбды, REPL, теперь вот автовывод типов предлагают… Ждем когда они у себя «изобретут» кейс-классы и паттерн-матчинг.
Java скорей ориентируется на C#, нежели на скалу. Скала может и имеет некоторые специфичные решения и области применения, но вцелом она все еще полагается на экосистему Java. Самостоятельнось скалы под вопросом.
> Java скорей ориентируется на C#, нежели на скалу.
Сомневаюсь, что они ориентируются строго на С#, скорее на некий усредненный запрос от программистов, которому C# в том числе старается соответствовать. И кстати, если посмотреть на некоторые последние фичи C#: self-hosted компилятор, строковая интерполяция, вложенные функции, туплы, паттерн-матчинг… хм… в Scala, например, это все уже есть. Так что, опять же, все указывает на то, что не скала вторична, а как раз-таки наоброт.
> Скала может и имеет некоторые специфичные решения и области применения
Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит. А вот примеров Java-проектов, в которых нельзя было бы взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
> но вцелом она все еще полагается на экосистему Java. Самостоятельнось скалы под вопросом.
Нет, в целом Scala уже довольно давно не полагается на экосистему Java (если не считать JVM). Более того, на мой взгляд Scala как никакой другой JVM-язык (кроме Java) вносит вклад в экосистему Java. Затрудняюсь назвать какие-либо Groovy-, Clojure- или Kotlin-фреймворки, которые использовались бы джавистами так же активно, как Spark, Play или Akka.
Сомневаюсь, что они ориентируются строго на С#, скорее на некий усредненный запрос от программистов, которому C# в том числе старается соответствовать. И кстати, если посмотреть на некоторые последние фичи C#: self-hosted компилятор, строковая интерполяция, вложенные функции, туплы, паттерн-матчинг… хм… в Scala, например, это все уже есть. Так что, опять же, все указывает на то, что не скала вторична, а как раз-таки наоброт.
> Скала может и имеет некоторые специфичные решения и области применения
Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит. А вот примеров Java-проектов, в которых нельзя было бы взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
> но вцелом она все еще полагается на экосистему Java. Самостоятельнось скалы под вопросом.
Нет, в целом Scala уже довольно давно не полагается на экосистему Java (если не считать JVM). Более того, на мой взгляд Scala как никакой другой JVM-язык (кроме Java) вносит вклад в экосистему Java. Затрудняюсь назвать какие-либо Groovy-, Clojure- или Kotlin-фреймворки, которые использовались бы джавистами так же активно, как Spark, Play или Akka.
Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит. А вот примеров Java-проектов, в которых нельзя было бы взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.Разве что приходит в голову, что скала в некоторых случаях не подходит для написания высокопроизводительных библиотек, часто написанных в fortran-стиле либо с использованием сильных предположений о поведении компилятора и JIT'а. В качестве примеров приведу Lucene и Disruptor. Но это довольно редкие кейсы.
Ещё одно замечание, что скала требует большей дисциплины (и более аккуратной проработки стандартов кодирования), поэтому может несколько хуже подходить для open-source проектов с распределённым ядром комитеров.
> self-hosted компилятор, строковая интерполяция, вложенные функции, туплы, паттерн-матчинг…
Большинство из модных фич упрощают написание кода, но далеко не всегда упрощают разработку (включая тестирование, отладку, поддержку кода). Все новые и необычные фичи очень лениво и эпизодически используются девелоперами. Это делает их наличие в языке рудиментарным. Особенно когда есть более привычный стандартный подход к решению.
> Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит.
То есть Вы хотите сказать, что существуют некоторые задачи общего назначения, которые можно решить на Scala и нельзя на Java? Навскидку (только не плагин для sbt)?
> взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
Почему-то все мыслят продуктивность исключительно в контесте написания кода: мой код короче, я пишу быстрее, поэтому я продуктивнее. Если взять качество кода, читабельность, простоту, сопровождение, тулинг, и совместную разработку, то все профиты резко уйдут в минус.
> Spark, Play или Akka.
Священная троица TypeSafe. Play и Akka изначально были написаны на Java и к Scala вообще не имели никакого отношения. Интерес к Play резко упал после того как к нему прилепили скалу и выпустили несовместимую ветку 2.x. Огромное количество тех, кто использует Play, до сих пор сидят на ветке 1.x и отказываются переходить, ибо разработка на 1.x в разы продуктивней, хоть и на Java. Spark ессно имеет API на Java. А вот чисто скаловский фреймворк — это Lift. Ну и много на нем пишут?
> Затрудняюсь назвать какие-либо Groovy
Gradle, например.
Большинство из модных фич упрощают написание кода, но далеко не всегда упрощают разработку (включая тестирование, отладку, поддержку кода). Все новые и необычные фичи очень лениво и эпизодически используются девелоперами. Это делает их наличие в языке рудиментарным. Особенно когда есть более привычный стандартный подход к решению.
> Есть области применения, где вопрос Scala vs Java не стоит, т.к. Java просто не подходит.
То есть Вы хотите сказать, что существуют некоторые задачи общего назначения, которые можно решить на Scala и нельзя на Java? Навскидку (только не плагин для sbt)?
> взять Scala вместо/вместе с Java и получить бенефитов в виде возросшей продуктивности, мне в голову не приходит.
Почему-то все мыслят продуктивность исключительно в контесте написания кода: мой код короче, я пишу быстрее, поэтому я продуктивнее. Если взять качество кода, читабельность, простоту, сопровождение, тулинг, и совместную разработку, то все профиты резко уйдут в минус.
> Spark, Play или Akka.
Священная троица TypeSafe. Play и Akka изначально были написаны на Java и к Scala вообще не имели никакого отношения. Интерес к Play резко упал после того как к нему прилепили скалу и выпустили несовместимую ветку 2.x. Огромное количество тех, кто использует Play, до сих пор сидят на ветке 1.x и отказываются переходить, ибо разработка на 1.x в разы продуктивней, хоть и на Java. Spark ессно имеет API на Java. А вот чисто скаловский фреймворк — это Lift. Ну и много на нем пишут?
> Затрудняюсь назвать какие-либо Groovy
Gradle, например.
А я вот для себя на днях открыл отличную книгу по Erlang:
Томпсон С., Черазини Ф.
Программирование в Erlang/Пер. с англ. Холомьёва А.О. — М.: ДМК Пресс, 2012. — 488с.
Томпсон С., Черазини Ф.
Программирование в Erlang/Пер. с англ. Холомьёва А.О. — М.: ДМК Пресс, 2012. — 488с.
Shameless plug: про Rust читать перевод официальной книги на русский, перевод книги о макросах, перевод Растономикона (в процессе работы; содержание не переведено, но примерно половина глав уже на русском).
Интересно бы такой же обзорчик по перспективным IT-технологиям вообще, а не только по языкам программирования...
По-моему с перспективами Scala и Lua давно уже всё понятно.
А вот почему забыли про Elixir и Nim непонятно...
А вот почему забыли про Elixir и Nim непонятно...
Source, напишите свой пост про Elixir и Nim. Мы почитаем.
Читать, конечно, можно разное, но я очень слабо представляю себе путь "выучил Lua -> нашел фултайм работу на Lua". И это справедливо для большей части указанного списка языков. Примеры с модулями на Go и Scala, которые используются в твиттере и ВК ни о чём не говорят, поскольку там их, очевидно, писали профи уровня изрядно выше среднего, которые и на С++\Java\C# написали бы их не хуже.
Роб Пайко — уже почти наш чувак! =) Роб Пайк, поправьте пжлст =)
А статья весьма информативная! Большое Спасибо!
А статья весьма информативная! Большое Спасибо!
Не верю ни в один из этих языков.
Он [Lua] получил известность как язык программирования многих игр (в том числе и World of Warcraft), однако может применяться не только для игр, но и там, где требуется использование данных, хранящихся в других файлах.
Писал на Lua плагин для Wireshark + встраивал в один проектик в одной конторке.
Язык замечательный — очень удобный для своих задач!
И встраивается легко! (по крайней мере в связке C# + Lua)
На уровне 3+ учиться чуть дольше Python'а.
Меня в lua вечно раздражало использование исключительно float'ов, но сейчас ещё добавили integer-представление для number.
Почему раздражало?
Использование на камнях без fpu — боль, сравнение float'ов — боль (и потенциальное место для ошибок); и иногда очень не хватало простых человеческих битовых операций, но их можно вынести в мини-библиотеку.
> Использование на камнях без fpu — боль
Хм, для такой, как по мне, экзотики можно было собрать с переопределением `lua_number` в `int`.
> сравнение float'ов — боль
Хм, ну если в формулах не использовать дроби, то и сравнение как для целых работало. Я вот не уверен, что от скриптов стоит требовать большего.
> иногда очень не хватало простых человеческих битовых операций
Тут соглашусь, но не уверен, что луа вообще хороший вариант языка для активной возни с битами.
> их можно вынести в мини-библиотеку
Еще у luajit было нечто приличное — http://bitop.luajit.org — но это, конечно, не стандартный интерпретатор и не везде заработает.
В общем, мне наоборот один тип для чисел казался как раз ближе к минималистичному духу lua (где даже массивы и хэши в одну сущность слепили) и всегда думалось, что для скриптов этого вполне достаточно.
Хм, для такой, как по мне, экзотики можно было собрать с переопределением `lua_number` в `int`.
> сравнение float'ов — боль
Хм, ну если в формулах не использовать дроби, то и сравнение как для целых работало. Я вот не уверен, что от скриптов стоит требовать большего.
> иногда очень не хватало простых человеческих битовых операций
Тут соглашусь, но не уверен, что луа вообще хороший вариант языка для активной возни с битами.
> их можно вынести в мини-библиотеку
Еще у luajit было нечто приличное — http://bitop.luajit.org — но это, конечно, не стандартный интерпретатор и не везде заработает.
В общем, мне наоборот один тип для чисел казался как раз ближе к минималистичному духу lua (где даже массивы и хэши в одну сущность слепили) и всегда думалось, что для скриптов этого вполне достаточно.
> и потенциальное место для ошибок
Кстати, хотя целые числа в 5.3 добавили, приведение одного к другому неявное, так что от ошибок это, вроде как, должно спасать ровно на столько же, насколько и просто использование целого подмножества float`ов.
Кстати, хотя целые числа в 5.3 добавили, приведение одного к другому неявное, так что от ошибок это, вроде как, должно спасать ровно на столько же, насколько и просто использование целого подмножества float`ов.
Кейс, когда меня это зацепило — использование lua, как встроенного языка для микроконтроллера. Соответственно, я не имел возможности:
Библиотека с битовыми операциями там естественно была, но не зная её реализации сложно сказать, что выдаст
Мне lua, как встраиваемый язык вполне импонирует, встраивается очень удобно, простой. Но в некоторых вариантах использования он смотрится не так хорошо.
- пересобрать lua (а если бы и имел — float для других вещей там всё равно был нужен, т. к. измерения с датчиков обычно нецелые);
- подсунуть стороннюю библиотеку.
Библиотека с битовыми операциями там естественно была, но не зная её реализации сложно сказать, что выдаст
a=1; b=2; bit.xor(a, b): 3, как ожидаешь, или что-нибудь типа (float)((*((int*)(&a))) ^ (*((int*)(&b)))). И что будет, если операнды для битовых операций должны были быть 32-битными числами, которые в точности не влезают в мантиссу float32.Мне lua, как встраиваемый язык вполне импонирует, встраивается очень удобно, простой. Но в некоторых вариантах использования он смотрится не так хорошо.
Кейс, когда меня это зацепило — использование lua, как встроенного языка для микроконтроллера
Очень интересно!
А можно немного поподробнее!
(или это гостайна?)
Мне lua, как встраиваемый язык вполне импонирует, встраивается очень удобно, простой. Но в некоторых вариантах использования он смотрится не так хорошо.
Основной упор Lua, как я понимаю, это очень легкая, быстрая и надежная встраиваимость.
А на счет недостадков — то, разумеется, они есть.
Не гт. Контроллер, который я имею ввиду, делается совместно российской и немецкой компаниями. С российской стороны это Эвика.
По назначению — всякий умный дом, домашняя автоматизация. Я использовал для реализации WebSCADA для пары простых промышленных вентустановок, но пришлось несколько помучиться.
В принципе, на контроллере linux, веб-интерфейс и для пользователя, и для разработчика. Вся конфигурация лежит в sqlite, есть набор библиотек, доступных из lua, которые являются обёртками над сишными библиотеками + плюс библиотека для взаимодействия с коммуникационным ядром контроллера (который может выступать в качестве шлюза) и простой userstorage, через который можно обмениваться данными между разными скриптами.
Скрипты могут запускаться по таймеру, по событию и т. п. В последнем случае в системной таблице доступен объект, описывающий событие.
Неудобство с битовыми операциями присутствует в случае, если надо распаковывать, скажем, 32-битное слово, где каждый бит означает определенную ошибку.
По назначению — всякий умный дом, домашняя автоматизация. Я использовал для реализации WebSCADA для пары простых промышленных вентустановок, но пришлось несколько помучиться.
В принципе, на контроллере linux, веб-интерфейс и для пользователя, и для разработчика. Вся конфигурация лежит в sqlite, есть набор библиотек, доступных из lua, которые являются обёртками над сишными библиотеками + плюс библиотека для взаимодействия с коммуникационным ядром контроллера (который может выступать в качестве шлюза) и простой userstorage, через который можно обмениваться данными между разными скриптами.
Скрипты могут запускаться по таймеру, по событию и т. п. В последнем случае в системной таблице доступен объект, описывающий событие.
Неудобство с битовыми операциями присутствует в случае, если надо распаковывать, скажем, 32-битное слово, где каждый бит означает определенную ошибку.
Ну и кто из этих новичков и почему вдруг должен заменить джаваскрипт?
Жаль, что PACKT не осуществляет доставку на физические адреса в Россию. Я бы купил у них пару книжек.
Интересно кто в итоге останется в живых из этого Зоопарка
По scala именно для ознакомления, как мне кажется, намного лучше подходит Scala для нетерпеливых Хорстмана (Scala for impatient, Cay S. Horstmann). По объему она в 2 раза меньше Programming in Scala и местами поверхностна, но дает хороший обзор основных возможностей языка, легко читается и на удивление неплохо переведена (не уверен, как сейчас обстоят дела с русскоязычными книгами по программированию, может хорошие переводы стали стандартом).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что читать о перспективных языках программирования