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

Original author: Ilya Kowalewski
  • Translation
Прим. переводчика — это всего лишь перевод статьи, которая отражает альтернативную точку зрения на тему «Go против Rust». Вовсе не обязятельно показывать свое несогласие с мнением автора на карме переводчика, спасибо.

Эта статья — небольшой ответ к записи в блоге Дейва Чейни «Почему Go и Rust не соперники». Я настоятельно рекомендую вам почитать его доводы! Вероятно, вам также понравится замечательная дискуссия на реддите.

На самом деле, Go и Rust решают одну и ту же самую проблему: оба пришли в наш мир, чтобы сделать жизнь программистов проще. Go до безобразия упростил концепт конкурентного (ака многопоточного) программирования и мне кажется, сделал программирование приятным занятием, ведь код на Go действительно приятно читать. В то ж время, Rust подарил нам мощные zero-cost абстракции… для паттерн-матчинга. Звучит оправданно, не так ли? Шутки-шутками, но Rust действительно сделал многие непростые штуки проще (частое заблуждение: он не избавился от них). Его дьявольская система типов позволяет гарантировать безопасность памяти, и в том числе, избавиться от состояния гонки, что звучит очень заманчиво.

Если мне не изменяет память, Роб Пайк (папаша языка Go) как-то сказал, что очень удивился, как все обернулось. Go задумывался, как спасательный круг для программистов на С/C++, но в конце-концов, люди стали думать о нем, как об альтернативе или даже замене Ruby или Python! Я считаю, что это просто офигенно, это не могло обернуться лучше.

Хорошо, тогда какое отношение Go имеет к Rust? Rust смахивает на мощную и безопасную замену для C++, который, как оказалось, мало чего общего имеет с Go. Тогда чего этим ребятам вообще соревноваться? Мир, дружба, печеньки! Но нееееет:

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

Те, кто считает, что самая большая проблема C++ это его «небезопасная» природа (давайте на минуточку забудем про умные указатели из последних стандартов, которые по своей природе, довольно безопасны) очень сильно заблуждаются. Самая большая проблема С++ заключается в том, что код на этом языке тяжело писать, читать, отлаживать, профилировать и поддерживать. В действительности, есть несколько известных путей для достижения безопасного управления памятью. Спросите у программистов на С++, это так-то мнимая проблема!

Повторюсь, программы на C++ тяжело читать, писать, отлаживать и поддерживать. И это мало относится к управлению памятью! Rust в этом ничем не отличается от С++. И вы не сможете решить эту проблему, умножая сущности, добавляя еще и еще концептов. Здесь очень классно справляется Go: «меньше» экспоненциально «больше» (прим. переводчика — less is exponentially more).

Что Go, что Rust — оба пытаются сделать нашу жизнь легче, не считая факта, что Go уже действительно поощряет своих программистов, помогая писать читабельный и легко поддерживаемый код с разумным количеством абстракций, в то времся как Rust охотится за великой и страшной проблемой Управления Памятью. Go и Rust всегда будут кровными врагами и несколько печально признавать, что последний уже проиграл эту войну.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 132

    +11
    Прим. переводчика — это всего лишь перевод статьи, которая отражает альтернативную точку зрения на тему «Go против Rust». Вовсе не обязятельно показывать свое несогласие с мнением автора на карме переводчика, спасибо.
    Стоп, я чего то не понял или автор и переводчик это одно и тоже лицо?

    Кстати, показательна реакция реддита на сстатью ;)
    К примеру:
    This is getting more and more dramatic. Is HBO coming out with an original?
    Holy cow, I expected something misinformed, but this was too much.
      0
      Комментарий про HBO и вправду очень смешной, особенно учитывая то, что по теме «Go vs Rust» за последний месяц было штук пять статей/заметок.
      +4
      В пересекающейся области Go действительно смотрится намного выигрышней. Но ведь есть области применения C++, где Go явно не следует использовать. Вот в них Rust крайне хорош. К примеру, не думаю, что кто-то серьезно будет писать под Cortex M на Go.
        –1
        Совсем не факт, учитывая, что некоторые пихают на кортексы всякие JS, NET и т.п., а затем пытаются продать как более простой Arduino :)
          +1
          Допускаю. Но это скорее рынок прототипирования. Там и помощнее SoC можно взять. И на скриптовом языке даже иногда написать всё. Но в серии это редко получается. Хотя, для IoT может и прокатить Go. Для относительно больших SoC.
          –9
          Что значит, серьезно писать? Что-то мне подсказывает, что сегодня мало кто станет серьезно писать под Cortex M на Rust. Я конечно не специалист, а скорее профан в этой области, но нестабильность стандартной библиотеки и высокий порог вхождения точно не очень играют на руку Rust в embedded разработке.
            +6
            Речь про концепции языков. Динамической выделение памяти, и то часто не приветствуется. Не говоря про GC. В этом контексте Go проигрывает.
            Стабильность библиотеки — для embedded не так выжна библиотека. Да и она сейчас достаточно стабильна. По крайней мере её нижний уровень, который и нужен по сути. Немного не хватает механизма выключения проверки границ массивов или его более умной версии, но это не совсемкритично.
            Порог вхождения — в embedded и так высокий порог вхождения, сложность концепций языка не сильно испортит картину, как мне кажется. Зато по предсказуемости Rust даже превосходит C.
              –6
              М-м-м-м… А чего сложного в, эм, embedded разработке? Это, конечно, не странички в веб выплевывать, но все же.
                +1
                Embedded разный бывает. Иногда есть 16 килобайт памяти и умещайся как знаешь.
                  +1
                  Бывает, что памяти и еще меньше.
                    +1
                    Да, конечно, мало памяти и все такое, надо выкручиваться довольно сильно. Но, с другой стороны, во встроенных системах имеется возможность плюс-минус полностью понимать все происходящее вплоть до железа, чего давно уже не встречается в программировании для ЦПУ.

                    Я не к тому, что жонглировать байтиками — дело вот прям тривиальное, а к тому, что *концептуально* оно не очень насыщенно.
                      –2
                      Просто для тех, кто не хочет учить ассемблер, сделали возможность писать на C. Некоторые прочат Rust и место C.
                        +1
                        (Не)желание учить ассемблер вообще не при делах. Просто читать код на С проще, чем читать код на ассемблере — следовательно и разработка легче. Например циклы на С становятся в ассемблерном коде кучей goto (исключая мелкие операции, к которым применим префикс повторения, если такой имеется). Кроме того, обычно нетрудно представить, во что превратит очередной кусок кода компилятор.

                        С другой стороны компилятор не человек, и может держать в памяти сразу весь код — особенно с link time optimization — что позволяет ему делать оптимизации вроде выкидывания неиспользуемого кода, встраивания функций, вследствие чего вновь выбрасывания кода.
                      0
                      Бывает, что памяти вообще нет. Только регистры.
                      +4
                      Я 9 лет занимался embedded разработкой именно для таких контроллеров с 16 килобайтами (а то и меньше)… и надо сказать, для меня это всегда было проще чем «странички в веб выплевывать». Потому что здесь нужно знать только чистый Си (возможно С++) и иметь одну pdf-ку с описанием контроллера (порты, прерывания, периферия...). Иногда — еще пару pdf-ок с описанием внешних периферийных устройств.
                      Никакого бешеного изобилия фреймворков, API, библиотек и технологий, которые меняются с огромной скоростью:) Никакой проблемы выбора.
                        0
                        Согласен, но… есть один момент.
                        Количество MCU превышает количество веб-фреймворков.
                        В embedded надо мыслить гибче и понимать как оно на уровне железа работает, а у многих с этим проблемы.
                        Хотя не вижу разницы: писать всю жизнь под одно семейство MCU или на одном веб-фреймворке.

                        Сам ненавижу веб, в детстве тяжелая психическая травма нанесена веб-технологиями, спустя 8 лет тошнит. Даже Джанго пробовал учить, не помогает.
                        +1
                        Иногда есть ещё меньше, пописывал я на плюсах для какой-то из attiny управлятор лазером. Нормально, вполне себе неплохо. А странички в веб выплёвывать терпеть вот не могу.
                          +1
                          Со страничками в web такое дело — там кроме программинга нужен еще дизайн. Или делать в олдскульном стиле 80-х, без всякого css… или дизайн, а я ни разу не дизайнер, у меня вообще мозг не работает в этом направлении. GUI в десктопных приложениях все-же более-менее стандартизирован — стандартные меню, стандартные тулбары, стандартные диалоги… конечно если кому-то хочется сделать «не как у всех» то можно пользоваться специальными GUI-библиотеками, но меня всегда устраивал стандартный GUI, встроенный в ОС. Более того, я вижу в этом преимущество — не нужно каждый раз привыкать к новому виду кнопок, полей ввода и прочих элементов (и поэтому я также отрицательно/настороженно отношусь к десктопным программам с сильно нестандартным GUI)

                          Кстати были у меня железные проекты с ethernet на борту и настройкой через web-интерфейс. Так что выплевывал таки странички в web — прямо из железки.
                            0
                            С gui под веб очень сильно выручают всякие там фрейморки типа bootstrap или foundation. Если говорить о веб-приложениях, разумеется.
                    +3
                    Мы вполне себе серьезно пробуем писать: github.com/hackndev/zinc
                  +16
                  Те, кто считает, что самая большая проблема C++ это его «небезопасная» природа… очень сильно заблуждаются. Самая большая проблема С++ заключается в том, что код на этом языке тяжело писать, читать, отлаживать, профилировать и поддерживать.

                  Самая большая проблема C++ — это отсутствие менеджера пакетов. В Go/Rust/Python/Ruby/JavaScript/Java/.NET вы находите подходящие инструменты и решаете задачу (ну может с Go и Rust я немного погорячился). В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента, и только после этого решаете задачу.
                    –8
                    Понятно, что зависимости — это геморрой. С другой стороны, это не косяк языка С++, а его реализаций :)
                      +15
                      > С другой стороны, это не косяк языка С++, а его реализаций

                      Место проклятое©

                      То, что вы стрелки перевели не помогает на нём писать более лучше.
                      +3
                      Неделя на подключение — это что-то очень специальное должно быть. Обычная либа подключается за час, сильно хитрая — за день. Основные проблемы возникают со сборкой, если есть бинарники (а они часто есть) то все делается влет. Только если либа почему-то отказывается собираться то можно серьезно застрять. Но все же из личных рекордов, два дня — на сборку буста интелом, и два — на хитрую математическую либу в винде которая требовала для себя тонну других либ, которые тоже требовали третьих либ, причем уже на Фортране. Неделя — это что-то очень экстравагантное должно быть. Типа подключения огра3д к проекту на c# :)

                      А вот отсутствие менеджера пакетов реально печалит, согласен. Для мелких проектов это не беда, а вот для энтерпрайза реально мешает жить.
                        +1
                        Обычная либа подключается за час, сильно хитрая — за день.

                        С порядком ваших оценок совершенно согласен, но обычно либа — не одна, отсюда и неделя вместо одного дня. А даже если вдруг одна, она обычно тянет за собой ещё парочку, а их сборка — опять же на ваших плечах.
                          +1
                          Ну так хитрая сборка с необходимостью тащить тонну зависимостей бывает далеко не только у проектов на плюсах. Подключение простой либы и в питоне и в плюсах пройдет с полпинка, а с хитрой возиться придется и там и там. Причем какой-нибудь хитрособираемый SuiteSparse SPQR кроме как на плюсах вообще и не найдешь еще.
                        +5
                        Имхо, самая большая проблема С++ — это чудовищный, запредельно запутанный Стандарт. В любом языке можно отстрелить себе ногу, но в С++ количество способов это сделать просто поражает.

                        И самое прелестное, что компилятор (если это не gcc c парой десятков добавочных флагов) практически не помогает, в лучшем случае предупреждение выдаст. Типа «no return statement in function returning non-void»; но скомпилировать — скомпилирует, чего уж там.

                        Очень много о чем приходится помнить или обвешиваться сторонними программами для проверок.
                          0
                          А решение же очень простое: не пишите код, который не понимаете.
                            +8
                            Решение — отстой. Не каждый поймет тот код, который написал ты. Надо писать такой код, который понимают все.
                              +1
                              Написание такого кода не вызывает наслаждения :(
                                0
                                Почему в других языках такой проблемы нет?
                                  0
                                  В каких, например?
                                    0
                                    Go.
                                      +1
                                      Пока что для Go обратная ситуация — все подряд испытают наслаждение от написания кода на Go, а у тех, кто код читает никакого наслаждения это не взывает.
                                        0
                                        Ерунда. Я и мои коллеги ежедневно читаем код на Go — полет нормальный, всем все нравится.
                                        +1
                                        Ну оберон еще предложите.
                                        –1
                                        Например ни разу не слышал, чтобы кто-либо испытывал наслаждение или жаловался на его отсутствие при программировании на JS и python. Зато довольно часто слышу это про C++ и изредка про Java и C#.
                                          +2
                                          У меня нет наслаждения от JS и Python, одни рвотные позывы, извините.
                                            –1
                                            Видимо проблема не в языке, а в вас.
                                              +2
                                              Отчего ж? На плюсах написать какой-нибудь шаблонный милый код — приятно, а от хаскеля вообще оргазм.
                                                –4
                                                Ну так на js можно писать еще более обобщенный код, чем на c++ или хаскел.
                                                Видимо проблема все-таки не в языке.
                                                  +5
                                                  Сомневаюсь, что получится более обобщённый код, чем на Haskell. По крайней мере, я бы на это посмотрел.

                                                  Может, туда и нормальную систему типов уже завезли?
                                                    –4
                                                    Динамическая типизация — самая выразительная система типов. Например в динамической системе типов можно написать нерекурсивный комбинатор неподвижной точки. А в статике — нельзя.
                                                        –1
                                                        UnsafeCoerce в хаскеле — проявления динамической типизации (отказ от контроля типов на стадии компиляции), а про powerset я ниче не понял.
                                                          0
                                                          Есть решения и без UnsafeCoerce, который не нужен.
                                                          0
                                                          Так там же тип рекурсивный объявлен. Мне кажется, это не очень честно.
                                                          0
                                                          Что это за комбинатор такой?
                                      +1
                                      Ну и собирайте, как положено. В случае с gcc:
                                      -Wall -Wextra -Werror -ansi -pedantic 
                                      
                                        0
                                        Я примерно так и поступаю — я ограничил себя небольшим подмножеством С++ и за пределы его вылезаю редко. Но наступить на грабли все равно очень легко, можно ведь просто не знать о какой-нибудь замечательной особенности.

                                        Вообще, когда только появился С, идея о «неопределенном поведении» была логична. Компиляторы были глупые, гораздо легче было переложить ответственность на программиста.

                                        Но сейчас это уже ни в какие ворота.
                                          –1
                                          Ну и какой смысл иметь в языке возможности, которыми запрещено пользоваться?
                                          Они же не совсем бесплатно даются, их наличие усложняет синтаксис разрешенных (что бы устранить неоднозначность), замедляет компилятор и дополнительные инструменты. Да и на управляемости проектов и наборе квалифицированных сотрудников такое решение отражается не лучшим образом.
                                          Лучше выбрать более чистый язык.
                                            +2
                                            Да, этот undefined behavior просто конкретно достает почти с каждой страницы, когда читаешь стандарт.
                                          +2
                                          По-моему про "-Wall -Wextra" знают почти все C++ программисты.
                                          Меня больше напрягает чудовищная сложность языка:
                                          • declaring != defining, более того, увы, часто нужны оба.
                                          • C'шному препроцессору тоже давно пора почить
                                          • Unicode. Как вы помните, с юникодом дела не очень.
                                          • Система типов. «Long имеет хотя бы 4 байта, и хотя бы такой же большой, как int» = отстой.
                                          • Шаблоны, конечно, штука замечательная. Только если при использовании шаблонных классов (например STL) вы сделаете ляп в типах, то получите под сотню строк ошибок.
                                          • Автомагическая генерация дефолтных конструкторов и пр. Готовы сходу ответить что генерируется и при каких условиях?

                                          Я, конечно, очень радуюсь фишкам из C++11 и C++14, но чем дальше, тем сильнее осознаёшь этот ужас…
                                            0
                                            Шаблоны, конечно, штука замечательная. Только если при использовании шаблонных классов (например STL) вы сделаете ляп в типах, то получите под сотню строк ошибок.

                                            Справедливости ради — в последних компиляторах максимум пара ошибок вместо сотен.
                                          0
                                          Ну, возьмите biicode и будет вам менеджер пакетов.
                                            +1
                                            Поискал библиотеки со своего проекта (libusb, exiv2, libRAW, libtiff) — ничего нет. Те, что есть (SDL, POCO, cURL и т. д.) и так элементарно подключаются.
                                              –1
                                              Ну так там есть только то, что кто-то уже туда добавил. Хотите добавить туда свой библиотеку — возьмите и добавьте.
                                                +4
                                                Это нифига не будет работать до тех пор, пока разработчики библиотек сами не воспринимают этот biicode как основной репозиторий для публикации релизов. Энтузиасты приходят и уходят, поэтому завязываться на них — себе дороже.
                                                  +2
                                                  А в мире С++ никаких «основных репозиториев» вообще быть не может. Нет одного мейнтейнера языка, нет одного «владельца» стандартной библиотеки, а значит и «главного» репозитория быть не может. Тем ни менее, может быть несколько «неглавных», среди которых со временем могут образоваться достаточно хорошие, решающие большую часть задач.
                                                    +4
                                                    Отсутствие одного мейнтейнера — это ни разу не проблема. Вот вам пример с Java:

                                                    1. Java в основном пилит Oracle, но есть реализации и не от Oracle.
                                                    2. В Java есть понятия Maven dependency и Maven repository. Эти штуки к Oracle не имеют никакого отношения. Maven — это проект Apache Software Foundation.
                                                    3. В Java есть «самый центральный репозиторий» — Maven Central. Он не имеет отношения ни к Oracle, ни к Apache. Им занимается Sonatype.

                                                    У меня есть теория, что у C++ никогда не будет ничего похожего только из-за того, что у «чистых C++ программистов» этой проблемы просто нет. Для них подключать библиотеку «всего 1 день» — это нормально. Проблемой это становится только для людей, у которых есть опыт с экосистемами других ЯП.
                                                      +2
                                                      Лично для меня этой проблемы нет потому, что установка библиотеки — вопрос одной команды системного пакетного менеджера, а её подключение — вопрос 5 минут на поиск FindFoo.cmake-файла либо его написание.
                                                        +1
                                                        А с Windows как быть?
                                                          +3
                                                          Избегать всеми силами.

                                                          Ну или, когда я крайний раз сторонников возможности использовать Windows для разработки троллил, они мне говорили, что в Windows 10-то пакетные менеджеры уже есть, чуть ли не хуже портажей!..
                                                            +1
                                                            С вашей точкой зрения полностью согласен, но это нифига не ответ.
                                                      0
                                                      Сам Страуструп совсем недавно на выступлении сказал, что признает проблему отсутствия у коммьюнити центра своим большим недосмотром. Одна из причин — отсутствие затрат на маркетинг, которые могли бы позволить в свое время наладить обмен информацией между программистами, и библиотеками в частности. Правда, при этом он заметил, что существуют «маленькие империи», вполне себе неплохо живущие со своим набором библиотек и тулзов, причем у некоторых из них больше 100К пользователей.
                                              0
                                              А меня еще удивило наличие в списке проблем отладки. Мне стало крайне интересно, в каком-то это языке отладка лучше, чем в С++. Я знаю — в порядке убывания знаний — С++, С#, Lisp, Bash, Haskell, Python. Мб что-то еще по мелочи — но из этого списка самая тяжелая отладка была в Bash. А самая простая отладка как раз таки в С++, о чем я не раз вспоминал, когда начал учить C#, и ушел с многофункционального gdb на студию и monodevelop.

                                              Вот честно — я действительно не знаю, что еще можно прикрутить связке GCC + AddressSanitizer + GDB в принципе. Черт подери, да в GDB есть даже чекпойнты — имеется хоть где-нибудь еще такая штука?!
                                                0
                                                asan, к сожалению, не всегда спасает, с парой таких случаев я встречался.

                                                Но кроме этого недоразумения я с вами согласен, да. Субъективно, сложнее всего в Haskell отлаживать, за счёт ленивости, в основном, как по мне.
                                              –1
                                              Жду следующую статью «Почему Go и Rust не враги, а друзья» с главным посылом о том, что Rust помогает Go избавить мир от C++ в тех нишах, где нужен ручной контроль памяти :)
                                              • UFO just landed and posted this here
                                                –8
                                                Посмотрел на Rust, посмотрел на Go и продолжил влюбляться в Crystal.
                                                  0
                                                  Да, Crystal довольно интересная штука. Надеюсь авторы продожат пилить проект. К 1.0 должна получиться конфетка.
                                                    0
                                                    Crystal, как альтернатива Nim, какое-то распространение может получить. Но вытеснять Rust и Go он врядли будет.
                                                      +6
                                                      Посмотрел на Rust, посмотрел на Go и продолжил любить С++ :)
                                                        +2
                                                        Я не уверен, что стоит писать на языке, автор которого считает, что вызывать сторонние программы в компайл-тайме — норма.
                                                        –15
                                                        ----Самая большая проблема C++ — это отсутствие менеджера пакетов.

                                                        пакетов чего?

                                                        --В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента

                                                        Не знаю в каком мире такое делается неделями, но в мире wintel VS/Borland никогда не занимает больше нескольких часов (Из моего опыта работы в больших компаниях).
                                                          +3
                                                          Стоит посмотреть на CMake-конфигурации крупных проектов, чтобы прийти в ужас. Десятки каких-то специфических cmake-макросов, куча external-project зависимостей, зависящих друг от друга, десятки патчей. И всё это пишется каждый раз вручную и потом поддерживается разработчиками проекта. Пока в конфигурации сборки разбираешься, уже уйдет неделя. Нифига это не просто даже с таким удобным инструментом как CMake. В общем, всё очень плохо у C++ в этом плане.
                                                            –1
                                                            Возможно в линухе так. Мой приятеь в Амазоне жаловался что ихний набор тулов C++ + Eclipse — это тихий ужас в настройке и использовании.

                                                            1. Конкретный пример — Blackberry Server на VC++. По TODO листу даже блондинка с улицы может за полдня может настроить машину и
                                                            сделать билд.

                                                            2. Другой примет Ricoh Enterprise Server на Java + Eclipse (Врагу не пожелаю) — сборка и настройка билда 3-4 дня минимум для продвинутого жабника.

                                                            Так что я полагаю дело лишь в затейливости идей тех кто создавал среду и зависимости.

                                                          +9
                                                          А разве Go настолько назкоуровниевый как Rust? Их вообще корректо сравнивать?
                                                            0
                                                            В Go при желании можно спуститься на довольно низкие уровни (до адресной арифметики и ассемблера), хотя язык и будет сопротивляться. Но сравнивать их действительно не корректно.
                                                              0
                                                              Го может работать с C/C++ либами если нужно.
                                                              import "C" import "unsafe"
                                                                +9
                                                                Он от этого сгенерирует бинарник для Z80?
                                                                  0
                                                                  Чего там Z80, он даже виндовую DLL с сишными экспортами сделать не может.
                                                                  0
                                                                  А ещё так умеют как минимум NodeJS, Java и .NET.
                                                                    0
                                                                    Но они не претендуют на низкоуровневые языки, к счастью.
                                                                0
                                                                К слову, о многих языках это слышал.

                                                                На C++ сложно создавать и поддерживать программы!
                                                                На JavaScript сложно создавать и поддерживать большие программы!
                                                                И т.д.
                                                                  +8
                                                                  C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.
                                                                    +1
                                                                    Those people simply have no idea of how to cook those cats properly.
                                                                    0
                                                                    К сожалению, удобство разработки и поддержки больших программ мало сказывается на популярности языка, в том числе и в больших проектах.
                                                                    Учатся начинающие программисты на меленьких, большая часть проектов не слишком велики. Потом и библиотеки для языков с низким уровнем вхождения плодятся. А потом и в серьезных проектах используют то, к чему привыкли.
                                                                    0
                                                                    А где статья-то?
                                                                      –5
                                                                      «Мама, де море?»
                                                                    • UFO just landed and posted this here
                                                                        +2
                                                                        А почему вы всех, кто занимается программированием графики отнесли к теоретикам? Вполне себе практические задачи. И, допустим, в разработке игр С++ — это стандарт, и его вряд ли что заменит, но если будет альтернатива для разработки новых проектов, будет замечательно. Вот народ и проверяет насколько Rust — альтернатива.
                                                                        • UFO just landed and posted this here
                                                                          –2
                                                                          Тоже чисто умозрительно, go обязан своей популярности докеру. И складывается впечатление, что в подобный «докер» из rust мира пророчат servo, который в firefox даже не планируется внедрять. Вот и остаются с rust одни теоретики.
                                                                            +1
                                                                            В Firefox внедрять его не слишком много смысла. На данный момент Servo — исследовательский движок, вокруг которого скорее всего придётся строить новый браузер, чтобы хорошо использовать его многопоточность, например.

                                                                            В то же время, Servo использует кучу существующих библиотек на C++ и да, Rust это «исследовательский язык для Servo». Но когда-то C был «исследовательским языком для Unix», просто никто не клеймил его такими ярлыками, потому что решение задачи в программировании — очень часто исследование.
                                                                              +2
                                                                              Судя по github.com/servo/servo/wiki/Roadmap, в Gecko его как раз очень даже собираются внедрять. Что качается Firefox — судя по презентации events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf#page=37 собираются(-лись ?) сделать тестовую версию Firefox mobile под Android с Servo под капотом.
                                                                                0
                                                                                О, интересно. Я видел, что они недавно какую-то штуку на Rust интегрировали в Gecko, но не думал, что это в рамках их плана постепенно всё заменить.
                                                                              –1
                                                                              Go стабилизировался 3 года назад, Rust — 2 месяца назад. Конечно, для Go будет написано гораздо больше продуктовых вещей.

                                                                              При этом для Rust уже есть сетевой стек, который вполне можно использовать — hyper, rustc-serialize, rust-postgres. Я этим пользовался для переписывания простого серверного приложения на Go — всё получилось, никаких принципиальных проблем. В целом же, вот статус сетевого стека для Rust.
                                                                                –7
                                                                                Можно вопрос? В 2015 году, в стандартной библиотеке современного языка Rust есть HTTP-клиент?
                                                                                  +5
                                                                                  Нет.

                                                                                  Моё мнение (совпадающее с мнением некоторых разработчиков Rust) — в стандартной библиотеке должен быть необходимый минимум вещей, у которых есть гарантированно оптимальная или общепринятая реализация (что называется, non-controversial и не opionated). HTTP-клиент к ним не относится.

                                                                                  Встречный вопрос: у вас есть как минимум 1 нормальный HTTP-клиент вне стандартной библиотеки; зачем его тащить внутрь?
                                                                                    –7
                                                                                    Я все понял. Если вы считаете, что в 2015 году, в стандартной библиотеке современного языка программирования не должно быть HTTP-клиента (не сервера, всего лишь клиента), то я думаю, что дальше спорить совершенно бесполезно.
                                                                                      +5
                                                                                      Поделитесь секретом: Зачем в стандартной библиотеке языка общего назначения HTTP клиент? Не REST, не SOAP, не что-то еще, а HTTP клиент. Я не представляю что им там можно делать. Разве что тесты писать, но это уже к тестирующим фреймворкам.
                                                                                      На мой взгляд HTTP-клиент — это самое бесполезное, что можно засунуть в стандартную библиотеку. SMTP и то осмысленнее, хотя тоже не надо.
                                                                                        –5
                                                                                        Что значит, «стандартная библиотека общего назначения»? В 2015 году софт чуть более, чем никогда не работает standalone, а так или иначе ходит в сеть. Ты хочешь сказать, что это не общая задача? Давай тогда из stdlib в плюсах и контейнеры к чертовой матери выкинем, это же не для общего назначения — хеллоуворлды и без них писать можно.
                                                                                          0
                                                                                          Спокойно, не нервничайте.
                                                                                          Да, софт взаимодействует в том числе по сети. Это REST, это SOAP, это тьма других стандартов. Но это точно не HTML.

                                                                                          HTTP-клиент это крайне специфичный инструмент, который мало кому нужен.
                                                                                            +1
                                                                                            Я где-то говорил про HTML?
                                                                                              +1
                                                                                              Нет, но все-же зачем в стандартной библиотеке HTTP клиент общего назначения? С поддержкой всех стандартных хедеров, включая Cookie?

                                                                                              Если это будет недоделанный клиент, то зачем его помечать в стандартную библиотеку — он недоделанный.
                                                                                              Полноценный же клиент совершенно логично поместить в отдельный проект, а не в стандартную библиотеку.
                                                                                              Да и для сетевого взаимодействия он не нужен — он избыточен и при этом слишком низкоуровневый — никто голым HTTPне пользуется, пользуются протоколами над HTTP.

                                                                                              Имело бы смысл реализовать ограниченную часть HTTP для REST, например, но не называть это HTTP клиентом. Но опять же хорошей реализации не получится. Да и протоколов слишком много. Это далеко не только REST с XML и JSON. Это и SOAP и многое другое. Зачем все это пихать в стандартную библиотеку?
                                                                                                +2
                                                                                                Как это никто не пользуется голым HTTP? Я вот пользуюсь. Читаю из ответа байтики, потом десериализирую их в JSON и работаю со своим REST.
                                                                                                  0
                                                                                                  Я надеюсь вы отделили чтение байтиков и десериализацию их в JSON от бизнеслогики?

                                                                                                  Тогда поздравляю, вы написали кастомный REST-клиент. Зачем вы это сделали при наличии огромного количества существующих REST-клиентов я не знаю, но вам виднее.
                                                                                                  Только почему вы считает задачу написания REST-клиента стандартной я не представляю.
                                                                                                    +1
                                                                                                    А чем HTTP-клиент отличается от REST-клиента?
                                                                                                      +2
                                                                                                      Уровнем абстракции.

                                                                                                      HTTP-клиент должен поддерживать HTTP и предоставлять к нему доступ, REST-клиент не обязан (хотя и может опционально дать доступ, например, к некоторым хедерам).
                                                                                                      Но главное различие: HTTP-клиент предоставляет доступ к body как к потоку байт, а REST-клиент предоставляет уже типизированный доступ к десериализованным объектам и проводит сериализацию объектов в body.

                                                                                                      REST-клиент реализует узкий набор набор задач на подмножестве протокола HTTP, предоставляя удобные инструменты для этого набора задач.

                                                                                                      В зависимости от реализации REST-клиент может использовать какой-то HTTP-клиент (а может и не использовать в целях снижения размера, например).
                                                                                                        +1
                                                                                                        А откуда вы узнаете к каким хидерам надо давать доступ в rest клиенте?
                                                                                                        Если рест-сервис отдает набор байт, то что будет на клиенте?
                                                                                                        0
                                                                                                        удалено
                                                                                                +1
                                                                                                Что REST, что SOAP, оба зачастую работают over HTTP. Я все еще не улавливаю ход мысли.
                                                                                                +2
                                                                                                Я пишу софт, который бывает чуть более, чем никогда, окей.

                                                                                                Вот длинная арифметика или сокеты в стандартной библиотеке моего языка мне бы не помешали, да. Но длинной арифметике там на самом деле не место.
                                                                                                  –1
                                                                                                  Действительно, зачем длинная арифметика в стандартной библиотеке, она же вообще никому не нужна. Кто пользуется длинной арифметикой? Какая криптография, о чем вы? Совершенно бесполезная и, что говорится, excessive штукотень!
                                                                                                    +2
                                                                                                    А какой бекенд? mpfr? gmp? Своя реализация?

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

                                                                                                    Зато почти во всех моих приложениях мне нужны методы оптимизации. Или language models. Или хотя бы такие примитивы, как bloom-фильтр. Срочно его добавить! И структуру для поддержания обратного индекса добавить! И Левенберга-Марквардта, куда же без оптимизаций-то всё-таки! И SVM, нейросети да генетику ещё для полного счастья!
                                                                                                      +1
                                                                                                      Все что вы назвали — это узкоспецифические алгоритмы, которые нужны для тех или иных редких задач. Большие числа куда чаще приходится считать.
                                                                                                        +5
                                                                                                        Http в стандартной бибилиотеке означает почти полную его заморозку. Либо несколько версий, добавляемых время от времени. См Python, к примеру. Для скриптового языка или языка, метящего в web — http клиент в stdlib наверное правильно, но для языка общего назначения лучше иметь хорошую внешнюю регулярно обновляемую библиотеку.
                                                                                                0
                                                                                                Секрет прост. Это влияет на разработку других библиотек, которые используют http клиент. Каждый постарается написать свой велосипед. Что и происходит в С++. С которым Rust пытается тягаться. Совпадение? Не думаю.

                                                                                                В 2015 году действительно стыдно не иметь такой функционал. Сходите на GitHub Trending и посмотрите какое количество проектов не связано с сетью.

                                                                                                Ссылка:
                                                                                                github.com/trending?l=rust&since=monthly
                                                                                                  +4
                                                                                                  В стандартной библиотеке должно быть только то, что не меняется практически никогда и поэтому может жёстко версионироваться одновременно с компилятором. Если вы включаете HTTP в std, вы не можете выпустить новую версию своего HTTP-клиента без выпуска новой версии std (т.е., по сути, без выпуска новой стабильной версии компилятора).

                                                                                                  И да, HTTP, наверное, меняется довольно редко, но по такой логике можно захотеть втащить ещё кучу application-level протоколов. Это не сфера ответственности Rust. Это системный язык.

                                                                                                  Если говорить конкретно, уже есть стандарт де-факто для HTTP — hyper. Просто потому что это первая достаточно полная достаточно стабильная реализация. Его не надо тащить в std, чтобы пользоваться им. При этом он всё же достаточно сложен, чтобы его нельзя было реализовать «очень быстро» и больше никогда не менять. Т.е. сам hyper сейчас активно развивается. Включение его в std сильно замедлило бы его развитие, потому что новые стабильные версии контейнера можно выпускать гораздо быстрее, чем новые стабильные версии std.

                                                                                                  Если так интересно расширение std, вот курируемый список де-факто стандартных библиотек.
                                                                                                    0
                                                                                                    В сети есть видео одной конфы по программированию, где Страуструп представлял новые черты C++ 11. В конце он нарисовал два квадрата, большой и маленький, и сказал: «у C# и Java маленький квадрат — это размер языка, а большой квадрат — это размер стандартных библиотек. Для С++ все наоборот и это плохо, мы будем стремиться к увеличению объема и функционала библитек.»
                                                                                        0
                                                                                        Кстати, на Go есть игровые движки? На Rust есть Piston.
                                                                                          +3
                                                                                          Есть, azul3d.org
                                                                                            0
                                                                                            А вам известны игры на нём?

                                                                                            Ни у них на сайте, ни в поиске ничего (совсем) релевантного не нашёл. Есть примеры от создателей, но я всё же про сторонние игры.
                                                                                              0
                                                                                              Писать игры на Go в июле 2015 года — глупость. Это фо-фан поделка.
                                                                                            0
                                                                                            Ну это вы перегнули. На Rust есть графические движки, да, и Piston стремится покрыть многие задачи именно игрового движка. Однако он суть просто набор библиотек, которым ещё долгий путь до настоящих движков. Давайте не торопить события.
                                                                                              0
                                                                                              Не понял.

                                                                                              Предоставляет полное ядро для написания игр? Предоставляет. Игры на нём делают? Делают. Значит движок.

                                                                                              Другое дело, что сопустсвующих инструментов там не особо, и игры делают пока любительские. Это не SDK вроде Unity и Unreal, это просто движок, хотя и любительский.

                                                                                              То что он побит на тучу библиотек в своих репозиториях — вообще не принципиально. Под одной крышей он их объединяет.
                                                                                                +1
                                                                                                Неа, полным ядром там пока и не пахнет. Игры «на нём» делают точно также, как и без движков — пишут свою логику. Автор и сам его движком с натяжкой называет. Всё-таки есть большая разница между большим движком, разбитым на слои/библиотеки, и разбросанным набором библиотек, которые хотят быть движком.
                                                                                          +4
                                                                                          Есть ниши (встраиваемые системы, ОС, жесткий realtime) где Go трудноприменим, а Rust имеет шанс вытестить C++. С модой на «умные дома», «интернет вещей» и любительскую робототехнику эти ниши будут расширяться.
                                                                                          А заняв прочное место в них, Rust может постепенно отвоевывать и другие.

                                                                                          PS Лично мне код на Rust читать проще и приятнее, чем на Go. Хотя понимаю, что это мои заморочки — люблю pattern matching и ненавижу return.
                                                                                            +3
                                                                                            Go и Rust всегда будут кровными врагами и несколько печально признавать, что последний уже проиграл эту войну.

                                                                                            Даже в областях где критично отсутствие GC? Не думаю. Тут скорее интересно проиграл ли уже Rust плюсам.
                                                                                              –4
                                                                                              В областях, где прямо-таки критично, Rust проиграл С/C++ в самом начале, еще до релиза.
                                                                                                +1
                                                                                                Поясните? В самом начале Rust был сам на себя не похож.

                                                                                            Only users with full accounts can post comments. Log in, please.