От переводчика: этот пост — несколько сокращенный перевод оригинальной статьи Гала Шлезингера, опытного frontend-разработчика. Ему очень нравится программировать, а его хобби — изучение различных (и порою весьма неожиданных) языков программирования как для рабочих целей, так и для собственных pet-проектов. О достоинствах и недостатках нескольких из них Гал и рассказывает в этом материале.

Несмотря на то что на работе я чаще всего работаю с Java, JS и Ruby, мне нравится изучать новые языки и фреймворки. Мне кажется, что постоянное обучение помогает формировать новые интересные идеи, которые можно использовать при необходимости для решения определенной задачи. Кроме того, функциональное программирование помогает понять больше про объектно-ориентированное программирование, а постоянная работа с Rails позволяет изучить многие нюансы тестирования (конечно, если вы будете практиковаться). Проблема в том, что рано или поздно в процессе изучения других языков вы начинаете задумываться: а есть ли среди них идеальный, где были бы собраны все полезные функции, найденные вами в других?

Skillbox рекомендует: Практический курс «Мобильный разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

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

Ruby


Ruby я начал изучать только потому, что его сообщество постоянно повторяет мысль о том, что здесь все отличается от Java, с которой я работал ранее. Мне очень нравится Ruby. Это отличный язык с большим количеством готовых библиотек (мы называем их «гемы», gems), который позволяет вам быстро разработать и пустить в дело новое приложение. Rails — то, что можно назвать «сел и поехал».

Ruby — объектно-ориентированный язык, так что весь код будет примерно в одном и том же стиле, безразлично, какую из библиотек вы решили выбрать. Сообщество здесь очень мощное: программисты предпочитают дорабатывать уже существующие библиотеки вместо того, чтобы каждый раз создавать для себя новую (ActiveRecord и Sequel как пример). Эта особенность позволяет здорово облегчить себе жизнь.

Правда, Ruby недостаточно быстрый, если мы говорим о производительности. Компоненты обычно «тяжелые» и загружаются достаточно долго. Практиковаться с Rails интересно, но запускать приложения означает тратить время и деньги. В качестве примера можно привести Heroku и AWS ECS: вам придется платить за ОЗУ, файловое пространство, трафик и время работы. Кроме того, необходимо учитывать, что ориентировочное время старта приложения среднего размера — 5-10 секунд.

JavaScript


Я обожаю JavaScript. Большинство моих frontend-проектов — для веба, поскольку у любого человека сейчас есть доступ к браузеру. Это относительно легкий в освоении язык, он очень распространен, порог входа низкий. Инструменты для разработчика весьма хороши, реализация прототипирования с использованием JavaScript — просто мечта. В сообществе тоже много участников, которые уделяют много внимания совершенствованию компонентов.

У JS много недостатков. Один из основных — разделение сообщества по различным направлениям развития языка в соответствии со своими предпочтениями. Так, основная дифференциация идет вокруг систем типов (Flow vs. TS), отличаются и подходы к использованию библиотек и всего остального. В результате многие наработки, модули просто «сырые».

Swift


После работы с предыдущими двумя языками я начал изучать Swift. Язык понадобился мне для продвижения в моей «игре в разработчика». Изначально я находился на нулевом уровне, поскольку лишь знал, как создавать приложения с Native React. В принципе, и этого было достаточно, но мне хотелось изучить больше.

Swift — статически типизированный язык. Изначально он создавался для разработки приложений в экосистеме Apple, но затем стал опенсурсным, благодаря чему теперь с ним работают для создания приложений под Linux. Достоинства языка — то, что приложения, написанные на нем, быстро загружаются, а процесс компиляции понятный, так что число runtime-ошибок постепенно сводится к минимуму.

Синтаксис языка интересный и не слишком сложный в освоении, некоторые функции здорово помогают избежать ошибок и проблем. К примеру, если часть кода «ожидает» строку, ошибочная передача туда целого числа не допускается. Это позволяет вам ловить и исправлять ошибки на самом раннем этапе процесса разработки.

Почему Swift не мой герой? Дело в том, что не так и просто писать на Swift в редакторах, отличных от Xcode. Обычно я использую Vim, другие редакторы работают медленнее. Как-то я попробовал VSCode и Atom, но они мне не очень понравились. Возможно, я в конце концов остановлюсь на Swift CLI, который позволит создавать плагины к редактору, но не сейчас. У Swift также нет статической компиляции, поэтому для использования CLI вам понадобится настроить среду со Swift. Это нормально для приложений Mac, но серверы — это Linux.

ReasonML


Я очень доволен этим новым синтаксисом и набором инструментов для Ocaml, разработанным Facebook. Тулкит вполне зрелый, функций он дает много. Хороши здесь OPAM, менеджер пакетов, а также Merlin и OCaml / Reason. Все это отлично взаимодействует с Vim. И это даже если не упоминать autocomplete engine и другие функции. Инструменты для разработчика здесь очень хороши.

Reason может быть скомпилирован в JS с использованием BuckleScript, генерирующего исполняемый JS из кода Reason / OCaml. Это потрясающе, потому что в этом случае мы получаем полностью типизированные системы с отличным JS-взаимодействием, а также можем использовать нужные библиотеки.

Единственное, что мне не нравится, — это то, что я должен создавать множество определений типов только для использования зависимостей. Но и это ничего, ведь нам не нужно собирать весь модуль, а только ввод / вывод определенной функции / класса / метода, которые мы используем. Работает все это очень быстро и без проблем.


Для меня сложностью при создании нативного Reason-приложения оказалось использование некоторых библиотек. В первую очередь это OCaml, но поскольку OCaml и Reason взаимозаменяемы, я использовал расширение Chrome для работы с кодом Reason. Проблемой оказалось в том, что есть код OCaml, который не конвертируется в Reason, возможно, из-за нехватки PPX в расширении Chrome. PPX, насколько я понимаю, расширение синтаксиса — макрос, который преобразует код. Это нечто вроде плагина Babel.

К слову, и Reason / Ocaml не поддерживают multi-core, для этого есть Lwt. Но для этой библиотеки до сих пор нет внятных мануалов!

Порог входа в OCaml / Reason очень высокий, что немного расстраивает. Сообщество не слишком развитое, и мало кто хорошо объясняет непонятные вещи. Возможно, с течением времени все это изменится.

Golang


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

Тот факт, что существует множество мощных модулей и приложений, написанных на Go, таких как Docker, Kubernetes, CockroachDB, означает, что вы можете создать внутри вашего приложения инфраструктурный бинарник для, например, Raspberry pi.

Отсутствие дженериков (что может быть добавлено в одной из последующих версий) — странность, поскольку возникают «структурные» сложности при использовании графов, деревьев и алгоритмов. Я бы предпочел, чтобы компилятор все делал за меня.

Кроме того, проблемой для меня является не слишком понятная модульная система VGO. Со временем мы узнаем о ней больше, поскольку сообщество постепенно развивается, но пока что информации мало. Сам язык довольно сложный. Это не причина его не использовать, но пока что я избегаю полноценной работы с Golang. Он, если так можно выразиться, скучный. Возможно, с течением времени я пересмотрю свои взгляды.

Crystal


Мы начали с Ruby, поэтому я предлагаю закончить Crystal.

Это один из новых языков, все еще не добравшийся до версии 1.0, который выглядит почти как Ruby, но он статически типизирован и быстр! Он предлагает разработчикам большое количество функций, включая опциональные типы, CSP и многое другое. Есть пара новых веб-фреймворков для Crystal, например Lucky и Amber. Есть и Kemal, который как Sinatra, но для Crystal, плюс есть ORMs.

Но, поскольку язык еще молод, он не совсем готов к активному использованию. Я бы хотел, например, чтобы Crystal задействовал все ядра, как Go. Редактор с автозаполнением и подсказками типов при наведении тоже не был бы лишним. Я немного переживаю из-за мысли о том, что Crystal может не добраться до версии 1.0. Искренне надеюсь, что ему это удастся.

А какой ваш любимый язык программирования и почему?

Skillbox рекомендует:

Комментарии (13)


  1. helgihabr
    27.09.2018 12:17
    +1

    Не хватает выводов. Я ожидал, что он все-таки нашел язык близкий к своему идеалу.
    Да и аргументы типа «скучный» или «молодой» не тянут на серьезную критику.


    1. Shtucer
      27.09.2018 13:26

      Вывод, как ни странно, похоже, в заголовке статьи.


  1. argonavtt
    27.09.2018 12:26
    +1

    Аргументы в стиле «скучный» странно слышать в адрес языка программирования. Вам не кажется, что это скорее относится к поставленным задачам?


  1. OlvinKSA
    27.09.2018 13:19

    Про Go-lang:

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

    Сам язык довольно сложный.

    Так простой или сложный? Или сложный — это про модульную систему VGO?


    1. DelphiCowboy
      28.09.2018 08:00

      Брэйн-фак — тоже очень прост для изучения, но пробуйте на нём что-нибудь серьёзное написать и обнаружите, что он довольно сложный.
      Так что простота изучения — отнюдь не означает простоту использования.


  1. Neusser
    27.09.2018 13:44

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

    Вместо «Сам язык довольно сложный» в оригинале

    I think that the language itself isn’t pretty


    Вместо " Он, если так можно выразиться, скучный" в оригинале написано
    «It’s just not fun, it’s simple, boring and good.»


    Вместо «После работы с предыдущими двумя языками я начал изучать Swift» в оригинале написано
    Lately, I started to learn Swift to bump up my iOS development game.


    И так далее.


    1. roman_kashitsyn
      29.09.2018 11:40

      Добавлю также про сильно искажённые факты


      К слову, и Reason / Ocaml не поддерживают multi-core, для этого есть Lwt.

      Lwt не для multi-core, а для concurrent programming! Вот что написано в оригинальной статье:


      Native Reason/OCaml doesn’t have multi-core support yet, but for doing concurrent processes you can use Lwt, which is a promise-like library.

      От себя добавлю, что есть похожая библиотека Async, которой посвящена глава в Real World OCaml. Хотя Lwt гораздо более популярена, основные принципы одинаковы.


  1. bosom
    27.09.2018 14:14

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

    Есть задачи которые легко решаются на одном языке, а на другом решение выглядит как фаршкод над не понятно кем написанными фреймворками сделанными на сотнях заплаток скотче и костылях с тележкой какашек в виде интерпретатора… Администраторам очень весело под такие решения сервер готовить :)

    Но статья хорошая, напомнила вот эту: divan.github.io/posts/go_complain_howto

    Автору спасибо! Надеюсь будет продолжение где всё-же будет избран тот самый идеальный язык программирования!


  1. AlexTheLost
    27.09.2018 15:16

    Попробуйте Clojure. Простой и эффективный.


  1. forcam
    27.09.2018 20:27

    Идеала нет: как я искал язык программирования для себя

    В смысле? А как же Rust?)


    1. nlinker
      27.09.2018 21:04

      Тут для автора го довольно сложный, вы что?


      1. symbix
        28.09.2018 03:55

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


  1. Siemargl
    28.09.2018 10:01

    Довольно странно оценивать языки по удобству работы с ними в редакторе Vim (и других редакторах).