А гонору то сколько было в твитере, когда Волож и Ко(бывшие яндексоиды) покидали Россию - все прям высокоморальные белопальтошники. А пришли к тому, что будут продавать мощности для военщины США, что бы бить по родине. nuff said
Ну так и цена= 1200 rub тоже не валидна, если читающая сторона не сможет распознать/обработать тип данных. А если читающая сторона знает про этот тип данных то она знает и про Rub(1200).
RON понимает суфиксы u32 и другие rust-суфиксы начиная с версии 0.9 “Fix issue #241 and allow parsing numbers with explicit type suffixes, e.g. 1u8 or -1f32 (#481)”.
Вообще в ваших примерах спецификации нехватает того как и во что это должно читаться. Если вы утверждаете что у вас типизация на 5 звёзд, а не просто числа/строки, то этот момент как мне кажется самый ключевой. Потому, что валидность данных будет определять не сам формат/спецификация, а читающая сторона. Не хватает описание поведения читающей стороны, когда приходят данные несоответствующие(или неоднозначны) её модели данных.
Да, это навязывается уловное выражение - когда условие может выступать(можно переписать) как выражение и возвращать, что-то. В более старых языках это будет как выше сказали - тернатный оператор.
В этом и прикол машинного обучения, что LLM при обучении, выучивает обобщающие знания(как программировать), а не то как именно программировать на том или ином языке. Достаточно относительно небольшой кодовой базы с фишками языка программирования, которые до селе не у кого не было.
Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в Rust нет хорошего(по мнению большинства) способа это делать. Поэтому пока пляшем вокруг std::SIMD, std::intrinsic и дизайном кода, который склоняет к векторизации.
Пример “хорошего” api как раз и показывает компромиссность связанную с производительностью Python:
for batch in dataloader:
logits = classifier(batch.features)
loss = cross_entropy(logits, batch.labels)
loss.backward()
optimizer.step()
Где градиент? Какие параметры оптимизирует оптимизатор? Как эти параметры попадают в целевую функцию? Совершенно не видно потока данных. Всё это скрыто не потому, что это удобно - это не удобно, а потому, что мы не хотим, чтобы выполнение вываливалось в python-код и тормозило библиотечный код.
Всё же Python это альтернатива Matlab/Maple итд, а не С++/Rust . Python в мире ML это язык скриптования тулбоксов: PyTorch, JAX, итд. А С++/Rust это технологи на которых реализуют эти тулбоксы.
Что-то мне кажется, что saas который можно написать при помощи LLM уже не продашь.
А гонору то сколько было в твитере, когда Волож и Ко(бывшие яндексоиды) покидали Россию - все прям высокоморальные белопальтошники. А пришли к тому, что будут продавать мощности для военщины США, что бы бить по родине. nuff said
Эх, был бы такой гайд когда я изучал макросы…
А я даже скажу точнее, это были Bundeskriminalamt.
Спасибо за статью, у меня тоже Mi Band 10 Pro и я давно хотел сделать пару игр на акселерометре. Но никак не мог подступиться.
Ну так и
цена= 1200 rubтоже не валидна, если читающая сторона не сможет распознать/обработать тип данных. А если читающая сторона знает про этот тип данных то она знает и проRub(1200).RON понимает суфиксы u32 и другие rust-суфиксы начиная с версии 0.9 “Fix issue #241 and allow parsing numbers with explicit type suffixes, e.g. 1u8 or -1f32 (#481)”.
Вообще в ваших примерах спецификации нехватает того как и во что это должно читаться. Если вы утверждаете что у вас типизация на 5 звёзд, а не просто числа/строки, то этот момент как мне кажется самый ключевой. Потому, что валидность данных будет определять не сам формат/спецификация, а читающая сторона. Не хватает описание поведения читающей стороны, когда приходят данные несоответствующие(или неоднозначны) её модели данных.
А вот так это выглядит на ron(Rusty Object Notation), и как по мне выглядит понятнее:
Да, безопаснее и проще в сопровождении, но не значительно.
рил ток
Да, это навязывается уловное выражение - когда условие может выступать(можно переписать) как выражение и возвращать, что-то. В более старых языках это будет как выше сказали - тернатный оператор.
В этом и прикол машинного обучения, что LLM при обучении, выучивает обобщающие знания(как программировать), а не то как именно программировать на том или ином языке. Достаточно относительно небольшой кодовой базы с фишками языка программирования, которые до селе не у кого не было.
Вот код на Rust:
А это как будет выглядеть на Mojo:
Как по мне - вполне неплохо.
Так там же управление памяти как в swift (на счётчиках ссылок), а в Mojo как в Rust на системе владения/заимствования. Это концептуально разные языки.
Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в Rust нет хорошего(по мнению большинства) способа это делать. Поэтому пока пляшем вокруг
std::SIMD,std::intrinsicи дизайном кода, который склоняет к векторизации.Пример “хорошего” api как раз и показывает компромиссность связанную с производительностью Python:
Где градиент? Какие параметры оптимизирует оптимизатор? Как эти параметры попадают в целевую функцию? Совершенно не видно потока данных. Всё это скрыто не потому, что это удобно - это не удобно, а потому, что мы не хотим, чтобы выполнение вываливалось в python-код и тормозило библиотечный код.
Всё же Python это альтернатива Matlab/Maple итд, а не С++/Rust . Python в мире ML это язык скриптования тулбоксов: PyTorch, JAX, итд. А С++/Rust это технологи на которых реализуют эти тулбоксы.
Зачем IDE чтобы читать код, кода это можно делать в редакторе кода, типо Zed в 120 фпс, а не на java-блоатваре?
Основное время уходит на LLVM - я проверял. Но тут нужно уточнить, что LLVM долго работает из-за того rustc генерирует много LLVM IR.
Не знаю, был ли это сарказм, но уж лучше так, чем кожевенные мешки.
Но это же не альтернатива.