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



    От переводчика: этот пост — несколько сокращенный перевод оригинальной статьи Гала Шлезингера, опытного 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 рекомендует:

    Skillbox
    182,56
    Онлайн-университет профессий будущего
    Поделиться публикацией

    Комментарии 14

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

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

        +1
        Аргументы в стиле «скучный» странно слышать в адрес языка программирования. Вам не кажется, что это скорее относится к поставленным задачам?
          +2
          Про Go-lang:
          Просто фантастический язык. Он прост для изучения, код без проблем компилируется и выполняется.

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

          Так простой или сложный? Или сложный — это про модульную систему VGO?
            0
            Брэйн-фак — тоже очень прост для изучения, но пробуйте на нём что-нибудь серьёзное написать и обнаружите, что он довольно сложный.
            Так что простота изучения — отнюдь не означает простоту использования.
              0
              BF простой, но писать на нем трудно.
            +5
            Переводчик очень вольно обращается с оригинальным текстом, местами значительно искажает мысли автора, в некоторых местах просто отсебятина.

            Вместо «Сам язык довольно сложный» в оригинале
            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.


            И так далее.

              0

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


              К слову, и 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
              Согласен с автором. Идеального языка нет, особенно когда не знаешь для чего вообще хочешь выбрать язык и какую проблему решаешь.

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

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

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

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

                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Тут для автора го довольно сложный, вы что?
                      +1

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

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

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

                    Самое читаемое