Эта статья — небольшой ответ к записи в блоге Дейва Чейни «Почему 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 всегда будут кровными врагами и несколько печально признавать, что последний уже проиграл эту войну.
Комментарии (131)
splav_asv
16.07.2015 21:50+4В пересекающейся области Go действительно смотрится намного выигрышней. Но ведь есть области применения C++, где Go явно не следует использовать. Вот в них Rust крайне хорош. К примеру, не думаю, что кто-то серьезно будет писать под Cortex M на Go.
9mm
16.07.2015 22:06-1Совсем не факт, учитывая, что некоторые пихают на кортексы всякие JS, NET и т.п., а затем пытаются продать как более простой Arduino :)
splav_asv
16.07.2015 22:33+1Допускаю. Но это скорее рынок прототипирования. Там и помощнее SoC можно взять. И на скриптовом языке даже иногда написать всё. Но в серии это редко получается. Хотя, для IoT может и прокатить Go. Для относительно больших SoC.
namespace Автор
16.07.2015 22:10-9Что значит, серьезно писать? Что-то мне подсказывает, что сегодня мало кто станет серьезно писать под Cortex M на Rust. Я конечно не специалист, а скорее профан в этой области, но нестабильность стандартной библиотеки и высокий порог вхождения точно не очень играют на руку Rust в embedded разработке.
splav_asv
16.07.2015 22:40+6Речь про концепции языков. Динамической выделение памяти, и то часто не приветствуется. Не говоря про GC. В этом контексте Go проигрывает.
Стабильность библиотеки — для embedded не так выжна библиотека. Да и она сейчас достаточно стабильна. По крайней мере её нижний уровень, который и нужен по сути. Немного не хватает механизма выключения проверки границ массивов или его более умной версии, но это не совсемкритично.
Порог вхождения — в embedded и так высокий порог вхождения, сложность концепций языка не сильно испортит картину, как мне кажется. Зато по предсказуемости Rust даже превосходит C.VlK
16.07.2015 22:54-6М-м-м-м… А чего сложного в, эм, embedded разработке? Это, конечно, не странички в веб выплевывать, но все же.
kekekeks
16.07.2015 23:01+1Embedded разный бывает. Иногда есть 16 килобайт памяти и умещайся как знаешь.
Wedmer
17.07.2015 00:36+1Бывает, что памяти и еще меньше.
VlK
17.07.2015 09:41+1Да, конечно, мало памяти и все такое, надо выкручиваться довольно сильно. Но, с другой стороны, во встроенных системах имеется возможность плюс-минус полностью понимать все происходящее вплоть до железа, чего давно уже не встречается в программировании для ЦПУ.
Я не к тому, что жонглировать байтиками — дело вот прям тривиальное, а к тому, что *концептуально* оно не очень насыщенно.Wedmer
17.07.2015 10:43-2Просто для тех, кто не хочет учить ассемблер, сделали возможность писать на C. Некоторые прочат Rust и место C.
justaguest
18.07.2015 00:46+1(Не)желание учить ассемблер вообще не при делах. Просто читать код на С проще, чем читать код на ассемблере — следовательно и разработка легче. Например циклы на С становятся в ассемблерном коде кучей goto (исключая мелкие операции, к которым применим префикс повторения, если такой имеется). Кроме того, обычно нетрудно представить, во что превратит очередной кусок кода компилятор.
С другой стороны компилятор не человек, и может держать в памяти сразу весь код — особенно с link time optimization — что позволяет ему делать оптимизации вроде выкидывания неиспользуемого кода, встраивания функций, вследствие чего вновь выбрасывания кода.
NeoCode
17.07.2015 11:25+4Я 9 лет занимался embedded разработкой именно для таких контроллеров с 16 килобайтами (а то и меньше)… и надо сказать, для меня это всегда было проще чем «странички в веб выплевывать». Потому что здесь нужно знать только чистый Си (возможно С++) и иметь одну pdf-ку с описанием контроллера (порты, прерывания, периферия...). Иногда — еще пару pdf-ок с описанием внешних периферийных устройств.
Никакого бешеного изобилия фреймворков, API, библиотек и технологий, которые меняются с огромной скоростью:) Никакой проблемы выбора.Nikobraz
17.07.2015 17:11Согласен, но… есть один момент.
Количество MCU превышает количество веб-фреймворков.
В embedded надо мыслить гибче и понимать как оно на уровне железа работает, а у многих с этим проблемы.
Хотя не вижу разницы: писать всю жизнь под одно семейство MCU или на одном веб-фреймворке.
Сам ненавижу веб, в детстве тяжелая психическая травма нанесена веб-технологиями, спустя 8 лет тошнит. Даже Джанго пробовал учить, не помогает.
0xd34df00d
17.07.2015 16:10+1Иногда есть ещё меньше, пописывал я на плюсах для какой-то из attiny управлятор лазером. Нормально, вполне себе неплохо. А странички в веб выплёвывать терпеть вот не могу.
NeoCode
18.07.2015 13:53+1Со страничками в web такое дело — там кроме программинга нужен еще дизайн. Или делать в олдскульном стиле 80-х, без всякого css… или дизайн, а я ни разу не дизайнер, у меня вообще мозг не работает в этом направлении. GUI в десктопных приложениях все-же более-менее стандартизирован — стандартные меню, стандартные тулбары, стандартные диалоги… конечно если кому-то хочется сделать «не как у всех» то можно пользоваться специальными GUI-библиотеками, но меня всегда устраивал стандартный GUI, встроенный в ОС. Более того, я вижу в этом преимущество — не нужно каждый раз привыкать к новому виду кнопок, полей ввода и прочих элементов (и поэтому я также отрицательно/настороженно отношусь к десктопным программам с сильно нестандартным GUI)
Кстати были у меня железные проекты с ethernet на борту и настройкой через web-интерфейс. Так что выплевывал таки странички в web — прямо из железки.PHmaster
19.07.2015 12:58С gui под веб очень сильно выручают всякие там фрейморки типа bootstrap или foundation. Если говорить о веб-приложениях, разумеется.
js605451
16.07.2015 22:26+16Те, кто считает, что самая большая проблема C++ это его «небезопасная» природа… очень сильно заблуждаются. Самая большая проблема С++ заключается в том, что код на этом языке тяжело писать, читать, отлаживать, профилировать и поддерживать.
Самая большая проблема C++ — это отсутствие менеджера пакетов. В Go/Rust/Python/Ruby/JavaScript/Java/.NET вы находите подходящие инструменты и решаете задачу (ну может с Go и Rust я немного погорячился). В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента, и только после этого решаете задачу.namespace Автор
16.07.2015 22:56-8Понятно, что зависимости — это геморрой. С другой стороны, это не косяк языка С++, а его реализаций :)
areht
16.07.2015 23:16+15> С другой стороны, это не косяк языка С++, а его реализаций
Место проклятое©
То, что вы стрелки перевели не помогает на нём писать более лучше.
0serg
17.07.2015 00:44+3Неделя на подключение — это что-то очень специальное должно быть. Обычная либа подключается за час, сильно хитрая — за день. Основные проблемы возникают со сборкой, если есть бинарники (а они часто есть) то все делается влет. Только если либа почему-то отказывается собираться то можно серьезно застрять. Но все же из личных рекордов, два дня — на сборку буста интелом, и два — на хитрую математическую либу в винде которая требовала для себя тонну других либ, которые тоже требовали третьих либ, причем уже на Фортране. Неделя — это что-то очень экстравагантное должно быть. Типа подключения огра3д к проекту на c# :)
А вот отсутствие менеджера пакетов реально печалит, согласен. Для мелких проектов это не беда, а вот для энтерпрайза реально мешает жить.js605451
17.07.2015 12:23+1Обычная либа подключается за час, сильно хитрая — за день.
С порядком ваших оценок совершенно согласен, но обычно либа — не одна, отсюда и неделя вместо одного дня. А даже если вдруг одна, она обычно тянет за собой ещё парочку, а их сборка — опять же на ваших плечах.0serg
17.07.2015 16:10+1Ну так хитрая сборка с необходимостью тащить тонну зависимостей бывает далеко не только у проектов на плюсах. Подключение простой либы и в питоне и в плюсах пройдет с полпинка, а с хитрой возиться придется и там и там. Причем какой-нибудь хитрособираемый SuiteSparse SPQR кроме как на плюсах вообще и не найдешь еще.
Amomum
17.07.2015 02:20+5Имхо, самая большая проблема С++ — это чудовищный, запредельно запутанный Стандарт. В любом языке можно отстрелить себе ногу, но в С++ количество способов это сделать просто поражает.
И самое прелестное, что компилятор (если это не gcc c парой десятков добавочных флагов) практически не помогает, в лучшем случае предупреждение выдаст. Типа «no return statement in function returning non-void»; но скомпилировать — скомпилирует, чего уж там.
Очень много о чем приходится помнить или обвешиваться сторонними программами для проверок.VioletGiraffe
17.07.2015 11:52А решение же очень простое: не пишите код, который не понимаете.
namespace Автор
17.07.2015 12:01+8Решение — отстой. Не каждый поймет тот код, который написал ты. Надо писать такой код, который понимают все.
0xd34df00d
17.07.2015 16:11+1Написание такого кода не вызывает наслаждения :(
gandjustas
17.07.2015 21:07Почему в других языках такой проблемы нет?
0xd34df00d
17.07.2015 21:15В каких, например?
namespace Автор
17.07.2015 21:19Go.
gandjustas
17.07.2015 21:22+1Пока что для Go обратная ситуация — все подряд испытают наслаждение от написания кода на Go, а у тех, кто код читает никакого наслаждения это не взывает.
namespace Автор
17.07.2015 21:27Ерунда. Я и мои коллеги ежедневно читаем код на Go — полет нормальный, всем все нравится.
gandjustas
17.07.2015 21:20-1Например ни разу не слышал, чтобы кто-либо испытывал наслаждение или жаловался на его отсутствие при программировании на JS и python. Зато довольно часто слышу это про C++ и изредка про Java и C#.
0xd34df00d
17.07.2015 21:31+2У меня нет наслаждения от JS и Python, одни рвотные позывы, извините.
gandjustas
17.07.2015 22:03-1Видимо проблема не в языке, а в вас.
0xd34df00d
17.07.2015 23:13+2Отчего ж? На плюсах написать какой-нибудь шаблонный милый код — приятно, а от хаскеля вообще оргазм.
gandjustas
17.07.2015 23:36-4Ну так на js можно писать еще более обобщенный код, чем на c++ или хаскел.
Видимо проблема все-таки не в языке.0xd34df00d
17.07.2015 23:38+5Сомневаюсь, что получится более обобщённый код, чем на Haskell. По крайней мере, я бы на это посмотрел.
Может, туда и нормальную систему типов уже завезли?gandjustas
17.07.2015 23:58-4Динамическая типизация — самая выразительная система типов. Например в динамической системе типов можно написать нерекурсивный комбинатор неподвижной точки. А в статике — нельзя.
justaguest
18.07.2015 00:16+2gandjustas
18.07.2015 00:52-1UnsafeCoerce в хаскеле — проявления динамической типизации (отказ от контроля типов на стадии компиляции), а про powerset я ниче не понял.
Rayslava
17.07.2015 12:55+1Ну и собирайте, как положено. В случае с gcc:
-Wall -Wextra -Werror -ansi -pedantic
Amomum
17.07.2015 13:14Я примерно так и поступаю — я ограничил себя небольшим подмножеством С++ и за пределы его вылезаю редко. Но наступить на грабли все равно очень легко, можно ведь просто не знать о какой-нибудь замечательной особенности.
Вообще, когда только появился С, идея о «неопределенном поведении» была логична. Компиляторы были глупые, гораздо легче было переложить ответственность на программиста.
Но сейчас это уже ни в какие ворота.
potan
17.07.2015 14:17-1Ну и какой смысл иметь в языке возможности, которыми запрещено пользоваться?
Они же не совсем бесплатно даются, их наличие усложняет синтаксис разрешенных (что бы устранить неоднозначность), замедляет компилятор и дополнительные инструменты. Да и на управляемости проектов и наборе квалифицированных сотрудников такое решение отражается не лучшим образом.
Лучше выбрать более чистый язык.
dyadyaSerezha
21.07.2015 20:20+2Да, этот undefined behavior просто конкретно достает почти с каждой страницы, когда читаешь стандарт.
cdkrot
17.07.2015 19:39+2По-моему про "-Wall -Wextra" знают почти все C++ программисты.
Меня больше напрягает чудовищная сложность языка:
- declaring != defining, более того, увы, часто нужны оба.
- C'шному препроцессору тоже давно пора почить
- Unicode. Как вы помните, с юникодом дела не очень.
- Система типов. «Long имеет хотя бы 4 байта, и хотя бы такой же большой, как int» = отстой.
- Шаблоны, конечно, штука замечательная. Только если при использовании шаблонных классов (например STL) вы сделаете ляп в типах, то получите под сотню строк ошибок.
- Автомагическая генерация дефолтных конструкторов и пр. Готовы сходу ответить что генерируется и при каких условиях?
Я, конечно, очень радуюсь фишкам из C++11 и C++14, но чем дальше, тем сильнее осознаёшь этот ужас…gandjustas
17.07.2015 21:09Шаблоны, конечно, штука замечательная. Только если при использовании шаблонных классов (например STL) вы сделаете ляп в типах, то получите под сотню строк ошибок.
Справедливости ради — в последних компиляторах максимум пара ошибок вместо сотен.
tangro
17.07.2015 11:19Ну, возьмите biicode и будет вам менеджер пакетов.
VioletGiraffe
17.07.2015 12:11+1Поискал библиотеки со своего проекта (libusb, exiv2, libRAW, libtiff) — ничего нет. Те, что есть (SDL, POCO, cURL и т. д.) и так элементарно подключаются.
tangro
17.07.2015 12:22-1Ну так там есть только то, что кто-то уже туда добавил. Хотите добавить туда свой библиотеку — возьмите и добавьте.
js605451
17.07.2015 12:36+4Это нифига не будет работать до тех пор, пока разработчики библиотек сами не воспринимают этот biicode как основной репозиторий для публикации релизов. Энтузиасты приходят и уходят, поэтому завязываться на них — себе дороже.
tangro
17.07.2015 17:14+2А в мире С++ никаких «основных репозиториев» вообще быть не может. Нет одного мейнтейнера языка, нет одного «владельца» стандартной библиотеки, а значит и «главного» репозитория быть не может. Тем ни менее, может быть несколько «неглавных», среди которых со временем могут образоваться достаточно хорошие, решающие большую часть задач.
js605451
17.07.2015 17:48+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 день» — это нормально. Проблемой это становится только для людей, у которых есть опыт с экосистемами других ЯП.0xd34df00d
17.07.2015 19:22+2Лично для меня этой проблемы нет потому, что установка библиотеки — вопрос одной команды системного пакетного менеджера, а её подключение — вопрос 5 минут на поиск
FindFoo.cmake-файла либо его написание.js605451
17.07.2015 22:15+1А с Windows как быть?
0xd34df00d
17.07.2015 23:14+3Избегать всеми силами.
Ну или, когда я крайний раз сторонников возможности использовать Windows для разработки троллил, они мне говорили, что в Windows 10-то пакетные менеджеры уже есть, чуть ли не хуже портажей!..
HotWaterMusic
18.07.2015 00:05Сам Страуструп совсем недавно на выступлении сказал, что признает проблему отсутствия у коммьюнити центра своим большим недосмотром. Одна из причин — отсутствие затрат на маркетинг, которые могли бы позволить в свое время наладить обмен информацией между программистами, и библиотеками в частности. Правда, при этом он заметил, что существуют «маленькие империи», вполне себе неплохо живущие со своим набором библиотек и тулзов, причем у некоторых из них больше 100К пользователей.
justaguest
17.07.2015 23:06А меня еще удивило наличие в списке проблем отладки. Мне стало крайне интересно, в каком-то это языке отладка лучше, чем в С++. Я знаю — в порядке убывания знаний — С++, С#, Lisp, Bash, Haskell, Python. Мб что-то еще по мелочи — но из этого списка самая тяжелая отладка была в Bash. А самая простая отладка как раз таки в С++, о чем я не раз вспоминал, когда начал учить C#, и ушел с многофункционального gdb на студию и monodevelop.
Вот честно — я действительно не знаю, что еще можно прикрутить связке GCC + AddressSanitizer + GDB в принципе. Черт подери, да в GDB есть даже чекпойнты — имеется хоть где-нибудь еще такая штука?!0xd34df00d
17.07.2015 23:15asan, к сожалению, не всегда спасает, с парой таких случаев я встречался.
Но кроме этого недоразумения я с вами согласен, да. Субъективно, сложнее всего в Haskell отлаживать, за счёт ленивости, в основном, как по мне.
divan0
16.07.2015 22:47-1Жду следующую статью «Почему Go и Rust не враги, а друзья» с главным посылом о том, что Rust помогает Go избавить мир от C++ в тех нишах, где нужен ручной контроль памяти :)
Alexeyco
17.07.2015 11:06+11Почему Go и Rust не враги и не друзья, а языки программирования… или как перестать холиварить и пойти писать код.
inook
16.07.2015 22:48-8Посмотрел на Rust, посмотрел на Go и продолжил влюбляться в Crystal.
googol
17.07.2015 10:44Да, Crystal довольно интересная штука. Надеюсь авторы продожат пилить проект. К 1.0 должна получиться конфетка.
potan
17.07.2015 14:07Crystal, как альтернатива Nim, какое-то распространение может получить. Но вытеснять Rust и Go он врядли будет.
nwalker
17.07.2015 18:39+2Я не уверен, что стоит писать на языке, автор которого считает, что вызывать сторонние программы в компайл-тайме — норма.
BalinTomsk
16.07.2015 22:49-15----Самая большая проблема C++ — это отсутствие менеджера пакетов.
пакетов чего?
--В C++ вы находите подходящие инструменты, неделю их подключаете, ещё неделю пишете README по настройке dev энвайронмента
Не знаю в каком мире такое делается неделями, но в мире wintel VS/Borland никогда не занимает больше нескольких часов (Из моего опыта работы в больших компаниях).
iroln
17.07.2015 16:48+3Стоит посмотреть на CMake-конфигурации крупных проектов, чтобы прийти в ужас. Десятки каких-то специфических cmake-макросов, куча external-project зависимостей, зависящих друг от друга, десятки патчей. И всё это пишется каждый раз вручную и потом поддерживается разработчиками проекта. Пока в конфигурации сборки разбираешься, уже уйдет неделя. Нифига это не просто даже с таким удобным инструментом как CMake. В общем, всё очень плохо у C++ в этом плане.
BalinTomsk
17.07.2015 23:35-1Возможно в линухе так. Мой приятеь в Амазоне жаловался что ихний набор тулов C++ + Eclipse — это тихий ужас в настройке и использовании.
1. Конкретный пример — Blackberry Server на VC++. По TODO листу даже блондинка с улицы может за полдня может настроить машину и
сделать билд.
2. Другой примет Ricoh Enterprise Server на Java + Eclipse (Врагу не пожелаю) — сборка и настройка билда 3-4 дня минимум для продвинутого жабника.
Так что я полагаю дело лишь в затейливости идей тех кто создавал среду и зависимости.
SuicideBlonde
16.07.2015 23:04+9А разве Go настолько назкоуровниевый как Rust? Их вообще корректо сравнивать?
david_mz
16.07.2015 23:16В Go при желании можно спуститься на довольно низкие уровни (до адресной арифметики и ассемблера), хотя язык и будет сопротивляться. Но сравнивать их действительно не корректно.
Keyten
17.07.2015 00:45К слову, о многих языках это слышал.
На C++ сложно создавать и поддерживать программы!
На JavaScript сложно создавать и поддерживать большие программы!
И т.д.potan
17.07.2015 13:54К сожалению, удобство разработки и поддержки больших программ мало сказывается на популярности языка, в том числе и в больших проектах.
Учатся начинающие программисты на меленьких, большая часть проектов не слишком велики. Потом и библиотеки для языков с низким уровнем вхождения плодятся. А потом и в серьезных проектах используют то, к чему привыкли.
Alexeyco
17.07.2015 10:55+1> Области применения часто пересекаются (серверный софт, системные утилиты, итд)
Однако же, нельзя не отметить два момента.
1. Когда начинаешь писать на go, нельзя не отметить, что существенное количество статей о go написаны иероглифами. Иными словами — в стране восходящего солнца почему-то очень полюбили go.
2. На go больше сетевых утилит (веб-фреймворков и т.д.), в то время как rust-сообщество ринулось в графику, разные там парсеры, нейронные сети…
Не хорошо это и не плохо, и чисто умозрительно… и возможно, я где-то неправ. Но go приглянулся практикам, а rust — теоретикам.
northicewind
17.07.2015 13:58+2А почему вы всех, кто занимается программированием графики отнесли к теоретикам? Вполне себе практические задачи. И, допустим, в разработке игр С++ — это стандарт, и его вряд ли что заменит, но если будет альтернатива для разработки новых проектов, будет замечательно. Вот народ и проверяет насколько Rust — альтернатива.
Alexeyco
17.07.2015 16:10+1Нет, я не относил. Вы не так поняли. Я о том, что пока чего-то готового нет. И пока что это все experimental. Я же написал, что все умозрительно и я могу ошибаться.
zolkko
17.07.2015 14:14-2Тоже чисто умозрительно, go обязан своей популярности докеру. И складывается впечатление, что в подобный «докер» из rust мира пророчат servo, который в firefox даже не планируется внедрять. Вот и остаются с rust одни теоретики.
CONSTantius
17.07.2015 14:30+1В Firefox внедрять его не слишком много смысла. На данный момент Servo — исследовательский движок, вокруг которого скорее всего придётся строить новый браузер, чтобы хорошо использовать его многопоточность, например.
В то же время, Servo использует кучу существующих библиотек на C++ и да, Rust это «исследовательский язык для Servo». Но когда-то C был «исследовательским языком для Unix», просто никто не клеймил его такими ярлыками, потому что решение задачи в программировании — очень часто исследование.
splav_asv
17.07.2015 14:39+2Судя по github.com/servo/servo/wiki/Roadmap, в Gecko его как раз очень даже собираются внедрять. Что качается Firefox — судя по презентации events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf#page=37 собираются(-лись ?) сделать тестовую версию Firefox mobile под Android с Servo под капотом.
CONSTantius
17.07.2015 14:42О, интересно. Я видел, что они недавно какую-то штуку на Rust интегрировали в Gecko, но не думал, что это в рамках их плана постепенно всё заменить.
CONSTantius
17.07.2015 14:34-1Go стабилизировался 3 года назад, Rust — 2 месяца назад. Конечно, для Go будет написано гораздо больше продуктовых вещей.
При этом для Rust уже есть сетевой стек, который вполне можно использовать — hyper, rustc-serialize, rust-postgres. Я этим пользовался для переписывания простого серверного приложения на Go — всё получилось, никаких принципиальных проблем. В целом же, вот статус сетевого стека для Rust.namespace Автор
17.07.2015 15:10-7Можно вопрос? В 2015 году, в стандартной библиотеке современного языка Rust есть HTTP-клиент?
CONSTantius
17.07.2015 15:39+5Нет.
Моё мнение (совпадающее с мнением некоторых разработчиков Rust) — в стандартной библиотеке должен быть необходимый минимум вещей, у которых есть гарантированно оптимальная или общепринятая реализация (что называется, non-controversial и не opionated). HTTP-клиент к ним не относится.
Встречный вопрос: у вас есть как минимум 1 нормальный HTTP-клиент вне стандартной библиотеки; зачем его тащить внутрь?namespace Автор
17.07.2015 18:16-7Я все понял. Если вы считаете, что в 2015 году, в стандартной библиотеке современного языка программирования не должно быть HTTP-клиента (не сервера, всего лишь клиента), то я думаю, что дальше спорить совершенно бесполезно.
senia
17.07.2015 18:36+5Поделитесь секретом: Зачем в стандартной библиотеке языка общего назначения HTTP клиент? Не REST, не SOAP, не что-то еще, а HTTP клиент. Я не представляю что им там можно делать. Разве что тесты писать, но это уже к тестирующим фреймворкам.
На мой взгляд HTTP-клиент — это самое бесполезное, что можно засунуть в стандартную библиотеку. SMTP и то осмысленнее, хотя тоже не надо.namespace Автор
17.07.2015 18:44-5Что значит, «стандартная библиотека общего назначения»? В 2015 году софт чуть более, чем никогда не работает standalone, а так или иначе ходит в сеть. Ты хочешь сказать, что это не общая задача? Давай тогда из stdlib в плюсах и контейнеры к чертовой матери выкинем, это же не для общего назначения — хеллоуворлды и без них писать можно.
senia
17.07.2015 19:12Спокойно, не нервничайте.
Да, софт взаимодействует в том числе по сети. Это REST, это SOAP, это тьма других стандартов. Но это точно не HTML.
HTTP-клиент это крайне специфичный инструмент, который мало кому нужен.namespace Автор
17.07.2015 19:15+1Я где-то говорил про HTML?
senia
17.07.2015 19:29+1Нет, но все-же зачем в стандартной библиотеке HTTP клиент общего назначения? С поддержкой всех стандартных хедеров, включая Cookie?
Если это будет недоделанный клиент, то зачем его помечать в стандартную библиотеку — он недоделанный.
Полноценный же клиент совершенно логично поместить в отдельный проект, а не в стандартную библиотеку.
Да и для сетевого взаимодействия он не нужен — он избыточен и при этом слишком низкоуровневый — никто голым HTTPне пользуется, пользуются протоколами над HTTP.
Имело бы смысл реализовать ограниченную часть HTTP для REST, например, но не называть это HTTP клиентом. Но опять же хорошей реализации не получится. Да и протоколов слишком много. Это далеко не только REST с XML и JSON. Это и SOAP и многое другое. Зачем все это пихать в стандартную библиотеку?namespace Автор
17.07.2015 19:34+2Как это никто не пользуется голым HTTP? Я вот пользуюсь. Читаю из ответа байтики, потом десериализирую их в JSON и работаю со своим REST.
senia
17.07.2015 20:05Я надеюсь вы отделили чтение байтиков и десериализацию их в JSON от бизнеслогики?
Тогда поздравляю, вы написали кастомный REST-клиент. Зачем вы это сделали при наличии огромного количества существующих REST-клиентов я не знаю, но вам виднее.
Только почему вы считает задачу написания REST-клиента стандартной я не представляю.gandjustas
17.07.2015 21:14+1А чем HTTP-клиент отличается от REST-клиента?
senia
17.07.2015 21:37+2Уровнем абстракции.
HTTP-клиент должен поддерживать HTTP и предоставлять к нему доступ, REST-клиент не обязан (хотя и может опционально дать доступ, например, к некоторым хедерам).
Но главное различие: HTTP-клиент предоставляет доступ к body как к потоку байт, а REST-клиент предоставляет уже типизированный доступ к десериализованным объектам и проводит сериализацию объектов в body.
REST-клиент реализует узкий набор набор задач на подмножестве протокола HTTP, предоставляя удобные инструменты для этого набора задач.
В зависимости от реализации REST-клиент может использовать какой-то HTTP-клиент (а может и не использовать в целях снижения размера, например).gandjustas
17.07.2015 22:09+1А откуда вы узнаете к каким хидерам надо давать доступ в rest клиенте?
Если рест-сервис отдает набор байт, то что будет на клиенте?
namespace Автор
17.07.2015 19:17+1Что REST, что SOAP, оба зачастую работают over HTTP. Я все еще не улавливаю ход мысли.
0xd34df00d
17.07.2015 19:27+2Я пишу софт, который бывает чуть более, чем никогда, окей.
Вот длинная арифметика или сокеты в стандартной библиотеке моего языка мне бы не помешали, да. Но длинной арифметике там на самом деле не место.namespace Автор
17.07.2015 19:32-1Действительно, зачем длинная арифметика в стандартной библиотеке, она же вообще никому не нужна. Кто пользуется длинной арифметикой? Какая криптография, о чем вы? Совершенно бесполезная и, что говорится, excessive штукотень!
0xd34df00d
17.07.2015 19:39+2А какой бекенд? mpfr? gmp? Своя реализация?
Если у вас криптографию массово пишут обычные программисты, то это либо очень специфичная криптографическая фирма, либо грош цена вашей криптографии, потому что это не та область, куда можно просто так придти и писать.
Зато почти во всех моих приложениях мне нужны методы оптимизации. Или language models. Или хотя бы такие примитивы, как bloom-фильтр. Срочно его добавить! И структуру для поддержания обратного индекса добавить! И Левенберга-Марквардта, куда же без оптимизаций-то всё-таки! И SVM, нейросети да генетику ещё для полного счастья!namespace Автор
17.07.2015 19:57+1Все что вы назвали — это узкоспецифические алгоритмы, которые нужны для тех или иных редких задач. Большие числа куда чаще приходится считать.
splav_asv
17.07.2015 20:26+5Http в стандартной бибилиотеке означает почти полную его заморозку. Либо несколько версий, добавляемых время от времени. См Python, к примеру. Для скриптового языка или языка, метящего в web — http клиент в stdlib наверное правильно, но для языка общего назначения лучше иметь хорошую внешнюю регулярно обновляемую библиотеку.
miolini
18.07.2015 11:55Секрет прост. Это влияет на разработку других библиотек, которые используют http клиент. Каждый постарается написать свой велосипед. Что и происходит в С++. С которым Rust пытается тягаться. Совпадение? Не думаю.
В 2015 году действительно стыдно не иметь такой функционал. Сходите на GitHub Trending и посмотрите какое количество проектов не связано с сетью.
Ссылка:
github.com/trending?l=rust&since=monthlyCONSTantius
20.07.2015 15:47+4В стандартной библиотеке должно быть только то, что не меняется практически никогда и поэтому может жёстко версионироваться одновременно с компилятором. Если вы включаете HTTP в std, вы не можете выпустить новую версию своего HTTP-клиента без выпуска новой версии std (т.е., по сути, без выпуска новой стабильной версии компилятора).
И да, HTTP, наверное, меняется довольно редко, но по такой логике можно захотеть втащить ещё кучу application-level протоколов. Это не сфера ответственности Rust. Это системный язык.
Если говорить конкретно, уже есть стандарт де-факто для HTTP — hyper. Просто потому что это первая достаточно полная достаточно стабильная реализация. Его не надо тащить в std, чтобы пользоваться им. При этом он всё же достаточно сложен, чтобы его нельзя было реализовать «очень быстро» и больше никогда не менять. Т.е. сам hyper сейчас активно развивается. Включение его в std сильно замедлило бы его развитие, потому что новые стабильные версии контейнера можно выпускать гораздо быстрее, чем новые стабильные версии std.
Если так интересно расширение std, вот курируемый список де-факто стандартных библиотек.dyadyaSerezha
21.07.2015 21:20В сети есть видео одной конфы по программированию, где Страуструп представлял новые черты C++ 11. В конце он нарисовал два квадрата, большой и маленький, и сказал: «у C# и Java маленький квадрат — это размер языка, а большой квадрат — это размер стандартных библиотек. Для С++ все наоборот и это плохо, мы будем стремиться к увеличению объема и функционала библитек.»
CONSTantius
17.07.2015 15:47Кстати, на Go есть игровые движки? На Rust есть Piston.
namespace Автор
17.07.2015 18:17+3Есть, azul3d.org
CONSTantius
17.07.2015 22:26А вам известны игры на нём?
Ни у них на сайте, ни в поиске ничего (совсем) релевантного не нашёл. Есть примеры от создателей, но я всё же про сторонние игры.
kvark
17.07.2015 19:04Ну это вы перегнули. На Rust есть графические движки, да, и Piston стремится покрыть многие задачи именно игрового движка. Однако он суть просто набор библиотек, которым ещё долгий путь до настоящих движков. Давайте не торопить события.
CONSTantius
17.07.2015 22:23Не понял.
Предоставляет полное ядро для написания игр? Предоставляет. Игры на нём делают? Делают. Значит движок.
Другое дело, что сопустсвующих инструментов там не особо, и игры делают пока любительские. Это не SDK вроде Unity и Unreal, это просто движок, хотя и любительский.
То что он побит на тучу библиотек в своих репозиториях — вообще не принципиально. Под одной крышей он их объединяет.kvark
17.07.2015 22:28+1Неа, полным ядром там пока и не пахнет. Игры «на нём» делают точно также, как и без движков — пишут свою логику. Автор и сам его движком с натяжкой называет. Всё-таки есть большая разница между большим движком, разбитым на слои/библиотеки, и разбросанным набором библиотек, которые хотят быть движком.
potan
17.07.2015 13:43+4Есть ниши (встраиваемые системы, ОС, жесткий realtime) где Go трудноприменим, а Rust имеет шанс вытестить C++. С модой на «умные дома», «интернет вещей» и любительскую робототехнику эти ниши будут расширяться.
А заняв прочное место в них, Rust может постепенно отвоевывать и другие.
PS Лично мне код на Rust читать проще и приятнее, чем на Go. Хотя понимаю, что это мои заморочки — люблю pattern matching и ненавижу return.
Drox
17.07.2015 16:26+3Go и Rust всегда будут кровными врагами и несколько печально признавать, что последний уже проиграл эту войну.
Даже в областях где критично отсутствие GC? Не думаю. Тут скорее интересно проиграл ли уже Rust плюсам.
Semmaz
Кстати, показательна реакция реддита на сстатью ;)
К примеру:
namespace Автор
Комментарий про HBO и вправду очень смешной, особенно учитывая то, что по теме «Go vs Rust» за последний месяц было штук пять статей/заметок.