Опубликован релиз языка системного программирования Rust 1.38, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51572
Имеет ли смысл учить плюсы или сразу с паста начать?
имеет, как раз выучишь плюсы к тому времени как раст станет мейнстримом
+1
Ты второй плюс потерял. Правильно будет 1++
Плюсовики любят именно ++1.
он не станет мэйнстримом
Если плюсы не спохватятся и не добавят себе фишки Rust в плане безопасности, то у Rust есть все шансы, чтобы стать мейнстримом.
Умные указатели в плюсах уже давно есть. По сути раст отличается наличием мощного анализатора, встроенного в систему сборки. А вот с последним в плюсах сложнее, так как тянет груз обратной совместимости с Си.
Одно из ключевые отличия от крестов -- наличие пакетного менеджера и быстрый цикл разработки Rust и его обвязок
На С++ ты можешь выбрать себе любой пакетный менеджер. И любую обвязку. Да даже если у тебя приложение упадет с сегфолтом ты всегда можешь нанять кучу тестировщиков. Вместо того чтобы юзать раст, на котором ты даже не найдешь программистов.
Лоол)
Да ты гонишь.. Это программисты не могут найти работу на раст. А вот как раз таки желающих много..
Бедные-бедные хайпожоры... Они-то выучили очередного "убийцу cpp", но тут *внезапно* оказалось что работы на нём нема... Це есть диалектический неизбежный переход перемоги в зраду.
А кто там предыдущим убийцей С++ был? Java?
А что не так с Java? Жирнющий кусок ынтерпрайз-проектов у плюсов отгрызла. Убивать плюсы изначально даже не собиралась, ЯП из совсем другого сегмента использования.
Не, мне интересно узнать какие убийцы убийцы плюсов уже были, если раст - очередной.
Лол, это очень хорошо иллюстрирует что будет с рустом через лет пять - большинство его даже тупо не вспомнят.Как минимум это были жабка, ocaml и D. Первая ведь изначально она нацеливалась на "generic purpose", осетра пришлось сильно урезать и получилось занять только нишу в энтерпрайзе. С недавних пор ещё и мобилки. Последние двое формально до сих пор живы (и на них даже есть какой-то рабочий софт), но изначальной цели не достигли.
> С недавних пор ещё и мобилки.https://en.wikipedia.org/wiki/Siemens_SL45
> debuted in 2001
> SL45i, was also the first phone to have a Java virtual machine.Хорошо быть опеннетч^W макклаудом, 18 лет -- недавно :(
Если что:
На не слишком дорогом (по тем меркам, по современным смартфоноценам -- вообще дешевка)
телефоне 2004 года уже запускалась куча игрулек на жабке и пара приложений.
Изучение Rust сделало меня лучше в С++, так что о потраченом времени не жалею абсолютно. А насчет "работы нема" и "очередной убийца срр" - рано еще смеятся. С++ точно не умрет в близжайшие лет 10, но и Rust, уверен, свою нишу займет.
С++ не умрёт ещё долго. И это нормально. Просто некоторые плюсовики считают, что получить звание аналогичное званию программиста на Cobol - это плохо.Как бы непонятно, от чего у некоторых плюсовиков так горит от Rust. На их миску никто не покушается.
Вы что, на солнечном языке разговариваете?
Чувак ты походу фанатик и не умеешь в причинно-следственную связь. Хорошо что в С++ таких как ты нет.
> По сути раст отличается наличием мощного анализатора, встроенного в систему сборки.Раст отличается системой типов, предотвращающей некоторые ошибки. Различие в том, что статический анализатор пытается обнаружить что может пойти не так, с неизбежными ложными тревогами или пропущенными целями, а система типов может гарантировать отсуствие некоторых типов ошибок.
Щас понабегут и расскажут вам, что всё это от лукавого, просто нужно без ошибок писать
Все знают, что канализационные люки не нужны, просто под ноги смотреть нужно.
Меня это тоже удивляет. Против канализационных люков никто не возражает, а возгласы "Тирания компилятора!" переходящие в "Если я напишу unsafe, то это будет ничем ни лучше, чем если весь код unsafe" раздаются с дивной регулярностью.
> Умные указатели в плюсах уже давно есть.Когда умных програмистов подвезут - тогда и приходи.
+1000 into karma!
Ещё как станет. Уже через 5 лет. Скринь.
> Ещё как станет. Уже через 5 лет. Скринь.а где он станет мэйнстримом? вместо чего?
>> Ещё как станет. Уже через 5 лет. Скринь.
> а где он станет мэйнстримом? вместо чего?Много где. От ОС до веб-сервисов.
> а где он станет мэйнстримом? вместо чего?Где — не знаю, может быть и нигде. Но очевидно, что если станет, то именно вместо плюсов.
>> а где он станет мэйнстримом? вместо чего?
> Где — не знаю, может быть и нигде. Но очевидно, что если
> станет, то именно вместо плюсов.а плюсы в мейнстриме?
А на чём написан браузер из которого ты это пишешь?
> А на чём написан браузер из которого ты это пишешь?сишка? (firefox)
Он не может СТАТЬ мэйнстримом, потому что он уже им СТАЛ
> Он не может СТАТЬ мэйнстримом, потому что он уже им СТАЛгде?
В манямирке растофанов, очевидно же.
> выучишь плюсы к тому времени как раст станет мейнстримомНе выучит. Выучить плюсы невозможно.
Значит раст и не станет мейнстримом. Все будут продолжать учить плюсы и никогда не доучат.
мозилльное мейнстримом не становится
рождённый ползать - летать не может
эт ты толстанул… жырненько так
Смотря для какой цели учить. Если для продакшена - то плюсы, так как раст в этом плане пока что редкий гость. Если на будущее и just for fun - раст.
для чего?
>или сразу с паста начать?Начни с копипаста.
Лучше начать с C. Он проще и ближе к тому как все устроено. А потом уже можно постепенно открывать для себя абстракции, которыми так переполнены плюсы. А раст наверное нужно учить, когда тебя реально достанут сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках. Вот тогда можно и на раст посмотреть, чобы было с чем сравнивать)
А раст наверное нужно учить, когда тебя реально достанут сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках. - по моему опыту чаще происходит профессиональная деформация: первое время пугает, а потом начинаешь жить с этим.по моему опыту сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках это те проблемы, которые можно решить в относительно короткое время - хуже всего если ошибка в алгоритме.
> по моему опыту сегфолты, утечки памяти, неопределенное поведение, неадекватные сообщения об ошибках это те проблемы, которые можно решить в относительно короткое времяТы везучий. Мне приходилось и по два дня сидеть, отлавливая причину сегфолта. Ну, то есть, разадресация NULL как причина находится легко, но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_!!!, то значит реальная причина сегфолта где-то в другом месте, в том коде который записал в этот указатель NULL. А это может быть, если по-хорошему, вообще любой кусок кода. Конечно, с большей вероятностью, проблема в каком-то куске кода который явно работает с этим указателем. Но это не всегда так, иногда этот кусок кода берёт другой якобы ненулевой указатель и записывает его сюда, но указатель оказывается нулевым, то есть проблема не здесь, где в указатель записывается NULL, а там откуда этот NULL пришёл. А иногда, какой-то совершенно левый код ошибается с индексом массива, вытаскивает из стека совершенно не тот указатель, который хотел, интерпретирует его как указатель на какую-то структуру, работает с ней, производит несколько рандомных изменений кучи, и так случается что сам при этом не сегфолтится и перезаписывает твой указатель нулём.
Такие штуки неплохо отлавливает valgrind, но только если он не зафлуживает при этом весь вывод руганью на libc или на ещё на какую-нибудь интересную библиотечку, которую ты подключил депендансами.
но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_ - то можно поставить бряк на модификацию этого указателя.А это может быть, если по-хорошему, вообще любой кусок кода. - не согласен. в худшем случае это код, который пишет в память в пределах одного процесса.
А иногда, какой-то совершенно левый код - если у Вас в проекте появился совершенно левый код, то это повод для беспокойства вне завимости от языка.
Вах, зачем так много пишешь?! Достаточно - УВР!!!!
> но если в коде при этом разадресуется указатель, который _никак_не_может_быть_NULL_
> - то можно поставить бряк на модификацию этого указателя.Если ты знаешь где он находится. Что далеко не всегда так, он может находится в куче, и при разных запусках программы иметь разные адреса. Или у тебя может быть десять тысяч указателей, один из которых оказывается нулём. Причём каждый раз -- разный. С этим можно бороться поработав над повторяемостью выполнения программы с точностью до точного порядка инструкций и до каждого бита в каждом куске памяти любого типа -- будь то RAM, кеши или регистры, но это само по себе иногда может отнять неделю.
> А это может быть, если по-хорошему, вообще любой кусок кода. - не
> согласен. в худшем случае это код, который пишет в память в
> пределах одного процесса.Хорошее уточнение.
> А иногда, какой-то совершенно левый код - если у Вас в проекте
> появился совершенно левый код, то это повод для беспокойства вне завимости
> от языка.Слово "левый" было использовано в смысле "занимающийся чем-то иным". Я описал пример тому, как это может выглядеть, и я не очень понимаю почему теперь, мне приходится пояснять это ещё раз.
Если ты знаешь где он находится. - после того как Вы попали в исключение, то Вам уже известно какой поток, состояние регистров и стека. Чаще прочего этого достаточно чтобы определить, где проблема.Понятное дело, что может быть код, который случайным образом портит память: но такой код, как правило, сам довольно быстро вызывает исключения и всё становится более менее понятно.
с точностью до точного порядка инструкций - если нужно писать с точностью до порядка инструкций, то я пишу на ассемблере.
я редко пишу на ассемблере.Слово "левый" было использовано в смысле "занимающийся чем-то иным". - я неправильно Вас понял. Предположил, что под левый код мы понимаем плохо документированный код, который попал в проект под давлением бизнеса(резко понадобилась функциональность и наскоро где-то что-то купили и вставили).
У меня наибольшие проблемы возникали когда время от времени программа неправильно работает(и никто толком ни в чем не уверен). Ничего не падает, но вроде бы иногда работает неправильно. И думай что-хочешь.
> Если ты знаешь где он находится. - после того как Вы попали
> в исключение, то Вам уже известно какой поток, состояние регистров и
> стека. Чаще прочего этого достаточно чтобы определить, где проблема.Чаще всего да. Но бывает ситуация, что проблема вылезла из-за повреждённой структуры данных. То есть весь код, чьи стековые фреймы активны -- совершенно корректный, но поскольку он исходит из (разумного) предположения что структура данных следует определённым правилам, то когда он напарывается на повреждённую структуру данных, он начинает пороть чушь.
> Понятное дело, что может быть код, который случайным образом портит память: но
> такой код, как правило, сам довольно быстро вызывает исключения и всё
> становится более менее понятно.
> с точностью до точного порядка инструкций - если нужно писать с точностью
> до порядка инструкций, то я пишу на ассемблере.
> я редко пишу на ассемблере.Я не о том. Если у тебя есть сегфолт, то первый шаг к его устранению -- это умение гарантированно его получить. Запустить программу с такими аргументами, чтобы она упала в сегфолт. Идеально, если при этом программа, каждый раз выполняет ровно одну и ту же последовательность инструкций -- не важно какую, важно чтобы она не менялась от запуска к запуску. Но это не всегда работает, скажем многопоточная программа может делать не так. Программа полагающаяся на генератор случайных чисел, будет иметь разные пути вполнения при разных запусках. Программа работающая асинхронно с несколькими источниками данных будет выполнять разные последовательности инструкций при разных запусках.
> У меня наибольшие проблемы возникали когда время от времени программа неправильно работает(и
> никто толком ни в чем не уверен). Ничего не падает, но
> вроде бы иногда работает неправильно. И думай что-хочешь.Угу. Это ещё хуже, потому что нет точного критерия "программа сработала неправильно". Сегфолт по-крайней мере окончателен. Но представь себе, что какая-то часть программы иногда работает неправильно, а другая часть иногда на это неправильно реагирует сегфолтом. И при этом неправильное поведение остаётся внутри программы незамеченным, если не было сегфолта. А если при этом неправильное поведение случается при каком-нибудь очень интересном стечении обстоятельств, которое происходит с частотой 0.0001, то есть один раз из 10000. И мало того, оно зависит от чего-нибудь, что меняется от запуска к запуску -- показания часов, состояние генератора случайных чисел, скорость чтения с жёсткого диска, переключение задач в точно заданный момент, обрыв tcp-соединения между входящими килобайтами с номерами 128*k+31 и 128*k+32 для любого целого k>0, или ещё что-нибудь в этом роде.
Представь себе это. Чуешь как интересно будет отлаживать? Особенно если ты не знаешь всех этих особенностей бага до того, как начал его ловить.
то есть, тестов нет. Ни юнит, ни функциональных. Я прав?
> то есть, тестов нет. Ни юнит, ни функциональных. Я прав?Тесты снижают вероятность такого, но не изничтожают её. И да, это если они есть. Тесты, например, плохо умеют в data-race'ы. Крайне плохо. Тут разве что fuzzing может помочь, и то я не знаю, насколько он может помочь: я не пробовал им искать data-race'ы.
Одно из основных правил написания тестов, которое повторяется чуть ли не в каждом руководстве: если вы нашли баг, то первым делом напишите тест, который при наличии этого бага сфейлится. И только после этого исправляйте баг, чтобы тест перестал бы фейлится. Это правило нам явно указывает на то, что тесты подчастую пишутся задним числом, то есть не для того, чтобы избегать багов, а для того, чтобы не наступать на те же самые грабли дважды.
> хуже всего если ошибка в алгоритмеВроде бы язык, который от этого помогает, ещё не изобрели. Или я что-то пропустил?
Ещё хуже, если ошибка - на генном уровне, а чел в программинг попёрси, да ещё и течёт постоянно, как сучка, как только речь про плюсы заходит.
Будто бы пролистывание пары книжек по Си++ и участие (по чьей-то глупости или недосмотру) в паре Си++ проектов исправит эту ошибку генах...
Скорблю.
Не начинай с сей, иначе будешь потерян для общества: начнёшь переизобретать строки, списки, классы…
Плюсы. Раст после плюсов одно удовольствие учить, а плюсы после раста будет сложно.
Только плюсы и надо учить. Раст тебе никогда нигде не пригодится.
Зависит от того, насколько вы уверены в успехе Rust, собираетесь ли вы на нём писать профессионально и понравится ли вам вообще на нём писать. Прямо сейчас работу на нём вы вряд ли найдёте (впрочем, прямо сейчас вы его и не знаете). Будущее никто наперёд не знает. Я лишь могу говорить о своём опыте, и он в случае с Rust весьма положителен. Как и у всех, у меня ушло порядочно времени, чтобы освоится с его семантикой, особенно с borrow checker, но это того стоило. Знаете, мне это напомнило знакомство с git после svn. Я не к тому, что C++ отстал от жизни (хотя некоторая доля правды в этом есть), просто сначала тоже многое непривычно и непонятно: зачем так сделано, почему компилятор постоянно вставляет палки в колёса, неужели нельзя сделать проще? Но потом наступает "просветление", и внезапно понимаешь, что это не палки в колёса, а этакий аналог муштры от мудрого наставника, необходимой для сдвига парадигмы и разрушения застоявшихся шаблонов. Когда долго занимаешься одним и тем же, "глаз замыливается" и становится сложнее даже представить себе, что задачи можно решать другими способами.В общем, если вы рассчитываете зарабатывать прямо сейчас, ваш выбор - C++. Но нужно понимать, что язык настолько сложен и полон исторического багажа, что у вас уйдёт несколько лет, чтобы писать на нём не полное гуано. Впрочем, это не всегда проблема - особенно, если вы пойдёте в геймдев: там и до вас такого понаписано, что диву даёшься, как оно вообще работает. Но если поднапрячься, можете заниматься действительно крутыми вещами, так как есть, из чего выбирать, вакансий полно.
Ну, а если у вас уже есть источник заработка, то изучайте Rust. После освоения основ прогресс пойдёт быстрее, и совершенно точно нервы себе сбережёте на отладке. После C++ это удивительно, но за всё время использования Rust отладчиком почти не пользовался. Скажем так, отлаживать падения и порчу памяти - это удовольствие для особых ценителей, и с Rust вам это не грозит с вероятностью 99.5%. Ну, и в целом писать на нём приятнее, гораздо меньше острых углов.
Два чаю этому просветлённому.
ООП тебя погубит в крестах как и в других недоООП языках, те же кресты функциональщину вводят, так как объекты провалились, но еще долго будут жить как COBOL
я бы начинал с раста
До появления хруста я был уверен, что более негодный синтаксис, чем у Брейнфака и прочей «эзотерики», изобрести невозможно.
Но после появления раста, так случилось, что вы нашли что-то более эзотерическое, чем Brainfuck?
LISTEN TO ME VERY CAREFULLY methodName
I NEED YOUR CLOTHES YOUR BOOTS AND YOUR MOTORCYCLE arg1
I NEED YOUR CLOTHES YOUR BOOTS AND YOUR MOTORCYCLE arg2
GIVE THESE PEOPLE AIR
[Statements]
HASTA LA VISTA, BABY
Диалект COBOL-а?
Это всего лишь креатив на сишном макропроцессоре - ArnoldC.
Можешь привести пример негодного синтаксиса, объяснить в чём негодность?
умею в питон говнокодить средние проекты, насколько долго переучиваться?
Мы все проекты потихоньку переводим с пистона на го. Раст тебе решительно ни к чему да и базы тебе наверняка не хватит.
наавсегда.
В течении года, можно норм освоить.
Начни с того, зачем тебе это. Язык - всего лишь средство решения определенного круга задач. "Стрелять из пушки по воробъям" и "выпиливать лобзиком по чугунию" - первый признак непрофессионализма.
> умею в питон говнокодить средние проекты, насколько долго переучиваться?На метлу/швабру/вантуз - год-два...
Изучения и практика на rust оч. полезна сишникам (с плюсами тоже), как минимум потому, что здорово вправляет мозги на правильную (корректную и быструю) работу с памятью.
Если не сложно, то можно немного подробнее? Правда очень интересно.
Открой растбук и читни. Он на русском уже есть
Максимум что ты от этих безумных фанатов дождёшься - это магическое заклинание "читай растобук".
А по си книжки читать не надо? херак-херак и оно само сегфолт?
За описанием *достоинств* си - не надо, его распространение, и многочисленные *неудачные* попытки закопать няшную сишечку говорят сами за себя. А причину большинства сегфолтов ищите в зеркале и кривизне культяпок.
ещё один "пищите без ошибок"
Когда научитесь писать на русте без unsafe - возвращайтесь.
Вообще на расте небезопасные блоки стараются всеми способами обходить.То есть, если у вас нет небезопасных блоков в коде то вы гарантированно не натолкнётесь на
- сегфолт
- гонки за данные
- разыменование пустого указателя
- выход за границы области памяти с дальнейшим продолжением выполненияНо си++ программистам ведь неведомы такие проблемы, они же без ошибок пишут
https://blog.regehr.org/archives/1520также, "повоевав" с borrow checker в rust и сделав всё корректно, можно понять что такое "владение", зачем нужно перемещение, ссылки и когда лучше использовать копирование (при этом в rust обязательно явно указать что надо копировать - через вызов .clone() плюс #derive(Copy) - только не надо этим злоупотреблять, скорость сильно просаживает).
с плюсами всё грустно, там ОЧЕНЬ сложно понять работает ли копирование объекта или перемещение, даже если прописаны конструктор перемещения и move оператор=. а ещё там RVO есть)
> https://blog.regehr.org/archives/1520Просто приходится много писать именно на C (не ++), вот и заинтересовало чем мне это сможет помочь. Спасибо, почитаю.
> Если не сложно, то можно немного подробнее? Правда очень интересно.Сложно. Впрочем, если тебе приходилось испытывать баттхёрт от того, что твой, жонглирующий указателями, код, который ты пишешь, не может быть дописан до конца корректно, из-за того, что в нём не осталось места для гарантированно корректного free (куда и как не вставляй free, будут либо утечки памяти либо double free), или что ты не можешь вызвать free на указатель, потому что на этапе компиляции неизвестно, будет ли этот указатель указывать на стек, кучу или в статическую память.
Если тебе приходилось с этим сталкиваться, то тогда ты поймёшь моё объяснение. Раст учит как надо писать программы так, чтобы не испытывать баттхёрт из-за невозможности решить проблемы управления памятью корректно без переписывания кода. Раст даёт относительно простые правила, которые борроу-чекер вбивает программисту в голову пинками. В результате обретается навык видеть нарушения правил, и это навык становится автоматизированным -- ты пишешь код, и ещё не дописав его понимаешь, что борроу-чекер будет ругаться. Потом, по мере дальнейшего накопления опыта, ты ещё даже не пишешь код, ты только задумываешь код, и понимаешь, что так как ты его задумываешь не надо делать, потому что борроу-чекер соберёт друзей, и устроит тебе тёмную.
Прям скажем, все эти правила выполнять в C не удастся, потому что, например, C не позволяет отразить в типе указателя, куда этот указатель указывает -- на стек, в кучу, в статическую память? С точки зрения C, char* и в Африке char*, с точки зрения rust'а, могут быть нюансы: Box<c_char> -- это указатель на кучу, и соответственно код который перевыделяет память, будет принимать Box<c_char>, и с указателем на стек откажется работать. В C так не сделать, или можно но слишком сложно, может макросами и можно упростить, реализовав тривиальную параметризацию типов, да и то не факт. Но многие правила въедаются не то, что в мозг, они въедаются в пальцы, и твои пальцы отказываются потом писать с нарушением правил.
Эти правила ограничивают полёт мысли и творческую свободу, конечно, но опыт раста может помочь и здесь: есть Learning Rust With Entirely Too Many Linked Lists[1] и есть Rustonomicon[2], если ты скуришь их, попробуешь это на практике и посмотришь как делают другие, то ты не просто будешь знать правила, ты будешь знать как и когда их можно нарушать так, чтобы минимизировать негативные последствия. И опять же не запутаться соплями в борроу-чекере при этом.
Эти знания и навыки вполне можно перенести и в C, и соблюдать (или осмысленно нарушать) эти правила несмотря на то, что компилятор C совершенно не парится об этом и не может отслеживать lifetime'ы и ownership. И на то, чтобы освоить эти правила под чутким руководством borrow-checker'а, будет достаточно, на мой взгляд, 1-3 лет чтения мануалов, написания кода, чтения кода (преимущественно кода std, преимущественно прямо в браузере по ссылке из документации на std) и общения на реддите. Чтобы то же самое освоить с C, потребуется лет пять и ещё хороший ментор, который будет ревьюировать твой код, то есть реально сидеть, вникать и пороть тебя розгами.
[1] https://rust-unofficial.github.io/too-many-lists/
[2] https://doc.rust-lang.org/nomicon/
Изучение и практика работ Donald Ervin Knuth здорово вправляет мозги и производит профилактику говнокодинга. Начинать нужно с этого, а уж потом выбирать инструмент под конкретные задачи.
Это сейчас как-то не модно. Все серебряную пулю ищут.
Rust не позиционируется как серебряная пуля и не обещает исправить кривые руки. Он обещает безопасную работу с памятью, если не используешь unsafe. Но даже если используешь, то при первой же проблеме будешь знать, где искать. Как часто нужен unsafe? Зависит от задачи. Если писать под голое железо типа Cortex-M3, то относительно часто, пока не напишешь безопасные обёртки над периферией (что уже сделано в svd2rust). Для прикладных задач - почти никогда.Код на C с точки зрения Rust - один сплошной unsafe. Так что польза от изучения Rust очевидна даже для сишника. Компилятор будет бить по рукам, когда будешь косячить, а это гораздо более эффективный метод обучения безопасной работе с памятью, чем просто очередной гайдлайн, про который компилятор C ничего не знает.
БЕЗОПАСНУЮ РАБОТУ С ПАМЯТЬЮ*<span style="font-size: 1pt">* если не используешь unsafe</span>
// Вот так правильно
Да пойми ты, что бизнес-задачам (например, телекому) как раз таки не нужен unsafe в 100% кода. Тем, кто пишет под конкретное железо обёртку для первых - нужен.В Rust "переключить режим" можно. В C - ты всегда во втором режиме. Что вызывает кучу жопоболи у пользователей, потому что всё "ломается".
тоже сейчас пока загружаю в себя плюсы, и не уходит сомнение что позже понадобится раст
есть годные материалы по Rust, для нубов?
https://www.rust-lang.org/learn
а не для нубов нормальное описание языка будет? типа стандарта c99
На той же странице есть ссылка: https://doc.rust-lang.org/reference/index.htmlДля стандартизации язык ещё слишком молодой. Многие проекты до сих пор компилятся только с nightly.
И что? Найтли очень даже стабилен. И Найтли в основном нужен для пары тройки фишек только
Меня просто бесит, когда компилятор ставится в обход системного пакетного менеджера. Найтли мало в каких дистрах есть, если вообще есть, поэтому ставить его приходится через rustup. Ставить себе бинарь через curl, вместо того, чтобы поставить бинарь, который вполне себе reproducible (в debian так) - мне не нравится. Особо упоротые могут даже bootstrappable build себе устроить, как это делается в guix. Но это всё не касается nightly, который нигде толком не опакечен. Желаю rust добра, самому нравится этот язык, но пока что есть вот такая неприятность. В идеальном мире все проекты должны были собираться с любой версией, поддерживающей Rust 2018.
Наброшу чуть-чуть)
https://aur.archlinux.org/packages/rust-nightly
> Rust nightly времён палеозоя (1.26)Ты серьёзно? Хоть заголовок новости прочитай
Ты мозг напряги. Там ставится последний билд, с коррекцией номера версии пакета
Мой косяк, глянул в PKGBUILD и действительно, скачивается последняя доступная версия. Это победа. В одном(!) дистре есть раст найтли и то в ауре.
Да, вариант не идеальный, но, заметьте, что он устанавливается в вашу домашнюю папку и не требует прав рута при установке.
А толку, если всё самое важное как раз в папке юзера?
Можно запускать хруст из под другого юзера, но зачем весь этот цирк с конями, когда могло быть иначе? А если код, который он компилирует не должен попасть в чужие руки?
Ты что, боишься, что rustup убьёт твои данные? А ты не боишься, что пакет, устанавливаемый пакетным менеджером с правами root, потрёт вообщё всё, включая home? Установочные скрипты ещё никто не отменял. С такой паранойей лучше вообще комп не включать.
Я пытаюсь сказать, что если раст хочет быть безопасным в плане памяти и ещё нескольких аспектах внутри языка, то было бы ещё полезно, если бы тулчейн тоже был безопасным. В данном случае, Trusting Trust не шутки и хорошо, если бинарь хоть сколько-то доверенный. Скачивать непойми что и где собранное через curl - ну завидую тебе, если тебя это вообще не напрягает. Тулчейн "безопасного" языка должен быть либо проверен возпроизводимыми сборками, либо проверен через Diverse Double-Compiling, либо собран из минимального бинарного зерна хотя бы. Вообще, rustc собирается из stage0 самого себя, что уже хоть что-то, но в идеальном мире stage0 должен быть таким: https://github.com/oriansj/stage0
В общем, расту ещё есть куда расти.
rustonomicon
Не будет, эта хрень overengineered с самого рождения и в дальнейшем будет становиться только хуже, т.к. останавливаться авторы не собираются.С прицелом на нубов проектировался golang.
https://github.com/ruRust/rust_book_ru
https://github.com/ruRust/rust_book_2ed
1 и 2 издания, оба на русском
Да, есть годная книга на русском языке от издательства ДМК-Пресс: https://dmkpress.com/catalog/computer/programming/978-5-9706.../
> предоставляет средства для достижения высокого параллелизма выполнения заданийReally? По-настоящему эффективных "зелёных" потоков нет!
> ... The green-threading M:N model requires a larger language runtime to manage threads. As such, the Rust standard library only provides an implementation of 1:1 threading. ...
tokio
это сторонняя библиотека
Это сторонняя библиотека типа плюсового буста. В ней находятся те вещи, которых нет в стандартной библиотеке, т.к. не совсем понятно, как их реализовать. Если их внесут в стандартную либу, придется потом долгое время тянуть груз обратной совместимости и поддержки, из-за этого замедлится и скорость разработки и удобство использования.Токио популярна и когда говорят о расте в плане сети или ассинхронщины, всегда на уме держат токио.
Ну не скажите, tokio уже стандарт де факто когда речь идет о распаралеливании в расте..
И когда говорят Future - то подразумевается именно токиоесть еще на уровне очень сырого тестирования правда async/await. не уверен - это то же токио или у них там свои обработчики нитей
Вообще-то, семантика async/await уже обкатана, просто были некоторые сомнения насчёт синтаксиса, но он недавно устаканился. Планировали стабилизировать в 1.39, вроде.
То что сейчас находится в стандарте (еще не релизнуто, но уже известен номер версии и дата, когда точно релизнется) – это некоторые соглашения о стандартных интерфейсах и реализация ключевых слов async/await. А в токио как раз находится одна из реализаций этих асинхронных механизмов.Если что-то и есть сейчас в std, то это, скорее всего, какая-то примитивщина, типа запуска нового треда на каждый фьюче. Если нужно что-то более серьезное и гибкое – пиши сам или пользуйся сторонними библиотеками, вроде того же токио.
В Rust несколько другая идеология стандартной библиотеки: туда стараются добавлять только то, что необходимо, или то, что с очень большой вероятностью все будут пытаться реализовать сами практически в каждом проекте, и 99% сделают это хуже. Такие вещи, как green threads и coroutines, выносятся в крейты, т.к. их можно сделать множеством способов, и совершенно не очевидно, какой оптимальный. А, может, оптимального способа и вовсе не существует. Это не C++, здесь использование сторонних библиотек не только поощряется, а ещё и сильно проще благодаря Cargo, поэтому в этом нет никакой проблемы.
> а ещё и сильно проще благодаря CargoАга, а потом будет очередной "Вспомнити leftpad."
Не будет. Нельзя просто так взять и удалить свой крейт с crates.io. Можно его "изъять из оборота" (yank), чтобы нельзя было на него ссылаться в публикуемых крейтах, но код будет по-прежнему доступен для тех, кто уже ссылается.
https://doc.rust-lang.org/cargo/commands/cargo-yank.html
Периодически лежащий целиком официальный докерхаб гомерически смеется над адептами облачка.
Ну не пользуйтесь crates.io, если у вас паранойя. Подключайте крейты напрямую с github или где они там у кого лежат:# Cargo.toml
[dependencies]
specs = { git = "https://github.com/slide-rs/specs", tag = "v0.15.1" }Но, конечно, github тоже может упасть. И машина вас может сбить. Стоматолог - заразить вас ВИЧ. Лучше никуда не ходить и ничего не делать, а то мало ли.
Cargo умеет в proxy registry. Т.е. дополнительно поднимаешь кеш у себя в компании и больше не теряешь доступ к тому, к чему один раз уже подцепился.
>> предоставляет средства для достижения высокого параллелизма выполнения заданий
> Really? По-настоящему эффективных "зелёных" потоков нет!
>> ... The green-threading M:N model requires a larger language runtime to manage threads. As such, the Rust standard library only provides an implementation of 1:1 threading. ...Глупые люди потому что - не знают, что есть такая серебрянная пуля!
А не, вдвойне глупые - взяли, да удалили … 🙄
https://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
> Runtime freedom: Rust's runtime system and green-threading model has been entirely removed, which cut the static binary size of "hello world" in half and has opened the door to lower-level hooks into the standard library. Implemented by Aaron Turon.https://github.com/rust-lang/rfcs/pull/230
> RFC: Remove runtime system, and move libgreen into an external library
Очень "глупые": взяли и вынески тяжёлый кусок рантайма в отдельную библятеку.
То ли дело го! В стандартной библятеке есть вообще всё. Удач с отладкой "странных" лагов.
> тяжёлый кусок рантаймаДа лан -- нам же говорят, что кастомная надстройка в виде юзерспейс-тредов будет "эффективнее" (видимо, за счет оверхеда) ;)
> Очень "глупые": взяли и вынески тяжёлый кусок рантайма в отдельную библятеку.
>> > RFC: Remove runtime system, and move libgreen into an external libraryЧини детектор сарказма ;)
Раст нигде не используется потому что, сюрприз, сюрприз, раст увеличивает срок разработки. Так как на нем нет ни одного вменяемого программиста, а те школьники что есть кроме хеллоу ворлд ничего написать не смогли. А на Си разрабов с опытом в 20 лет хоть ложкой ешь.
Какой б***ь сюрприз??
Если программа компилится - то 99% что она работает. Никаких сюрпризовНигде не используется? Используется, и в серьезных конторах тоже. RocksDB(Facebook) но там ещё си, Fuchsia (google) там он как один из языков. Источник Википедия
Я не все проекты знаю.. но и разрабов много и проектов тоже. А в крипте - так ваще раст первый в списке язык
Начинается в вашей мифологии Дропбокс тоже работает на Расте. Хотя там весь бекенд на Go. https://habr.com/ru/post/335056/RocksDB написан на С++ https://en.wikipedia.org/wiki/RocksDB
Фуксия поддерживает приложения написанные для неё на расте. В ядре кода на расте нет. Есть несколько приложений и несколько игр и то данные как примеры https://fuchsia.googlesource.com/fuchsia/
Фанатики такие фанатики даже на 15 секунд включить мозг для них непозволительная роскошь. Программисты из них точно такие же даже просто погуглить не в состоянии, все принимают за чистую монету. Им бы школу для начала закончить.
Ох, да ладно..на счёт RocksDB - извиняюсь.. Я вот правда думал что на Расте. А оказывается просто растовая обвязка есть(
Ох, лол. Ещё один "просветлённый" от мира го. Ваш го сколько пушился гуглом? Почти пять лет, напомню. Догадаешься зачем? Гуглу нужны сотни дешёвых макак, которые умеют в их инструмент. У мозилки_и_ко таких ресурсов нет. Да, раст ни разу не идеален, и проектов на нём не то, чтобы много. Но они есть. Из открытых — библиотеки Gecko и Firefox. Как ты думаешь, почему мозиловцам пришло в голову изобрести НОВЫЙ ЯЗЫК? Лень, выучить ЦэПэПэ или го? Или, всё-таки, они пытаются сделать инструмент удобный для себя и сообщества (приходится, ага. Ресурсов как у гугла нету же)?
Ваш раст сколько пушился мозилкой? Почти восемь лет, напомню. Догадаешься зачем? Мозилке нужны сотни дешёвых макак, которые умеют в их инструмент. У александреску таких ресурсов нет. Да, D ни разу не идеален, и проектов на нём не то, чтобы много. Но они есть. Как ты думаешь, почему александреску пришло в голову изобрести НОВЫЙ ЯЗЫК? Лень, выучить ЦэПэПэ? Или, всё-таки, они пытаются сделать инструмент удобный для себя и сообщества (приходится, ага. Ресурсов как у гугла нету же)?// Fixed
P.S. Попытка неудачная, на выходе всё равно получилось говно, несмотря на все ресурсы.
8 лет? Таки к 2023-му году изобрели машину времени уже? Приятно. А как с флаерами? Как там Алиса?
> А в крипте - так ваще раст первый в списке языкСам-то понял, что написал?
Кри́пта (от др.-греч. κρυπτή «крытый подземный ход; тайник») — в средневековой западноевропейской архитектуре одно или несколько подземных сводчатых помещений, расположенных под алтарной и хоральной частями храма и служащее для погребения и выставления для почитания мощей святых и мучеников.
Ну всё правильно, заранее столбят место на кладбище. Мозилла заранее строит себе пирамиду, аки древнеегипетский фараон.
>> А в крипте - так ваще раст первый в списке язык
>Сам-то понял, что написал?
>Кри́пта (кусь...)В сленге промышленного быдлокодинга -- криптография. Так понятнее?
Чувак, ты ошибаешься. Rust использует Mozilla, причём эффективно. На расте там пишет небольшая команда, остальные сишники или js и проч.Так вот, ребятам удалось написать (с "нуля") многопоточный парсер CSS на rust. До этого было 3 (!!) попытки сделать то же самое на C++, причем в команде мозиллы очень квалифицированные разработчики (другие просто не смогут писать такую сложную вещь как браузер), но все разы был облом, новый код глючил и не работал, отладка затягивалась на месяцы и в конечном итоге попытка "закапывалась".
Где ещё раст используется:
https://www.reddit.com/r/rust/comments/d9fww1/which_companie.../
Правильнее было писать только Mozilla. Написали либу для css. Либу, Карл! За 9 лет!
не гони. У меня есть знакомая студия игоределов, которые ушли из других игродельных контор. Пишут на расте всякую мелкую фигню. Пока не публично. Из прикольного — присылают бинари под 4 платформы одновременно (винда, мак, линуксы и фряха). Все бинари статичны.
Вот ты и ответил на вопрос что на расте нельзя сделать ничего, кроме мелкой фигни. Еще и не публично. Бинари статичные под 4 платформы и го может. Только го может гораздо больше.
> Так как на нем нет ни одного вменяемого программиста, а те школьники что есть кроме хеллоу ворлд ничего написать не смогли.https://github.com/BurntSushi/ripgrep
ripgrep rg -L -u -tc -n -w '[A-Z]+_SUSPEND' 404 0.079s
ucg ucg --type=cc -w '[A-Z]+_SUSPEND' 390 0.163s
GNU grep egrep -R -n --include='*.c' --include='*.h' -w '[A-Z]+_SUSPEND' 404 0.611sripgrep rg -w 'Sherlock [A-Z]\w+' 5268 2.108s
GNU grep LC_ALL=C egrep -w 'Sherlock [A-Z]\w+' 5268 7.014sИли локально:
% time rg -uui uint16 /somelargeproject |wc -l
40923
rg -uui uint16 /somelargeproject 2,22s user 2,99s system 372% cpu 1,400 total% time /usr/bin/grep -Iir uint16 /samelargeproject |wc -l
40923
/usr/bin/grep -Iir uint16 /samelargeproject 3,28s user 1,03s system 99% cpu 4,315 total
wc -l 0,00s user 0,01s system 0% cpu 4,312 total% time rg -uui "sizeof\([a-z].*[0-9]\)" /somelargeproject |wc -l
11690
rg -uui "sizeof\([a-z].*[0-9]\)" /somelargeproject 3,18s user 2,71s system 374% cpu 1,573 total% time /usr/bin/grep -Iir "sizeof([a-zA-Z].*[0-9])" /somelargeproject |wc -l
11690
/usr/bin/grep -Iir "sizeof([a-zA-Z].*[0-9])" /somelargeproject 3,36s user 1,21s system 99% cpu 4,577 total% /usr/bin/grep -V
grep (GNU grep) 3.3Хорошее, годное поколение подрастает, раз будучи школьниками уделали старперов :)
Опять кроме синтетики ничего сказать не могут. Классика. Почему растобои всегда ведут дискуссию в одном ключе? У вас методичка есть как защищать раст на опеннете?Синтетику можно подогнать к чему угодно когда угодно.
4 ядра обогнали 1.
> 4 ядра обогнали 1.Реальных ядер только 2, если что.
Ну и я весь внимание и жду с нетерпением патч/опции запуска grep на нескольких ядрах.
> Опять кроме синтетики ничего сказать не могут. Классика.Специально для танкистов добавил уточнение про "локально". "Локально" - это значит на реальной репе в 2.5 GB кода на собственном локалхосте.
Теперь жду объяснений про "синтетику" и примеров "несинтетики" :)> Почему растобои всегда ведут дискуссию в одном ключе? У вас методичка есть как защищать раст на опеннете?
Т.е. по теме ничего не будет, будет батхерт? :)
> Синтетику можно подогнать к чему угодно когда угодно.
Ну давайте подгон под grep, я только за!
Вы растаманы от природы такие недалекие или вы специально головой об стенку бьетесь?Любую башовую тулзу для распараллеливания возьми и все. Или это для тебя с твоим отсутствующим образованием высшая математика?
Для примера с исходниками ядра хватит и такого:
find . -type f -print0 | xargs -0 -P 4 grep *pattern*И будет быстрее чем твой калораст. Больше того можно под разные бенчмарки подобрать тулзы которые будет работать быстрее, чем то что я тут привел.
И так во всем. Твой раст тебе привел пример когда он обогнал программу, которая заведомо запущена так чтобы работать максимально медленно. И ты на это повелся как хомячек. Ты наверно еще телевизору веришь.
> Вы растаманы от природы такие недалекие или вы специально головой об стенку бьетесь?
> Любую башовую тулзу для распараллеливания возьми и все. Или это для тебя с твоим отсутствующим образованием высшая математика?О, какой (не)обыкновенно храбрый и умный анонмный аноним! С офигительной аргументацией и (не)оригинальным анонимным анонимствованием из под анонимного анонима! :)
> Для примера с исходниками ядра хватит и такого:
>find . -type f -print0 | xargs -0 -P 4 grep
> *pattern*Ну смотри:
% time find /somelargeproject -type f -print0 | xargs -0 -P 4 /usr/bin/grep -Ii "sizeof([a-zA-Z].*[0-9])" |wc -l
11690
find /somelargeproject -type f -print0 0,09s user 0,57s system 36% cpu 1,826 total
xargs -0 -P 4 /usr/bin/grep -Ii "sizeof([a-zA-Z].*[0-9])" 4,82s user 2,36s system 329% cpu 2,177 total
wc -l 0,01s user 0,00s system 0% cpu 2,174 total% второй прогон
user 0,00s system 0% cpu 2,182 total
% третий
user 0,00s system 0% cpu 2,190 total% time rg -uui "sizeof\([a-z].*[0-9]\)" /somelargeproject |wc -l
11690
rg -uui "sizeof\([a-z].*[0-9]\)" /somelargeproject 3,11s user 2,47s system 375% cpu 1,487 total
% второй
user 0,02s system 2% cpu 1,664 tota
% третий
user 0,03s system 2% cpu 1,671 total% time find /somelargeproject -type f -print0 | xargs -0 -P 4 /usr/bin/grep -Ii uint16 |wc -l
40923
find /somelargeproject -type f -print0 0,08s user 0,55s system 37% cpu 1,698 total
xargs -0 -P 4 /usr/bin/grep -Ii uint16 4,34s user 2,22s system 328% cpu 1,998 total
wc -l 0,01s user 0,01s system 1% cpu 1,996 total% time rg -uui uint16 /somelargeproject |wc -l
40923
rg -uui uint16 /somelargeproject 2,22s user 2,99s system 372% cpu 1,445 totalКто-то из нас (опять) сел в лужу. И это (опять) не я. :)
> И будет быстрее чем твой калораст. Больше того можно под разные бенчмарки
> подобрать тулзы которые будет работать быстрее, чем то что я тут привел.Так подбери - я ж не запрещаю. А то все обещаешься и обещаешься.
Напомню на всякий пожарный: меня лично интересует в первую очередь реальная скорость выполнения и потребление ОЗУ на реальном железе, а не труЪшность ЯП или религиозные догмы и прочие виляния/кривляния анонимного анонима.
В общем, "show me the code". Если не можешь для реального юзкейзка выше, то хотя бы для простой синтетики:
seq 100000000 > /tmp/testit% time rg -ic 1010 /tmp/testit
49700
rg -ic 1010 /tmp/testit 1,19s user 0,24s system 99% cpu 1,428 total% time /usr/bin/grep -ic 1010 /tmp/testit
49700
/usr/bin/grep -ic 1010 /tmp/testit 2,58s user 0,31s system 99% cpu 2,894 total
> И так во всем. Твой раст тебе привел пример когда он обогнал
> программу, которая заведомо запущена так чтобы работать максимально медленно.Ты бы эта, вместо надувания щек , взял да и прочитал https://blog.burntsushi.net/ripgrep/#literal-optimizations
А потом пропатчил бы grep, встроил бы поддержку мультипроцев - как никак, 2k19 на дворе.Но да, опримизировать движок грепа - это не п*зде^W умничание (да яростное и совсем беспалевное накручивание минусиков и плюсиков) на форумах из под безликого анонима :)
> system 372% cpu 1,400 total
> system 99% cpu 4,315 totalТо есть выигрыш алгоритмический.
Два вопроса:
1. почему в 1м варианте (rust) ядра частично проставивают?
2. почему второй вариант (С) "не смогли" распараллелить?
Вспоминается статья со сравнением производительности aws-кластера hadoop'а и grep'а. Угадайте кто выиграл.
Раст.
> 1. почему в 1м варианте (rust) ядра частично проставивают?Если там написано 375%, то есть 25% одного ядра не было занято ripgrep'ом, я подозреваю, что это из-за того, что они были заняты чем-то ещё. Выводом в консоль, например.
> 2. почему второй вариант (С) "не смогли" распараллелить?
Потому что писали его при царе Горохе, когда никому в голову не приходило параллелить. А теперь "работает, не трожь", то есть не осталось никого, кому было бы интересно этот код переписывать.
Может это и правильно: bash скрипты никогда не были заточены на скорость. То есть, плюс к скорости лишним не будет, но заморачиваться из-за этого специально? Зачем? Однократный долгий поиск можно и потерпеть, а если часто надо искать, можно создать индекс и искать быстрее на пару порядков. И я уверен, что если поискать, то можно найти софт, который умеет индексировать файлы с их содержимым.
Как там насчёт сравнения с The Silver Searcher (ag), написанном на C?
> Как там насчёт сравнения с The Silver Searcher (ag), написанном на C?
>> Regex searching uses PCRE's JIT compiler (if Ag is built with PCRE >=8.21).Угу, угу.
% ag --version
ag version 2.2.0
Features:
+jit +lzma +zlib% rg --version
ripgrep 11.0.2
+SIMD -AVX (compiled) # это конечно круто, но AVX тута вот нема :)
+SIMD -AVX (runtime)% time rg -uuui "sizeof\([a-z].*[0-9]\)" /somelargeproject |wc -l
11691
rg -uuui "sizeof\([a-z].*[0-9]\)" /somelargeproject 3,46s user 3,29s system 376% cpu 1,795 total% time rg -i "sizeof\([a-z].*[0-9]\)" /somelargeproject |wc -l
11687
rg -i "sizeof\([a-z].*[0-9]\)" /somelargeproject 3,61s user 3,10s system 377% cpu 1,777 total% time ag -iur "sizeof\([a-zA-Z].*[0-9]\)" /somelargeproject |wc -l
11691
ag -iur "sizeof\([a-zA-Z].*[0-9]\)" /somelargeproject 3,39s user 3,88s system 350% cpu 2,073 total
wc -l 0,00s user 0,03s system 1% cpu 2,068 total% 3,24s user 4,40s system 353% cpu 2,161 total
% 3,39s user 3,88s system 350% cpu 2,073 total
без опции -u (11687 результатов)
3,01s user 3,65s system 337% cpu 1,975 total
3,05s user 3,35s system 339% cpu 1,883 total
три прогона
% time rg -uuui uint16 /somelargeproject |wc -l
40925
rg -uuui uint16 /somelargeproject 2,50s user 3,08s system 372% cpu 1,497 total
wc -l 0,01s user 0,03s system 2% cpu 1,492 total% time ag -iur uint16 /somelargeproject|wc -l
40925
ag -iur uint16 /somelargeproject 3,36s user 3,52s system 284% cpu 2,416 total
wc -l 0,00s user 0,03s system 1% cpu 2,411 total% 3,23s user 3,48s system 282% cpu 2,372 total
% 3,16s user 3,70s system 286% cpu 2,398 total
немного синтетики:
% seq 100000000 > testit # tmpfs
% echo foobar >> testit
% time ag -ic f testit
1 # посл. строчки с reзультатом я вырезал - итак слишком длинная простыня получилась
ag -ic f testit 6,72s user 0,14s system 99% cpu 6,871 total
%2 6,73s user 0,17s system 99% cpu 6,908 total
%3 6,63s user 0,14s system 99% cpu 6,785 total% time grep -ic f testit
/usr/bin/grep --color=auto -ic f testit 2,06s user 0,31s system 99% cpu 2,375 total% time rg -ic f testit
rg -ic f testit 0,31s user 0,22s system 99% cpu 0,533 total
=========
% time ag -ic foobar testit
ag -ic foobar testit 0,61s user 0,14s system 99% cpu 0,754 total
%2 0,78s user 0,22s system 99% cpu 1,004 total
%3 0,69s user 0,21s system 99% cpu 0,903 total% time rg -ic foobar testit
rg -ic foobar testit 0,80s user 0,17s system 99% cpu 0,974 total
%2 0,78s user 0,13s system 99% cpu 0,908 total
%3 0,69s user 0,18s system 99% cpu 0,879 total% time /usr//bin/grep -ic foobar testit
/usr/bin/grep -ic foobar testit 2,21s user 0,23s system 99% cpu 2,445 total
%2 2,27s user 0,23s system 99% cpu 2,496 total
%3 2,24s user 0,24s system 99% cpu 2,479 total
==========
% time rg -ic 1 testit
56953280
rg -ic 1 testit 6,52s user 0,13s system 99% cpu 6,663 total% time /usr/bin/grep -ic 1 testit
56953280
/usr/bin/grep -ic 1 testit 4,49s user 0,31s system 99% cpu 4,803 total% time ag -ic 1 testit
80000001 # похоже, оно считает не строки, а кол. матчей
ag -ic 1 testit 8,14s user 1,04s system 99% cpu 9,188 total
=========
# далее по просты^W тексту просто взято лучшее время из 3 запусков
=========
% time ag -ic "12.[1-3]4" testit
119940
ag -ic "12.[1-3]4" testit 1,75s user 0,14s system 99% cpu 1,899 total% time /usr/bin/grep -ic "12.[1-3]4" testit
/usr/bin/grep -ic "12.[1-3]4" testit 2,58s user 0,25s system 99% cpu 2,843 total% time rg -ic "12.[1-3]4" testit
rg -ic "12.[1-3]4" testit 2,49s user 0,11s system 99% cpu 2,606 total
===========
% time /usr/bin/grep -ic "^1" testit
11111112
/usr/bin/grep -ic "^1" testit 2,68s user 0,27s system 99% cpu 2,971 total% time ag -ic "^1" testit
ag -ic "^1" testit 2,27s user 0,27s system 99% cpu 2,546 total% time rg -ic "^1" testit
rg -iuuc "^1" testit 9,93s user 0,13s system 99% cpu 10,057 total
===========
% time rg -ic "1001" testit
49979
rg -ic "1001" testit 1,15s user 0,16s system 99% cpu 1,313 total
% time ag -ic "1001" testit
49980
ag -ic "1001" testit 0,74s user 0,23s system 99% cpu 0,974 total
% time /usr/bin/grep -ic "1001" testit
49979
/usr/bin/grep -ic "1001" testit 2,56s user 0,31s system 99% cpu 2,870 total
а еще синтаксис раст такое уг, что прочесть его через пару лет сможет не каждый. а там и язык сменится)) короче он далек от реальной сферы применения.
Язык снабжён огромным количеством runtime сахара, но всё это тонет в куче синтаксического мусора. По моему скромному мнению Swift, Nim и python вполне адекватные и современные языки с простым и выразительным синтаксисом. Скобочный синтаксис это прошлый век, но ручное управление памятью - для низкоуровневых задач вполне приелемо, поэтому скобочный Си всегда будет нужен. Даже Си++ имеет более низкий порог вхождения чем Rust, при этом Си++ был разработан давно, а это значит что создатели Rust не получилось учесть опыт разработчиков Си++, т.к. по совокупности свойств Си и Си++ опережают Rust, к сожалению.
Какие его годы - вырастет еще мальчонка. Swift | Nim | Python решают совершенно иной круг задач нежели C | C++ | Rust - сравнение тут неуместно.
Особенно производительность Пайтона может как-то вообще стоять рядом с растом.. Питона даже PHP уделывает... А вы тут с Растом сравнили
Не знаю в какой ситуации пэхапэ уделывает питона, но я за семь лет использования питона, ни разу не сталкивался с проблемой нехватки времени ЦПУ в задачах решаемых на питоне, при этом графически нагруженные приложения работают у меня на целеронах и атомах.
Ну смотри: я такое недавно реализовывал для "анализа" пролетающего в наш же сервис трафика. Задача: необходимо посчитать неопределённое количество сообщений из UDP-"сокета" и каждую секунду впихивать в KV-хоронилище результат в виде суммы по ключам сообщений со сбросом счётчика. Сообщение — UDP-пакет вида ```key{:,=,/}value```. Однопоточное нечто на похапэ 7.2 (вроде) порвало мой многопоточный нетривиальный код на питоне со счётом 0:400 (в количестве потерянных пакетов в секунду) при общем потоке чот около 15000-20000 сообщений в секунду. Это была основная характеристика. По памяти я тоже (вроде) проиграл раза в 2. После такого унижения смеяться совсем не захотелось. Хотел отомстить, но крыть было нечем.
ты где это видел такого питона чтоб так тихо полз?))) скрипты на питоне прекрасно летают. чес слово не замечал большой разницы с тем же башем, или другими приложениями в консоли. если ты только его не тормозишь через input().
Соглашусь про мусор. Только мусор этот не синтаксический, а визуальный. Привычки искать парные символы, вот это вот всё…
Все эти свифты, нимы и пыхтоны обладают одной интересной особенностью — ЖИРНЮЧИМ рантаймом. И это имеет свою цену. В первую очередь — размер финального "бинаря". Скомплить сколь-нибудь сложное питононячье приложение как статический бинарник под большинство платформ ты, скорее всего не сможешь. Двое других тянут с собой приличный запас "батареек". И если хэллоуворд на NIM занимает куда меньше чем тот же хэллоуворд на свифте (спасибо умному линковщику), то вот более-менее работающее веб-приложение с приличным деревом зависимостей не оставит тебя равнодушным.
Не трясите ерундой.
https://hackaday.com/wp-content/uploads/2018/09/graph.png
> пакетный менеджер Cargo, позволяющий получить нужные для программы библиотеки в один кликДа не в один клик, а в один пись...
> :type_name::‹T›());Писец блиа. Полу-рандомный набор знаков? Пока я думаю так, что еще ничего, но когда меня просят рассмотреть в этом какой-то синтаксис.. сразу же накатывает тошнота.
Ты не одинок.
Если вы плохо знаете язык, то это ваша проблема, а не языка. Любой, кто знает Rust, читает это без напряга и сразу понимает, что это значит. А у вас подход, как у каждого второго комментатора в новостях про Rust: "Буээ, ужасный синтаксис, да ещё и не такой же, как у C++! Я языку не уделил даже десятой части времени, потраченной на освоение C++, но читать не могу не потому, что я предвзят и ленив, а потому что язык - дерьмо! А раз язык - дерьмо, то его изучение - пустая трата времени. Шах и мат, растоманы!"Вот вы почитайте код STL и скажите после этого, какой у C++ изящный и интуитивно понятный синтаксис. Однако под новостями о C++ даже близко нет такого количества нытья. По-моему, это говорит лишь о двойных стандартах. Вы по-русски хорошо читаете? А вот подавляющая часть иностранцев - нет. Как вы думаете, почему? Наверное, потому, что вы в нём варитесь уже больше десятка лет, а они его видят впервые. Почему-то, это всем очевидно, но как только разговор заходит о синтаксисе не естественного языка, а языка программирования, вы резко забываете об этом и считаете, что ваша бурная висцеральная реакция - вина разработчика, и никого другого.
Вообще, поражаюсь таким, как вы. Как вы умудряетесь развиваться как программисты, если боитесь нового синтаксиса? Умение читать код - это самый базовый навык в профессии, дальше всё на порядок сложнее, независимо от языка. Удивительно, как с таким подходом можно уйти дальше QBASIC. Наверное, в вас всё же есть силы преодолеть это незначительное препятствие. Желаю вам удачи.
плюсую за то что смог выучить весь синтаксис плюсов и их изменения. я вот только думаю где такого гения нашли? даже мастера плюсов говорят , что они не знают всего языка, а тыт тут говоришь , что знаешь. извини это хвастовство.
Где я так говорю? Приведите цитату, будьте любезны.
> Вообще, поражаюсь таким, как вы. Как вы умудряетесь развиваться как программисты ...Деградирую.. К тому же я юууузер а не кодер, на ник посмотрите в конце концов!
> на ник посмотритеВыше есть комментарий от пользователя с ником "заминированный тапок". Это так, к слову.
> Если вы плохо знаете язык, то это ваша проблема, а не языка.Поясню свой базар)) Мне честно говоря плевать на сам раст с 9го этажа, речь только про то, что мозилла не сумела впихнуть свои гениальные идеи в адекватное текстовое представление. Ну не вышло! Толи букавок не хватило, то ли сами идеи не совсем того..
> мозилла не сумелаСильное заявление. Проверять я его, конечно, не буду. Доверюсь вам. Спасибо, что решили выступить арбитром адекватности в этом деле. Но проявите милосердие, ведь Мозилла не сумела вас удовлетворить просто потому, что не пыталась, так как не знала о вашем существовании. Так что в следующий раз вы не молчите, вправьте им там мозги, чтобы не позорились, и впредь ориентировались на ваше экспертное мнение, а не на миллионы обычных людей, у которых нет вашего утончённого вкуса.
> Сильное заявление.Как раз самое банальнейшее. Достаточно просто сравнить с чем-то другим.
> Желаю вам удачи.Синтаксис нормальный у python или c#, или котлина там. И наверное сравнивают его по синтаксису именно с "красивыми" языками, а не с c++
Т.е. плюсовыйauto x = std::vector<int>();
ты понимаешь, а растовский
let x = std::any::type_name::‹i32›();
уже рандомный набор знаков? Ну да, там лишняя пара двоеточий стоит.
Сначала "rustup update" а потом уже читаю комментарии уважаемых экспертов.
Пишем на нём инструменты для своих инженеров - пока нравится. Может и до основных сервисов дойдёт если так и продолжится. В отличие от других языков Rust у нас и Java и C++ разработчики хотят попробовать. Есть наконец-то общая тема.
Создание и использование Раста совершенно логично. Невозможно создать современную систему без современных инструментов.Одно только не понятно: зачем они написали "призван заменить Си"? На нем же давно уже никто не пишет. Самая лучшая среда программирования - Visual Studio его даже не поддерживает толком. Может еще Паскаль давайте заменим?
на си пишут и много. сколько низкоуровневых программ и драйверов ты знаешь на чем то другом. есть конечно, но это не в какие ворота не лезет рядом с сишным кодом.
Потому что до уровня С++ это месиво не дотягивает. Поэтому решили заменить то что может заменить что угодно.
Это студия-то лучшая? Мда, тяжело некоторые люди живут.
у си всегда была одна лучшая студия и это текстовый редактор да gcc.
Не надо про простоту, 'жизни', это самое главное. Решается очень просто. Скачал, установил, запустил. Новый проект, кнопочка "билд"
Из того, что я уже в Расте увидел, сделал вывод, что, наверное впервые за всю историю развития императивных ЯП (ну, кроме Виртовско-Дейкстровско-Хоаровуских, наверное), развитие языка начали правильно и с привлечения грамотных математиков.
Имеет шанс.
А что будет с Си и Си++?
Они начнут движение в сторону Раст-мира.
Другое дело, что Си будет легче стать "как Раст", а вот На счёт Си++ - не уверен. Там уже столько тонн прилепок и "обеспечений совместимости" в стандартах наговнили, что "добавление ещё одной универсальности", может его окончательно превратить в кучу неподъёмного и внутренне несовместимого говнища.
Кстати да, добавление в C lifetime'ов было бы весьма кстати.