Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 132
Прим. переводчика — это всего лишь перевод статьи, которая отражает альтернативную точку зрения на тему «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.
В пересекающейся области Go действительно смотрится намного выигрышней. Но ведь есть области применения C++, где Go явно не следует использовать. Вот в них Rust крайне хорош. К примеру, не думаю, что кто-то серьезно будет писать под Cortex M на Go.
Совсем не факт, учитывая, что некоторые пихают на кортексы всякие JS, NET и т.п., а затем пытаются продать как более простой Arduino :)
Что значит, серьезно писать? Что-то мне подсказывает, что сегодня мало кто станет серьезно писать под Cortex M на Rust. Я конечно не специалист, а скорее профан в этой области, но нестабильность стандартной библиотеки и высокий порог вхождения точно не очень играют на руку Rust в embedded разработке.
Речь про концепции языков. Динамической выделение памяти, и то часто не приветствуется. Не говоря про GC. В этом контексте Go проигрывает.
Стабильность библиотеки — для embedded не так выжна библиотека. Да и она сейчас достаточно стабильна. По крайней мере её нижний уровень, который и нужен по сути. Немного не хватает механизма выключения проверки границ массивов или его более умной версии, но это не совсемкритично.
Порог вхождения — в embedded и так высокий порог вхождения, сложность концепций языка не сильно испортит картину, как мне кажется. Зато по предсказуемости Rust даже превосходит C.
Стабильность библиотеки — для embedded не так выжна библиотека. Да и она сейчас достаточно стабильна. По крайней мере её нижний уровень, который и нужен по сути. Немного не хватает механизма выключения проверки границ массивов или его более умной версии, но это не совсемкритично.
Порог вхождения — в embedded и так высокий порог вхождения, сложность концепций языка не сильно испортит картину, как мне кажется. Зато по предсказуемости Rust даже превосходит C.
М-м-м-м… А чего сложного в, эм, embedded разработке? Это, конечно, не странички в веб выплевывать, но все же.
Embedded разный бывает. Иногда есть 16 килобайт памяти и умещайся как знаешь.
Бывает, что памяти и еще меньше.
Да, конечно, мало памяти и все такое, надо выкручиваться довольно сильно. Но, с другой стороны, во встроенных системах имеется возможность плюс-минус полностью понимать все происходящее вплоть до железа, чего давно уже не встречается в программировании для ЦПУ.
Я не к тому, что жонглировать байтиками — дело вот прям тривиальное, а к тому, что *концептуально* оно не очень насыщенно.
Я не к тому, что жонглировать байтиками — дело вот прям тривиальное, а к тому, что *концептуально* оно не очень насыщенно.
Просто для тех, кто не хочет учить ассемблер, сделали возможность писать на C. Некоторые прочат Rust и место C.
(Не)желание учить ассемблер вообще не при делах. Просто читать код на С проще, чем читать код на ассемблере — следовательно и разработка легче. Например циклы на С становятся в ассемблерном коде кучей goto (исключая мелкие операции, к которым применим префикс повторения, если такой имеется). Кроме того, обычно нетрудно представить, во что превратит очередной кусок кода компилятор.
С другой стороны компилятор не человек, и может держать в памяти сразу весь код — особенно с link time optimization — что позволяет ему делать оптимизации вроде выкидывания неиспользуемого кода, встраивания функций, вследствие чего вновь выбрасывания кода.
С другой стороны компилятор не человек, и может держать в памяти сразу весь код — особенно с link time optimization — что позволяет ему делать оптимизации вроде выкидывания неиспользуемого кода, встраивания функций, вследствие чего вновь выбрасывания кода.
Бывает, что памяти вообще нет. Только регистры.
Я 9 лет занимался embedded разработкой именно для таких контроллеров с 16 килобайтами (а то и меньше)… и надо сказать, для меня это всегда было проще чем «странички в веб выплевывать». Потому что здесь нужно знать только чистый Си (возможно С++) и иметь одну pdf-ку с описанием контроллера (порты, прерывания, периферия...). Иногда — еще пару pdf-ок с описанием внешних периферийных устройств.
Никакого бешеного изобилия фреймворков, API, библиотек и технологий, которые меняются с огромной скоростью:) Никакой проблемы выбора.
Никакого бешеного изобилия фреймворков, API, библиотек и технологий, которые меняются с огромной скоростью:) Никакой проблемы выбора.
Согласен, но… есть один момент.
Количество MCU превышает количество веб-фреймворков.
В embedded надо мыслить гибче и понимать как оно на уровне железа работает, а у многих с этим проблемы.
Хотя не вижу разницы: писать всю жизнь под одно семейство MCU или на одном веб-фреймворке.
Сам ненавижу веб, в детстве тяжелая психическая травма нанесена веб-технологиями, спустя 8 лет тошнит. Даже Джанго пробовал учить, не помогает.
Количество MCU превышает количество веб-фреймворков.
В embedded надо мыслить гибче и понимать как оно на уровне железа работает, а у многих с этим проблемы.
Хотя не вижу разницы: писать всю жизнь под одно семейство MCU или на одном веб-фреймворке.
Сам ненавижу веб, в детстве тяжелая психическая травма нанесена веб-технологиями, спустя 8 лет тошнит. Даже Джанго пробовал учить, не помогает.
Со страничками в web такое дело — там кроме программинга нужен еще дизайн. Или делать в олдскульном стиле 80-х, без всякого css… или дизайн, а я ни разу не дизайнер, у меня вообще мозг не работает в этом направлении. GUI в десктопных приложениях все-же более-менее стандартизирован — стандартные меню, стандартные тулбары, стандартные диалоги… конечно если кому-то хочется сделать «не как у всех» то можно пользоваться специальными GUI-библиотеками, но меня всегда устраивал стандартный GUI, встроенный в ОС. Более того, я вижу в этом преимущество — не нужно каждый раз привыкать к новому виду кнопок, полей ввода и прочих элементов (и поэтому я также отрицательно/настороженно отношусь к десктопным программам с сильно нестандартным GUI)
Кстати были у меня железные проекты с ethernet на борту и настройкой через web-интерфейс. Так что выплевывал таки странички в web — прямо из железки.
Кстати были у меня железные проекты с ethernet на борту и настройкой через web-интерфейс. Так что выплевывал таки странички в web — прямо из железки.
Мы вполне себе серьезно пробуем писать: github.com/hackndev/zinc
Те, кто считает, что самая большая проблема C++ это его «небезопасная» природа… очень сильно заблуждаются. Самая большая проблема С++ заключается в том, что код на этом языке тяжело писать, читать, отлаживать, профилировать и поддерживать.
Самая большая проблема C++ — это отсутствие менеджера пакетов. В Go/Rust/Python/Ruby/JavaScript/Java/.NET вы находите подходящие инструменты и решаете задачу (ну может с Go и Rust я немного погорячился). В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента, и только после этого решаете задачу.
Понятно, что зависимости — это геморрой. С другой стороны, это не косяк языка С++, а его реализаций :)
Неделя на подключение — это что-то очень специальное должно быть. Обычная либа подключается за час, сильно хитрая — за день. Основные проблемы возникают со сборкой, если есть бинарники (а они часто есть) то все делается влет. Только если либа почему-то отказывается собираться то можно серьезно застрять. Но все же из личных рекордов, два дня — на сборку буста интелом, и два — на хитрую математическую либу в винде которая требовала для себя тонну других либ, которые тоже требовали третьих либ, причем уже на Фортране. Неделя — это что-то очень экстравагантное должно быть. Типа подключения огра3д к проекту на c# :)
А вот отсутствие менеджера пакетов реально печалит, согласен. Для мелких проектов это не беда, а вот для энтерпрайза реально мешает жить.
А вот отсутствие менеджера пакетов реально печалит, согласен. Для мелких проектов это не беда, а вот для энтерпрайза реально мешает жить.
Обычная либа подключается за час, сильно хитрая — за день.
С порядком ваших оценок совершенно согласен, но обычно либа — не одна, отсюда и неделя вместо одного дня. А даже если вдруг одна, она обычно тянет за собой ещё парочку, а их сборка — опять же на ваших плечах.
Ну так хитрая сборка с необходимостью тащить тонну зависимостей бывает далеко не только у проектов на плюсах. Подключение простой либы и в питоне и в плюсах пройдет с полпинка, а с хитрой возиться придется и там и там. Причем какой-нибудь хитрособираемый SuiteSparse SPQR кроме как на плюсах вообще и не найдешь еще.
Имхо, самая большая проблема С++ — это чудовищный, запредельно запутанный Стандарт. В любом языке можно отстрелить себе ногу, но в С++ количество способов это сделать просто поражает.
И самое прелестное, что компилятор (если это не gcc c парой десятков добавочных флагов) практически не помогает, в лучшем случае предупреждение выдаст. Типа «no return statement in function returning non-void»; но скомпилировать — скомпилирует, чего уж там.
Очень много о чем приходится помнить или обвешиваться сторонними программами для проверок.
И самое прелестное, что компилятор (если это не gcc c парой десятков добавочных флагов) практически не помогает, в лучшем случае предупреждение выдаст. Типа «no return statement in function returning non-void»; но скомпилировать — скомпилирует, чего уж там.
Очень много о чем приходится помнить или обвешиваться сторонними программами для проверок.
А решение же очень простое: не пишите код, который не понимаете.
Решение — отстой. Не каждый поймет тот код, который написал ты. Надо писать такой код, который понимают все.
Почему в других языках такой проблемы нет?
Go.
Например ни разу не слышал, чтобы кто-либо испытывал наслаждение или жаловался на его отсутствие при программировании на JS и python. Зато довольно часто слышу это про C++ и изредка про Java и C#.
Видимо проблема не в языке, а в вас.
Ну так на js можно писать еще более обобщенный код, чем на c++ или хаскел.
Видимо проблема все-таки не в языке.
Видимо проблема все-таки не в языке.
Ну и собирайте, как положено. В случае с gcc:
-Wall -Wextra -Werror -ansi -pedantic
Я примерно так и поступаю — я ограничил себя небольшим подмножеством С++ и за пределы его вылезаю редко. Но наступить на грабли все равно очень легко, можно ведь просто не знать о какой-нибудь замечательной особенности.
Вообще, когда только появился С, идея о «неопределенном поведении» была логична. Компиляторы были глупые, гораздо легче было переложить ответственность на программиста.
Но сейчас это уже ни в какие ворота.
Вообще, когда только появился С, идея о «неопределенном поведении» была логична. Компиляторы были глупые, гораздо легче было переложить ответственность на программиста.
Но сейчас это уже ни в какие ворота.
Ну и какой смысл иметь в языке возможности, которыми запрещено пользоваться?
Они же не совсем бесплатно даются, их наличие усложняет синтаксис разрешенных (что бы устранить неоднозначность), замедляет компилятор и дополнительные инструменты. Да и на управляемости проектов и наборе квалифицированных сотрудников такое решение отражается не лучшим образом.
Лучше выбрать более чистый язык.
Они же не совсем бесплатно даются, их наличие усложняет синтаксис разрешенных (что бы устранить неоднозначность), замедляет компилятор и дополнительные инструменты. Да и на управляемости проектов и наборе квалифицированных сотрудников такое решение отражается не лучшим образом.
Лучше выбрать более чистый язык.
Да, этот undefined behavior просто конкретно достает почти с каждой страницы, когда читаешь стандарт.
По-моему про "-Wall -Wextra" знают почти все C++ программисты.
Меня больше напрягает чудовищная сложность языка:
Я, конечно, очень радуюсь фишкам из C++11 и C++14, но чем дальше, тем сильнее осознаёшь этот ужас…
Меня больше напрягает чудовищная сложность языка:
- declaring != defining, более того, увы, часто нужны оба.
- C'шному препроцессору тоже давно пора почить
- Unicode. Как вы помните, с юникодом дела не очень.
- Система типов. «Long имеет хотя бы 4 байта, и хотя бы такой же большой, как int» = отстой.
- Шаблоны, конечно, штука замечательная. Только если при использовании шаблонных классов (например STL) вы сделаете ляп в типах, то получите под сотню строк ошибок.
- Автомагическая генерация дефолтных конструкторов и пр. Готовы сходу ответить что генерируется и при каких условиях?
Я, конечно, очень радуюсь фишкам из C++11 и C++14, но чем дальше, тем сильнее осознаёшь этот ужас…
Ну, возьмите biicode и будет вам менеджер пакетов.
Поискал библиотеки со своего проекта (libusb, exiv2, libRAW, libtiff) — ничего нет. Те, что есть (SDL, POCO, cURL и т. д.) и так элементарно подключаются.
Ну так там есть только то, что кто-то уже туда добавил. Хотите добавить туда свой библиотеку — возьмите и добавьте.
Это нифига не будет работать до тех пор, пока разработчики библиотек сами не воспринимают этот biicode как основной репозиторий для публикации релизов. Энтузиасты приходят и уходят, поэтому завязываться на них — себе дороже.
А в мире С++ никаких «основных репозиториев» вообще быть не может. Нет одного мейнтейнера языка, нет одного «владельца» стандартной библиотеки, а значит и «главного» репозитория быть не может. Тем ни менее, может быть несколько «неглавных», среди которых со временем могут образоваться достаточно хорошие, решающие большую часть задач.
Отсутствие одного мейнтейнера — это ни разу не проблема. Вот вам пример с 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 день» — это нормально. Проблемой это становится только для людей, у которых есть опыт с экосистемами других ЯП.
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 день» — это нормально. Проблемой это становится только для людей, у которых есть опыт с экосистемами других ЯП.
Сам Страуструп совсем недавно на выступлении сказал, что признает проблему отсутствия у коммьюнити центра своим большим недосмотром. Одна из причин — отсутствие затрат на маркетинг, которые могли бы позволить в свое время наладить обмен информацией между программистами, и библиотеками в частности. Правда, при этом он заметил, что существуют «маленькие империи», вполне себе неплохо живущие со своим набором библиотек и тулзов, причем у некоторых из них больше 100К пользователей.
А меня еще удивило наличие в списке проблем отладки. Мне стало крайне интересно, в каком-то это языке отладка лучше, чем в С++. Я знаю — в порядке убывания знаний — С++, С#, Lisp, Bash, Haskell, Python. Мб что-то еще по мелочи — но из этого списка самая тяжелая отладка была в Bash. А самая простая отладка как раз таки в С++, о чем я не раз вспоминал, когда начал учить C#, и ушел с многофункционального gdb на студию и monodevelop.
Вот честно — я действительно не знаю, что еще можно прикрутить связке GCC + AddressSanitizer + GDB в принципе. Черт подери, да в GDB есть даже чекпойнты — имеется хоть где-нибудь еще такая штука?!
Вот честно — я действительно не знаю, что еще можно прикрутить связке GCC + AddressSanitizer + GDB в принципе. Черт подери, да в GDB есть даже чекпойнты — имеется хоть где-нибудь еще такая штука?!
Жду следующую статью «Почему Go и Rust не враги, а друзья» с главным посылом о том, что Rust помогает Go избавить мир от C++ в тех нишах, где нужен ручной контроль памяти :)
Посмотрел на Rust, посмотрел на Go и продолжил влюбляться в Crystal.
Да, Crystal довольно интересная штука. Надеюсь авторы продожат пилить проект. К 1.0 должна получиться конфетка.
Crystal, как альтернатива Nim, какое-то распространение может получить. Но вытеснять Rust и Go он врядли будет.
Посмотрел на Rust, посмотрел на Go и продолжил любить С++ :)
Я не уверен, что стоит писать на языке, автор которого считает, что вызывать сторонние программы в компайл-тайме — норма.
Стоит посмотреть на CMake-конфигурации крупных проектов, чтобы прийти в ужас. Десятки каких-то специфических cmake-макросов, куча external-project зависимостей, зависящих друг от друга, десятки патчей. И всё это пишется каждый раз вручную и потом поддерживается разработчиками проекта. Пока в конфигурации сборки разбираешься, уже уйдет неделя. Нифига это не просто даже с таким удобным инструментом как CMake. В общем, всё очень плохо у C++ в этом плане.
А разве Go настолько назкоуровниевый как Rust? Их вообще корректо сравнивать?
К слову, о многих языках это слышал.
На C++ сложно создавать и поддерживать программы!
На JavaScript сложно создавать и поддерживать большие программы!
И т.д.
На C++ сложно создавать и поддерживать программы!
На JavaScript сложно создавать и поддерживать большие программы!
И т.д.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.
К сожалению, удобство разработки и поддержки больших программ мало сказывается на популярности языка, в том числе и в больших проектах.
Учатся начинающие программисты на меленьких, большая часть проектов не слишком велики. Потом и библиотеки для языков с низким уровнем вхождения плодятся. А потом и в серьезных проектах используют то, к чему привыкли.
Учатся начинающие программисты на меленьких, большая часть проектов не слишком велики. Потом и библиотеки для языков с низким уровнем вхождения плодятся. А потом и в серьезных проектах используют то, к чему привыкли.
А где статья-то?
А почему вы всех, кто занимается программированием графики отнесли к теоретикам? Вполне себе практические задачи. И, допустим, в разработке игр С++ — это стандарт, и его вряд ли что заменит, но если будет альтернатива для разработки новых проектов, будет замечательно. Вот народ и проверяет насколько Rust — альтернатива.
Тоже чисто умозрительно, go обязан своей популярности докеру. И складывается впечатление, что в подобный «докер» из rust мира пророчат servo, который в firefox даже не планируется внедрять. Вот и остаются с rust одни теоретики.
В Firefox внедрять его не слишком много смысла. На данный момент Servo — исследовательский движок, вокруг которого скорее всего придётся строить новый браузер, чтобы хорошо использовать его многопоточность, например.
В то же время, Servo использует кучу существующих библиотек на C++ и да, Rust это «исследовательский язык для Servo». Но когда-то C был «исследовательским языком для Unix», просто никто не клеймил его такими ярлыками, потому что решение задачи в программировании — очень часто исследование.
В то же время, Servo использует кучу существующих библиотек на C++ и да, Rust это «исследовательский язык для Servo». Но когда-то C был «исследовательским языком для Unix», просто никто не клеймил его такими ярлыками, потому что решение задачи в программировании — очень часто исследование.
Судя по github.com/servo/servo/wiki/Roadmap, в Gecko его как раз очень даже собираются внедрять. Что качается Firefox — судя по презентации events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf#page=37 собираются(-лись ?) сделать тестовую версию Firefox mobile под Android с Servo под капотом.
Go стабилизировался 3 года назад, Rust — 2 месяца назад. Конечно, для Go будет написано гораздо больше продуктовых вещей.
При этом для Rust уже есть сетевой стек, который вполне можно использовать — hyper, rustc-serialize, rust-postgres. Я этим пользовался для переписывания простого серверного приложения на Go — всё получилось, никаких принципиальных проблем. В целом же, вот статус сетевого стека для Rust.
При этом для Rust уже есть сетевой стек, который вполне можно использовать — hyper, rustc-serialize, rust-postgres. Я этим пользовался для переписывания простого серверного приложения на Go — всё получилось, никаких принципиальных проблем. В целом же, вот статус сетевого стека для Rust.
Можно вопрос? В 2015 году, в стандартной библиотеке современного языка Rust есть HTTP-клиент?
Нет.
Моё мнение (совпадающее с мнением некоторых разработчиков Rust) — в стандартной библиотеке должен быть необходимый минимум вещей, у которых есть гарантированно оптимальная или общепринятая реализация (что называется, non-controversial и не opionated). HTTP-клиент к ним не относится.
Встречный вопрос: у вас есть как минимум 1 нормальный HTTP-клиент вне стандартной библиотеки; зачем его тащить внутрь?
Моё мнение (совпадающее с мнением некоторых разработчиков Rust) — в стандартной библиотеке должен быть необходимый минимум вещей, у которых есть гарантированно оптимальная или общепринятая реализация (что называется, non-controversial и не opionated). HTTP-клиент к ним не относится.
Встречный вопрос: у вас есть как минимум 1 нормальный HTTP-клиент вне стандартной библиотеки; зачем его тащить внутрь?
Я все понял. Если вы считаете, что в 2015 году, в стандартной библиотеке современного языка программирования не должно быть HTTP-клиента (не сервера, всего лишь клиента), то я думаю, что дальше спорить совершенно бесполезно.
Поделитесь секретом: Зачем в стандартной библиотеке языка общего назначения HTTP клиент? Не REST, не SOAP, не что-то еще, а HTTP клиент. Я не представляю что им там можно делать. Разве что тесты писать, но это уже к тестирующим фреймворкам.
На мой взгляд HTTP-клиент — это самое бесполезное, что можно засунуть в стандартную библиотеку. SMTP и то осмысленнее, хотя тоже не надо.
На мой взгляд HTTP-клиент — это самое бесполезное, что можно засунуть в стандартную библиотеку. SMTP и то осмысленнее, хотя тоже не надо.
Что значит, «стандартная библиотека общего назначения»? В 2015 году софт чуть более, чем никогда не работает standalone, а так или иначе ходит в сеть. Ты хочешь сказать, что это не общая задача? Давай тогда из stdlib в плюсах и контейнеры к чертовой матери выкинем, это же не для общего назначения — хеллоуворлды и без них писать можно.
Спокойно, не нервничайте.
Да, софт взаимодействует в том числе по сети. Это REST, это SOAP, это тьма других стандартов. Но это точно не HTML.
HTTP-клиент это крайне специфичный инструмент, который мало кому нужен.
Да, софт взаимодействует в том числе по сети. Это REST, это SOAP, это тьма других стандартов. Но это точно не HTML.
HTTP-клиент это крайне специфичный инструмент, который мало кому нужен.
Я где-то говорил про HTML?
Нет, но все-же зачем в стандартной библиотеке HTTP клиент общего назначения? С поддержкой всех стандартных хедеров, включая Cookie?
Если это будет недоделанный клиент, то зачем его помечать в стандартную библиотеку — он недоделанный.
Полноценный же клиент совершенно логично поместить в отдельный проект, а не в стандартную библиотеку.
Да и для сетевого взаимодействия он не нужен — он избыточен и при этом слишком низкоуровневый — никто голым HTTPне пользуется, пользуются протоколами над HTTP.
Имело бы смысл реализовать ограниченную часть HTTP для REST, например, но не называть это HTTP клиентом. Но опять же хорошей реализации не получится. Да и протоколов слишком много. Это далеко не только REST с XML и JSON. Это и SOAP и многое другое. Зачем все это пихать в стандартную библиотеку?
Если это будет недоделанный клиент, то зачем его помечать в стандартную библиотеку — он недоделанный.
Полноценный же клиент совершенно логично поместить в отдельный проект, а не в стандартную библиотеку.
Да и для сетевого взаимодействия он не нужен — он избыточен и при этом слишком низкоуровневый — никто голым HTTPне пользуется, пользуются протоколами над HTTP.
Имело бы смысл реализовать ограниченную часть HTTP для REST, например, но не называть это HTTP клиентом. Но опять же хорошей реализации не получится. Да и протоколов слишком много. Это далеко не только REST с XML и JSON. Это и SOAP и многое другое. Зачем все это пихать в стандартную библиотеку?
Как это никто не пользуется голым HTTP? Я вот пользуюсь. Читаю из ответа байтики, потом десериализирую их в JSON и работаю со своим REST.
Я надеюсь вы отделили чтение байтиков и десериализацию их в JSON от бизнеслогики?
Тогда поздравляю, вы написали кастомный REST-клиент. Зачем вы это сделали при наличии огромного количества существующих REST-клиентов я не знаю, но вам виднее.
Только почему вы считает задачу написания REST-клиента стандартной я не представляю.
Тогда поздравляю, вы написали кастомный REST-клиент. Зачем вы это сделали при наличии огромного количества существующих REST-клиентов я не знаю, но вам виднее.
Только почему вы считает задачу написания REST-клиента стандартной я не представляю.
А чем HTTP-клиент отличается от REST-клиента?
Уровнем абстракции.
HTTP-клиент должен поддерживать HTTP и предоставлять к нему доступ, REST-клиент не обязан (хотя и может опционально дать доступ, например, к некоторым хедерам).
Но главное различие: HTTP-клиент предоставляет доступ к body как к потоку байт, а REST-клиент предоставляет уже типизированный доступ к десериализованным объектам и проводит сериализацию объектов в body.
REST-клиент реализует узкий набор набор задач на подмножестве протокола HTTP, предоставляя удобные инструменты для этого набора задач.
В зависимости от реализации REST-клиент может использовать какой-то HTTP-клиент (а может и не использовать в целях снижения размера, например).
HTTP-клиент должен поддерживать HTTP и предоставлять к нему доступ, REST-клиент не обязан (хотя и может опционально дать доступ, например, к некоторым хедерам).
Но главное различие: HTTP-клиент предоставляет доступ к body как к потоку байт, а REST-клиент предоставляет уже типизированный доступ к десериализованным объектам и проводит сериализацию объектов в body.
REST-клиент реализует узкий набор набор задач на подмножестве протокола HTTP, предоставляя удобные инструменты для этого набора задач.
В зависимости от реализации REST-клиент может использовать какой-то HTTP-клиент (а может и не использовать в целях снижения размера, например).
удалено
Что REST, что SOAP, оба зачастую работают over HTTP. Я все еще не улавливаю ход мысли.
Действительно, зачем длинная арифметика в стандартной библиотеке, она же вообще никому не нужна. Кто пользуется длинной арифметикой? Какая криптография, о чем вы? Совершенно бесполезная и, что говорится, excessive штукотень!
Все что вы назвали — это узкоспецифические алгоритмы, которые нужны для тех или иных редких задач. Большие числа куда чаще приходится считать.
Http в стандартной бибилиотеке означает почти полную его заморозку. Либо несколько версий, добавляемых время от времени. См Python, к примеру. Для скриптового языка или языка, метящего в web — http клиент в stdlib наверное правильно, но для языка общего назначения лучше иметь хорошую внешнюю регулярно обновляемую библиотеку.
Секрет прост. Это влияет на разработку других библиотек, которые используют http клиент. Каждый постарается написать свой велосипед. Что и происходит в С++. С которым Rust пытается тягаться. Совпадение? Не думаю.
В 2015 году действительно стыдно не иметь такой функционал. Сходите на GitHub Trending и посмотрите какое количество проектов не связано с сетью.
Ссылка:
github.com/trending?l=rust&since=monthly
В 2015 году действительно стыдно не иметь такой функционал. Сходите на GitHub Trending и посмотрите какое количество проектов не связано с сетью.
Ссылка:
github.com/trending?l=rust&since=monthly
В стандартной библиотеке должно быть только то, что не меняется практически никогда и поэтому может жёстко версионироваться одновременно с компилятором. Если вы включаете HTTP в std, вы не можете выпустить новую версию своего HTTP-клиента без выпуска новой версии std (т.е., по сути, без выпуска новой стабильной версии компилятора).
И да, HTTP, наверное, меняется довольно редко, но по такой логике можно захотеть втащить ещё кучу application-level протоколов. Это не сфера ответственности Rust. Это системный язык.
Если говорить конкретно, уже есть стандарт де-факто для HTTP — hyper. Просто потому что это первая достаточно полная достаточно стабильная реализация. Его не надо тащить в std, чтобы пользоваться им. При этом он всё же достаточно сложен, чтобы его нельзя было реализовать «очень быстро» и больше никогда не менять. Т.е. сам hyper сейчас активно развивается. Включение его в std сильно замедлило бы его развитие, потому что новые стабильные версии контейнера можно выпускать гораздо быстрее, чем новые стабильные версии std.
Если так интересно расширение std, вот курируемый список де-факто стандартных библиотек.
И да, HTTP, наверное, меняется довольно редко, но по такой логике можно захотеть втащить ещё кучу application-level протоколов. Это не сфера ответственности Rust. Это системный язык.
Если говорить конкретно, уже есть стандарт де-факто для HTTP — hyper. Просто потому что это первая достаточно полная достаточно стабильная реализация. Его не надо тащить в std, чтобы пользоваться им. При этом он всё же достаточно сложен, чтобы его нельзя было реализовать «очень быстро» и больше никогда не менять. Т.е. сам hyper сейчас активно развивается. Включение его в std сильно замедлило бы его развитие, потому что новые стабильные версии контейнера можно выпускать гораздо быстрее, чем новые стабильные версии std.
Если так интересно расширение std, вот курируемый список де-факто стандартных библиотек.
В сети есть видео одной конфы по программированию, где Страуструп представлял новые черты C++ 11. В конце он нарисовал два квадрата, большой и маленький, и сказал: «у C# и Java маленький квадрат — это размер языка, а большой квадрат — это размер стандартных библиотек. Для С++ все наоборот и это плохо, мы будем стремиться к увеличению объема и функционала библитек.»
Кстати, на Go есть игровые движки? На Rust есть Piston.
Есть, azul3d.org
Ну это вы перегнули. На Rust есть графические движки, да, и Piston стремится покрыть многие задачи именно игрового движка. Однако он суть просто набор библиотек, которым ещё долгий путь до настоящих движков. Давайте не торопить события.
Не понял.
Предоставляет полное ядро для написания игр? Предоставляет. Игры на нём делают? Делают. Значит движок.
Другое дело, что сопустсвующих инструментов там не особо, и игры делают пока любительские. Это не SDK вроде Unity и Unreal, это просто движок, хотя и любительский.
То что он побит на тучу библиотек в своих репозиториях — вообще не принципиально. Под одной крышей он их объединяет.
Предоставляет полное ядро для написания игр? Предоставляет. Игры на нём делают? Делают. Значит движок.
Другое дело, что сопустсвующих инструментов там не особо, и игры делают пока любительские. Это не SDK вроде Unity и Unreal, это просто движок, хотя и любительский.
То что он побит на тучу библиотек в своих репозиториях — вообще не принципиально. Под одной крышей он их объединяет.
Неа, полным ядром там пока и не пахнет. Игры «на нём» делают точно также, как и без движков — пишут свою логику. Автор и сам его движком с натяжкой называет. Всё-таки есть большая разница между большим движком, разбитым на слои/библиотеки, и разбросанным набором библиотек, которые хотят быть движком.
Есть ниши (встраиваемые системы, ОС, жесткий realtime) где Go трудноприменим, а Rust имеет шанс вытестить C++. С модой на «умные дома», «интернет вещей» и любительскую робототехнику эти ниши будут расширяться.
А заняв прочное место в них, Rust может постепенно отвоевывать и другие.
PS Лично мне код на Rust читать проще и приятнее, чем на Go. Хотя понимаю, что это мои заморочки — люблю pattern matching и ненавижу return.
А заняв прочное место в них, Rust может постепенно отвоевывать и другие.
PS Лично мне код на Rust читать проще и приятнее, чем на Go. Хотя понимаю, что это мои заморочки — люблю pattern matching и ненавижу return.
Go и Rust всегда будут кровными врагами и несколько печально признавать, что последний уже проиграл эту войну.
Даже в областях где критично отсутствие GC? Не думаю. Тут скорее интересно проиграл ли уже Rust плюсам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Go и Rust не соперники, а чертовы враги