От переводчика: этот пост — несколько сокращенный перевод оригинальной статьи Гала Шлезингера, опытного 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 рекомендует:
- Онлайн-курс «Профессия Frontend-разработчик».
- Образовательный онлайн-курс «Профессия веб-разработчик».
- Образовательный онлайн-курс «Профессия Java-разработчик».
Комментарии (13)
argonavtt
27.09.2018 12:26+1Аргументы в стиле «скучный» странно слышать в адрес языка программирования. Вам не кажется, что это скорее относится к поставленным задачам?
OlvinKSA
27.09.2018 13:19Про Go-lang:
Просто фантастический язык. Он прост для изучения, код без проблем компилируется и выполняется.
…
Сам язык довольно сложный.
Так простой или сложный? Или сложный — это про модульную систему VGO?DelphiCowboy
28.09.2018 08:00Брэйн-фак — тоже очень прост для изучения, но пробуйте на нём что-нибудь серьёзное написать и обнаружите, что он довольно сложный.
Так что простота изучения — отнюдь не означает простоту использования.
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.
И так далее.
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 гораздо более популярена, основные принципы одинаковы.
bosom
27.09.2018 14:14Согласен с автором. Идеального языка нет, особенно когда не знаешь для чего вообще хочешь выбрать язык и какую проблему решаешь.
Есть задачи которые легко решаются на одном языке, а на другом решение выглядит как фаршкод над не понятно кем написанными фреймворками сделанными на сотнях заплаток скотче и костылях с тележкой какашек в виде интерпретатора… Администраторам очень весело под такие решения сервер готовить :)
Но статья хорошая, напомнила вот эту: divan.github.io/posts/go_complain_howto
Автору спасибо! Надеюсь будет продолжение где всё-же будет избран тот самый идеальный язык программирования!
Siemargl
28.09.2018 10:01Довольно странно оценивать языки по удобству работы с ними в редакторе Vim (и других редакторах).
helgihabr
Не хватает выводов. Я ожидал, что он все-таки нашел язык близкий к своему идеалу.
Да и аргументы типа «скучный» или «молодой» не тянут на серьезную критику.
Shtucer
Вывод, как ни странно, похоже, в заголовке статьи.