Rust 1.49

Вообще, совет мочерне с хлебушком в черепушке. Чтобы на ресурсе нормально общались - нужно начать с вычищения тупака. Тупака, а не «неверной» на взгляд мочерна информации, запарта нелепая. Нормально общаются по теме, а когда и так немногочисленные темы тонут в тупаке - остаётся только дерьмом кидаться. Исполнять.

Бесполезный мусор, как и всё в C++. Никто не запрещает передать туда кривой указатель.

Никто не запрещает прибавить 2 вместо 3 в расте. Подгорать.

Разбором выражения может занимаешься и ты, тем не менее ты говорил про парсер, но приведи мне пример где такой разбор в реальном коде более хотя бы двойной вложенности, типичный крик теоретиков, такого уродства о котором ты пытаешься говорить нормальные люди не пишут. Так что все еще мимо.

Я привел тебе и твоему прихлебале схожие уродства синтаксиса rust, на которые вынуждены идти его создатели. rust - c++ в новом фантике, не более.

Получить воспроизводимые сборки в принципе невозможно. Cargo, скачивающий что-то откуда-то во время компиляции - это никуда не годится.

Можешь раскрыть тему? Ведь если все зависимости версионируются, и сам компилятор и система сборки конкретных версий, то не важно, откуда этот карго получает данные зависимости - все компоненты определены однозначно.

Никто не запрещает передать туда кривой указатель.

будет вызван std::terminate.

https://gcc.godbolt.org/z/fc1sEv

все компоненты определены однозначно

Однозначно определены значения версий, но не само содержимое (исходники, бинарники и прочие блобы).

будет вызван std::terminate

Зсб решение.

auto p = new int(1);
gsl::not_null<int*> test = p;
delete p;

ok

uintptr_t i = 10;
gsl::not_null<int*> test = (int*)i;

ok

Ну и толку от него? Это фундаментальный баг уровня std::optional dereferncing.

cargo сверяет хеши. Ваш КО.

cargo сверяет хеши.

Ты указываешь хеши в описании пакетов? Откуда карга достанет то, чего нет?

Кстати, на заметку, хеш - неоднозначная функция. И для «однозначности» хешировать надо не только исходники, но и саму сборку.

Закрыл от анонимусов, опять тот же самый с тем же самым.

хеш - неоднозначная функция

на всякий случай: под «однозначностью» в моем посте, конечно, не имелась в виду математическая однозначность, т.е. случай существования двух разных версий исходника (или разных версий множества файлов исходников) с одним и тем же значением хеша априори исключается

даже то, что скорость компиляции зависит от языка. у меня никаких проблем с компиляцией сей почему-то нет

Скорость компиляции конечно же зависит как от сложности синтаксиса и семантики языка, так и от заложенных возможностей инкрементальной разработки. В С++ со всем этим плохо. «Нет проблем» только на хеллоуворлдах, в больших проектах приходится идти на прогулку на время ребилда.

выучи язык и пиши правильно и все у тебя будет работать

Выучить можно все, что угодно. Люди даже на бейсике писали (и пишут) продашн код, и на асме графический интерфейс, сайты и объектную систему - надо ли так делать? Нет. Вот то же самое и с С++. Я тебя ни к чему не призываю, самому лет 15 назад нравилось на плюсах писать, просто объективные факты не в пользу него (помимо нескольких весьма узких ниш, и то в основном по причинам уже написанных библиотек и компиляторов).

жалобы на синтаксис я вообще первый раз слышу, на синтаксис пхп, д, го, яваскрипта, явы и тд почему-то никто не жалуется

ORLY?

не знаю где питон с руби оказался лучше сей, разве что может не придется читать про указатели

Везде лучше, что касается высокоуровневого программирования.

самые крутые штуки пишутся именно на сях

Кроме игр я ядра в парочке ос, что там еще такого крутого пишется? Числодробилка известных алгоритмов? О да, очень круто (в скобочках - нет).

кретин после них разберется как это работает и что нужно доделать.

И сразу придет к выводам, что срочно надо фиксить меморилики. Но где и как... ?!

посмотри на синтаксис раста https://doc.rust-lang.org/stable/rust-by-example/conversion/try_from_try_into... и скажи что тебе понятнее, си или вот это вот что по ссылке.

Rust почти не знаю, но по ссылке достаточно симпатичный кусок кода, очевидный и понятный.

Однозначно определены значения версий, но не само содержимое

а это уже проблема системы контроля версий и методики ее использования, а не системы сборки. С таким же успехом можно изменить значение метки версии в VCS, или подставить адрес ложного репозитория, но обвинить при этом систему сборки в невоспоизводимых билдах. Или я не понял чего-то?

Нет, это не проблемы «системы контроля версий и методики ее использования». Никак ты по libversion := [6.4; 7.0) не сможешь воспроизводимо собирать.

версии в VCS

Причём здесь vcs? Речь про сборку. Нет там никакой vcs.

Никак ты по libversion := [6.4; 7.0) не сможешь воспроизводимо собирать.

Есть же cargo.lock

Там конкретные версии, а не диапазоны.

https://github.com/mozilla/grcov

https://github.com/mozilla/grcov/blob/master/Cargo.lock

Никак ты по libversion := [6.4; 7.0)

если процесс сборки/пакетирования и версионирования libversion детерминирован, то не должно быть проблем

А как в таком случае цеплять библиотеки с хоста? Там с хардкодом версии очень сложно будет. Или оно только для сценария «зависимости из репы» и грузит безусловно, без предварительного поиска по уже установленным либам?

Не «не должно», а обязательно будут. Нет точного критерия загружаемой версии, могут быть загружены разные версии - не воспроизводимо.

Ты, клоун, будешь мне рассказывать о чём я говорил?

Нет, естественно ни о каком парсере я не говорил, то, что ты додумал идиотское - это говорит о тебе. Я написал об уродском синтаксисе языка C, о том, как разбор объявления типа приходится делать по довольно сложному алгоритму и эта сложность не обусловлена ничем рациональным. А будет это делать компилятор или человек-читатель - этого вопроса я вообще не касался.

А как в таком случае цеплять библиотеки с хоста?

Не знаю. С crates.io работает…

The purpose of a Cargo.lock is to describe the state of the world at the time of a successful build. It is then used to provide deterministic builds across whatever machine is building the package by ensuring that the exact same dependencies are being compiled.

самому лет 15 назад нравилось на плюсах писать

это в школьном кружке чтоли? нихрена по ссылке не хороший и понятный код, они взяли си и сделали его максимально уродливым.

самому лет 15 назад нравилось на плюсах писать

это в школьном кружке чтоли?

В универе и на первой работе (делал очень веселые штуки в сове время - в том числе писал генераторы для vhdl на плюсах / прочую цифровую схемотехнику и генераторы html для бизнеса), в школе я писал на паскале и бейсике и php.

нихрена по ссылке не хороший и понятный код, они взяли си и сделали его максимально уродливым.

Попробуй доказать?

Получить воспроизводимые сборки в принципе невозможно. Cargo, скачивающий что-то откуда-то во время компиляции - это никуда не годится.

Либо из тебя хреновый мейнтейнер, либо ты просто жиробасик. В Gentoo же смогли сделать, что бы Rust проекты собирались со включённым network-sandbox (Т.е. без сети). И в Debian смогли. И вообще, ты можешь собственный реестр/репозиторий крейтов сделать.

Да и сам раст для установки требует откуда-то скачать какой-то бинарный блоб. Его нельзя собрать из исходников.

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет? Всё, GCC и Clang для тебя - больше тоже не опенсорс.

Собственно это легко объясняется чтением растового багтрекера. Складывается ощущение, что авторы уже давно сами запутались что они лепят. И особенно доставляет, как часто они не могут что-то починить, потому что это дурацкий LLVM во всём виноват.

LLVM не дурацкий, но он действительно «виноват». Правда, какое это отношение имеет к опакечиванию?

Короче говоря, пока не запилят фронтенд для GCC, этот супермегабезопасный язык - просто куча хлама. Вещь в себе.

Очередная глупость.

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет? Всё, GCC и Clang для тебя - больше тоже не опенсорс.

«Блоб» это то что без исходиков?

C++ компилируется довольно быстро. По крайней мере точно быстрее чем:

Откуда дровишки? Когда я ради интереса пощупать rust переписал свой проектик на плюсах, то разница в скорости компиляции была кратной.

C++ компилируется довольно быстро. По крайней мере точно быстрее чем:

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

В данном случае «блобом» он назвал либо официальный бинарик rustc, либо rustup. Но и rustc, и rustup имеют открытые исходники под двойной лицензией Apache 2.0 / MIT. И прекрасно собираются из них на Gentoo, в частности.

Откуда дровишки?

Из личного опыта.

разница в скорости компиляции была кратной.

Код на плюсах был плох с точки зрения скорости компиляции.

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

Контролировались ли специализации шаблонов? Лишние специализации не должны создаваться, и компилироваться одна специализация должна максимум один раз, а не в каждом файле.

Использовались ли предварительное объявление там где можно обойтись им вместо include?

Если ответ на всё да, то я не верю, что плюсы компилировались медленнее раста.

А GCC или Clang ты можешь собрать из исходников без «блоба» - уже скомпилированного GCC или Clang? Нет?

да!

stage0

Это фундаментальный баг уровня std::optional dereferncing.

А что там?

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

Я даже специально выделил «ты» в своём сообщении. Понятное дело, что так можно, с Rust - тоже. Тык. Тык. Просто анончик не стал заморачиваться и решил уныленько набросить. Да, этот компилятор (mrustc) начал пилиться позже, изначально rustc собирался как-то иначе. Но я почти уверен, что эксгумировать окаменевшую версию, которая написана на OCaml - можно, однако никому нафиг не нужно кроме парочки хикканов с параноидальной шизофренией.

Ты, клоун, будешь мне рассказывать о чём я говорил?

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

Нет, естественно ни о каком парсере я не говорил

Ага «для меня» и «выглядит».

А я вот сформулирую утверждение, которое гораздо сильнее: синтаксис C не «для меня», а объективно и не «выглядит», а является уродским. И могу даже это доказать. Набираешь в гугле «правило право-лево» и где-то на первой странице встречаешь объяснение, как разбирать сложные объявления указателей. Это не вопрос каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов, нет, это сраный парсинг типа переменной! А всё почему? Потому что в одном из первых структурных языков алголе решили поместить тип переменных слева от имени. Решение основанное не на чём. А потом в сях (или в каком-то промежуточном языке) решили объявлять массивы скобками после имени, а под конец попытались обобщить правило объявления так, чтоб оно покрывало объяление функций, переменных и массивов. С тех пор наследники алгола и C занимаются тем, что выбирают насколько упростить объявления. Те, кто посмелее (обычно теоретики) просто делают сразу нормально. Те, кто пытается не пугать старых программистов, оставляют тип слева, но от порнографии с описанием типа, который окружает идентификатор, отказались все. Одно только объявление функции осталось в виде исключения.

Ну что враль мелкая, все еще ничего не говорил, оправдывайся.

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

Ну там аж два бага.

1. Никто не запрещает обращаться к std::nullopt. Соответственно смысла от него чуть менее чем ничего.
2. std::optional не даёт хранить ссылки. std::optional<int&> - ошибка.

Это справедливо для любого языка.

Ну и зачем весь этот пердолинг? Речь-то идёт про идиоматичный код. И в данном случае разницы в скорости компиляции скорее всего не будет.

Слишком много пафоса для того чтоб сказать «раз парсинг, значит компилятор». Термин «парсинг», мой юный друг, в IT означает «грамматический разбор». Компилятор этим занимается, но и другие тоже. Так что на двоечку.

Более того, если взять контекст, а именно то предложение, которое ты выделил:

Это не вопрос каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов, нет, это сраный парсинг типа переменной!

То твоя предъява ещё тупее. Как видишь, тут сравнение двух знаний, с одной стороны знание «каких-то соглашений для нормальной работы сложных систем, поддерживаемых десятилетиями коллективами из сотни программистов», с другой - «правило право-лево», которое объясняет как делать «сраный парсинг типа переменной». Так как «соглашения» нужно знать не компилятору, а программисту, было бы странно сравнивать эту задачу с парсером из компилятора. Т.е. нужно быть полным дебилом, чтоб из этого предположить, что речь вообще идёт о сложностях компилятора.

std::optional не даёт хранить ссылки.

Ну тут я бы не считал это багом. А то вернут тебе из функции optional со ссылкой на переменную которая была выделенна на стеке и привет. Это ж не rust.

Хотя конечно остётся ещё возможность вернуть optional с указателем на эту переменную.

Хотя конечно остётся ещё возможность вернуть optional с указателем на эту переменную.

тут скорее std::reference_wrapper

Какие только кюнштуки не приходится придумывать с++, только из-за того что приходится тащить тонну легаси и при этом хочется сделать как-то по новому и безопаснее.

«Стройная система костылей и подпорок»(цы)

Правда они начали всё-таки удалять всякую deprecated хрень в c++20.

Какие только кюнштуки не приходится придумывать с++, только из-за того что приходится тащить тонну легаси

ну у раста таких проблем нет и не будет - там в принципе не задумываются, что произойдет с существующим кодом лет через 10-15.

там в принципе не задумываются, что произойдет с существующим кодом лет через 10-15.

Задумываются. В частности в Rust есть такие гарантии от разработчиков:

Warning-free code on edition N must compile on edition N+1 and have the same behavior.

Редакции будут выходить раз в три года, как в плюсах. Пока есть Rust 2015 и Rust 2018, планируется Rust 2021

С совместимостью в Rust более менее хорошо, ломают только Nightly. Stable достаточно стабильный. Не десятки лет, но множество языков и библиотек не имеют даже таких гарантий…

Обратная сторона, да.

Выходит что Warning-free code будет работать так же само 6 лет. Не представляю зачем нужно больше, но это все равно не 10-15.

разработчики раста могут гарантировать все что угодно, но делают они помойку говнокода вроде npm. Я уже сейчас вижу, как даже в небольших проектах cargo тянет одну библиотеку черт знает скольки разных версий, отличающихся друг от друга одной 3-й цифрой.

И вообще, раст от начала и до конца рассчитан на разработку проприетарщины в больших корпорациях, с монорепами и т.п. Почему в среде линуксоидов его не выкидывают на мороз, как сишарп какой-нибудь?

Почему в среде линуксоидов его не выкидывают на мороз, как сишарп какой-нибудь?

Потому что люди не шизики, в отличии от.

если ты ламер, которому нечего написать по теме, то советую просто ничего не писать

вопрос в том, что есть «вредное»?

вот посикс сокеты это полезное или вредное?