В этом небольшом посте я расскажу, почему я считаю, что Go и Rust не являются соперниками.

Почему некоторые считают, что Go и Rust соперники?

  • Rust и Go анонсировали в примерно одно и то же время. Разработку языка Go начали в 2007 и в ноябре 2009 он уже увидел свет. Rust появился несколько месяцев спустя, в 2010, тем не менее Грейдон отмечает, что разработку начали гораздо раньше. В любом случае, у обоих языков достаточно явно различаются влиятельные предшественники. В случае Go, это CSP Хоара, Alef, и Newsqueak Пайка. Rust рассматривается, как расширение семейства ML-языков.
  • Что Rust, что Go — оба считаются безопасными (по части управления памятью). В то время, как это утверждение абсолютно правдиво, оба языка не поощряют использование unsafe кода; что более важно, сегодня мир просто не примет язык без подобных гарантий надежности. Просто так получилось, что Go и Rust — это первые языки, которым удалось доказать, спустя десятилетия доказательств, что в реальности программисты просто не могут безопасно обращаться с памятью вручную.
  • Оба очень молоды: Go достиг 1.0 в 2012, а Rust в середине 2015 года. Оба более, чем амбициозны и явно готовы потеснить «старожил».


Почему я считаю, что Go и Rust таки не соперники?

  • Фокус Rust лежит на “free of charge” абстракциях. Звучит знакомо, не так ли? Последние несколько десятилетий, это был боевой клич всех С++ программистов! Так как Go делает слишком много вещей во время исполнения программы, то приходится несколько пожертвовать производительностью в пользу простоты и ортогональности.
  • Rust изначально делали совместимым с языком C; код на Rust, по определению, легко встраивается в программы, которые поддерживают вызовы из С. Go также совместим с конвенцией вызовов С через cgo, но пользоваться им стоит только тогда, когда это действително необходимо.
  • Фокус Go лежит на красивой реализации конкуррентности. Не то, чтобы аспекты этой конкуррентности нельзя было найти, например, в Ruby, но в Go они являются частью языка.
  • В отличии от Rust, Go целит на максимальную производительность на протяжении всего цикла разработки.


Rust и Go не соперники

За счет повсеместного навязывания «простоты», Go делает большие команды разработчиков эффективнее. Комплексные идеи или идеи, которые ведут к неортогональному поведению отсекаются. Rust метит на класс софта, который не допускает небезопасное использование памяти или сколько существенного оверхеда.

Rust соревнуется за внимание программистов на C++ и D, которые готовы к гораздо более сложному синтаксису и семантике (и что тоже важно, к значительному понижению читабельности) взамен на высокую производительность. Микроконтроллеры, ААА-игры, движки рендеринга веб-страниц. Go соревнуется за внимание компаний формата Интернет 2.0, которые просто переросли такие языки, как Ruby, Python или Node (V8) и уже не могут терпеть высокие требования языков с JVM.

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


  1. lolmaus
    16.07.2015 15:01
    +1

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


    1. namespace Автор
      16.07.2015 15:12

      Тут один чертяга недавно писал ядро ОС на Go… Но ты подумай, у Go хоть и классный, но сборщик мусора.


    1. CONSTantius
      16.07.2015 15:30
      +4

      Может и «годятся», но так-то и Nim «годится». Заставить работать можно, только это ничего не даёт — во-первых, нужна память для среды исполнения, во-вторых, гарантии безопасности Rust статические — во время исполнения это ничего не стоит.


      1. lolmaus
        16.07.2015 15:31
        +1

        То есть Rust годится для микроконтроллеров, а Go нет?

        Если так, то, имхо, это одно из решающих отличий.


        1. Googolplex
          16.07.2015 15:51
          +3

          Да, всё так.

          На Rust удобно написать программу для микроконтроллера гораздо проще, чем на Go.


          1. Alexeyco
            16.07.2015 16:50

            Можете хотя бы два-три аргумента накинуть?


            1. Googolplex
              16.07.2015 17:08
              +9

              На Rust писать без рантайма проще, чем на Go. Для поддержки всех фич Go нужен рантайм. Каналы, встроенные типы данных, горутины — всё это без рантайма работать не будет, а без этих фич Go — это крайне неудобный C. В Rust практически весь язык доступен вообще без какого-либо внешнего кода, и, кроме того, он «модульный», если это так можно сформулировать. Например, вы хотите написать программу для Pebble. Там свои скрипты сборки, своя архитектура и своя сишная библиотека, сильно урезанная по сравнению, например, с glibc. Не проблема — отключаете std, подключаете то, что можно, например, liballoc (и, как следствие, станет возможно взять libcollections и ещё кучу всего), который можно подключить, обернув сишный malloc/free, компилируете свою программу как статическую библиотеку и скармливаете её нативным для Pebble скриптам сборки — и всё будет работать.

              В Rust писать низкоуровневый код, например, работу с сырыми указателями, гораздо проще. Goшный unsafe.Pointer очень неудобен по сравнению с его обычными указателями. В Go нет inline assembly, в Rust есть, и есть планы по его улучшению.


  1. deniskreshikhin
    16.07.2015 15:12

    Rust изначально делали совместимым с языком C; код на Rust, по определению, легко встраивается в программы, которые поддерживают вызовы из С. Go также совместим с конвенцией вызовов С через cgo, но пользоваться им стоит только тогда, когда это действително необходимо.


    Вроде всё наоборот, в rust надо вручную описывать внешние функции, а в golang можно сразу подключить заголовочный файл.


    1. namespace Автор
      16.07.2015 15:14
      +3

      Тут речь о том, что так как у Rust бэкенд это LLVM, то можно библиотеки на Rust, линковать к другим приложениям.


      1. 0xd34df00d
        17.07.2015 13:27

        А научите, пожалуйста, так делать?

        У меня вот приложение на C++ есть, хочу линковать с ним библиотеки на хаскеле с ghc -fllvm.


    1. CONSTantius
      16.07.2015 15:27
      +2

      Тут говорят о том, что у Rust практически отсутствует среда исполнения, поэтому его можно легко встраивать в языки с runtime. В официальной книге есть пример вызова Rust из Ruby.


  1. corvette
    16.07.2015 16:19

    Есть куча характеристик, показатели которых можно измерять для Rust и Go. И в этом смысле определять соперничество.
    То, что они предназначены для разных областей, не значит что они не являются соперниками. Просто один другому однозначно проигрывает в популярности, в зависимости от сферы применения.


  1. shoomyst
    16.07.2015 16:20
    +7

    Недавно решил взглянуть на оба языка. Как-то с первых же глав их документаций ощущается, что Rust метит в нишу безопасного системного ПО С/С++, а Go больше по прикладному на замену Java/Python/Perl/Nodejs


    1. ShadowsMind
      16.07.2015 18:41

      Go больше по прикладному на замену Java/Python/Perl/Nodejs

      Спорное утверждение, как альтернативу еще может быть, но чтобы прям замену… Да и к тому же даже у этих казалось бы чаще применимых на бэкэндах языков отчасти разные ниши. Не будете же Вы для банков ПО писать на NodeJS. А если сравнить Python и Go в разрезе разработки сферического веб-сайта в вакууме, то победитель тоже очевиден.


      1. shoomyst
        16.07.2015 18:53

        Ну понятно, что это очень грубая оценка. Объединил я эти средства по большей части в контексте веб-приложений, где сейчас у Go наблюдается наверное наибольшая популярность. Perl/Python скорее в контексте написания различных скриптов. В общем посыл в том, что может работать на низком уровне, но сами же слабо позиционируют себя в этом направлении


      1. astec
        17.07.2015 02:28

        Ну вот я знаю один очень большой банк (международный) в котором сделали огромный фрэймворк на Питоне (под капотом много всего, но бизнес логика именно на Питоне) и сейчас мигрируют Java и .NET приложения на него. Сделано всё довольно круто. Так что теоретически наверное и на NodeJS можно.


        1. ShadowsMind
          17.07.2015 16:58

          Хм, достаточно интересно. Но в принципе ничего удивительно, зная то насколько Python хорошо подходит для data mining и т.д., можно с легкостью предположить, что и для финансовых операций он отлично подойдет. Не в курсе как у него с транзакциями и т.д., но думаю что язык вполне подходящий под эту нишу.


          1. 0xd34df00d
            17.07.2015 19:18

            Питон отлично подходит для data mining только потому, что на нём есть несколько мощных библиотек для data mining'а.


      1. bogushevich
        17.07.2015 05:52
        +1

        Не будете же Вы для банков ПО писать на NodeJS.
        PayPal в 2013 году начал переход с Java на Node.js.
        There’s been a lot of talk on PayPal moving to node.js for an application platform. I’m happy to say that the rumors are true and our web applications are moving away from Java and onto JavaScript and node.js.


        1. ShadowsMind
          17.07.2015 16:55

          Если вчитаться, то можно увидеть, что они его юзают именно для веба. Речь то шла совсем о другом. Если гугл себе состряпает сайт для одного из сотни своих сервисов на Node.js, то не будем же мы говорить, что гугл на Node.js написан… Пока мы не увидим реально большие вещи на Node.js(например как инфраструктура Amazon'а), то даже и обсуждать нечего. Ничего не имею против Node.js(даже напротив очень рад что появилась такая быстрорастущая платформа), но надо понимать, что у него совсем другая ниша.


  1. SirEdvin
    16.07.2015 19:46

    Что Rust, что Go — оба считаются безопасными (по части управления памятью). В то время, как это утверждение абсолютно правдиво, оба языка не поощряют использование unsafe кода; что более важно, сегодня мир просто не примет язык без подобных гарантий надежности. Просто так получилось, что Go и Rust — это первые языки, которым удалось доказать, спустя десятилетия доказательств, что в реальности программисты просто не могут безопасно обращаться с памятью вручную.

    Если вам не сложно, не можете, пожалуйста, подсказать, чем именно они доказали это?
    Вон в Java и C# уже давно были сборщики мусора и они вроде оба безопасные по памяти.
    Или я что-то не понимаю?

    (Также существование C++ вот уже много лет доказывает, что вполне себе могут)