The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.60, opennews (??), 07-Апр-22, (0) [смотреть все] –1

Сообщения [Сортировка по времени | RSS]


56. "Выпуск языка программирования Rust 1.60"  +1 +/–
Сообщение от А где же каменты (?), 08-Апр-22, 00:33 
Поделитесь в чем прелесть zig?
Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск языка программирования Rust 1.60"  +5 +/–
Сообщение от Аноним (53), 08-Апр-22, 02:32 
В принципе в том как позиционируется язык всё уже описано.

1. No hidden control flow. Т.е. нет exception. Нет переопределения методов. Нет конструкторов и деструкторов.
2. Error это отдельный тип и ошибки обрабатывать придётся (что-то типа Maybe / Optional, но в процедурном стиле), иначе не скомпилипуется.
3. В тестах и дебаге тебе выдадут дательный пошаговый путь где возникла ошибка и весь её путь - это ОЧЕНЬ круто, такого нигде не видел. И это не stacktrace, а error trace.
4. Тесты пишутся прямо в файле как test {...zig code...} и сразу запускаются командной zig test - ничего делать не надо. Очень поощряет test-driven программирование. Я ещё ни разу не собирал проект и не разбирался как это делать детально, а уже несколько тысяч строк работающего кода с тестами.
5. Тесты можно дебажить и все breakpoint работают в VS Code.
6. Билд система тоже на Zig, не надо учить отдельный язык синтаксис (cmake/Gradle).
7. Максимальная безопасность - все значения по умолчанию const (настоящий, а не как константная ссылка), проверки выхода за границы, и т.д. и т.п. Т.е. в отличие от Rust много проверок в runtime в Debug режиме, вместо статического доказывания системе типов, как в Rust - притом что многие проверки можно реально выполнить только в runtime.
8. Аллокатор передаётся как параметр - никаких скрытых аллокаций памяти.
9. Аллокатор std.testing.allocator отлавливает утечки - очень круто, использую в тестах
10. Отличная интероперабельность с С (не тестировал сам)

defer / errdefer - крутейшая фича.

Вообще ощущение что пишешь на высокоуровневом языке, хотя Zig самый низкоуровневый из всех.

Я очень доволен. Скажу честно, расчитывал что он быстро начнёт разваливаться и я его выкину как "не смогла".

Но он превзошёл все мои ожидания даже в версии 0.10.0-dev.

Ребята очень заточены на безопасность, но в меру, без фанатизма, и на performance.

Уже добавили переносимые SIMD в язык (тип @Vector())

Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 02:33 
Это только часть, не рассказал про дженерики и вычисления в compile time.

Язык очень самобытный.

Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от qew (?), 08-Апр-22, 05:20 
Спасибо за описание!
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

82. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Someone (??), 08-Апр-22, 06:59 
Если по уровню обработки ошибок, их детальность и понятности, то лучше раста ничего нет. Только Elm может сравниться.

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

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

125. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (94), 08-Апр-22, 12:13 
> Zig самый низкоуровневый из всех.

Я не понял, это фронтенд над LLVM?

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

151. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 14:15 
Это действительно круто. Потому что + на типе "вектор" или "массив" может быть в тысячу / миллион раз медленее чем + над обычным integer.

По сути это тот самый hidden control flow, когда стоимость операции предполагается такой же или сопоставимой.

Тут ты точно знаешь что + это дёшево и только для integer и float с аппаратной поддержкой.

И потом это переопределение операторов. Его тоже нет.

Ответить | Правка | Наверх | Cообщить модератору

154. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (154), 08-Апр-22, 14:29 
А как быстро делать + на массиве, например? Не троллю, просто не разбираюсь.
Ответить | Правка | Наверх | Cообщить модератору

161. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 14:44 
Быстро не сделать. Лучшее что можно сделать - использовать SIMD инструкции. В зависимости от разрядности элементов массива от 2х до 8х можно получить.

Но всё равно O(N).

Ответить | Правка | Наверх | Cообщить модератору

160. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 14:40 
Да, использует backend LLVM для оптимизации и генерации кода.
Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

165. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (94), 08-Апр-22, 14:59 
Эх! Но все равно круто, надо пристальней изучить
Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (124), 08-Апр-22, 12:20 
>Нет переопределения методов.

Т.е., нельзя определить операции "+", "-", "=" для своего типа? Ну "круто", чё.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

227. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 18:00 
Ну как тебе сказать. Оверлоад операторов хитрож@пым програмером - даст фору любому obfuscated C code contest'у. И это вовсе даже и не фича когда охота вдуплить в логику чужого кода.
Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск языка программирования Rust 1.60"  +1 +/–
Сообщение от Аноним (137), 08-Апр-22, 12:43 
интересно, что большая часть этих пунктов есть и в rust
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

158. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 14:39 
Много чего в Rust нет и неизвестно когда будет.

Zig опережает Rust по многим пунктам. Просто не стал касаться этой темы.

В Rust основное преимущество, и оно же - недостаток, их система типов с borrow checking.

Про её ограниченность можно почитать в интернете, неплохо разбиралось. Там что-то про слабость и ограниченность аффинной системы типов.

Именно поэтому сравнивая языки, я выбрал Zig. Он более низкоуровневый. Это то что нужно для системного программирования.

Rust тоже хороший язык, по сравнению с C++. Он он как раз замена С++, и какие концепции оттуда стащили - Clone, Copy, конструкторы, деструкторы и вот это вот всё.

В Zig этого нет и не нужно. В Zig даже нет типа "строка".

Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск языка программирования Rust 1.60"  +1 +/–
Сообщение от Анимус (?), 08-Апр-22, 22:08 
> Zig опережает Rust по многим пунктам. Просто не стал касаться этой темы.

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

Ответить | Правка | Наверх | Cообщить модератору

209. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (209), 09-Апр-22, 12:19 
>> Zig опережает Rust по многим пунктам. Просто не стал касаться этой темы.
> А было бы интересно, если бы коснулся. Согласен с предыдущим комментатором, почти
> все плюсы Zig ты расписываешь, как будто Раст расхваливаешь.

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

Ответить | Правка | Наверх | Cообщить модератору

210. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 13:08 
> А меня позабавило как он в одном пункте пишет что Зиг самый
> низкоуровневый из всех, когда в пункте выше написал что у Зиг
> больше проверок времени исполнения чем в Раст.

А чего там забавного? "Сложная" система типов, те же владения, как раз позволяет более продвинутые проверки времени компиляции.

Ответить | Правка | Наверх | Cообщить модератору

212. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (53), 09-Апр-22, 13:28 
Это в теории, притом гипотетической. На практике самый быстрый код генерирует C, а не Rust.
Ответить | Правка | Наверх | Cообщить модератору

213. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 14:01 
>> больше проверок времени исполнения чем в Раст.
> Это в теории, притом гипотетической.

Ты хочешь сказать, что на самом деле владения и ссылки не проверяются? От оно че ...
> На практике самый быстрый код генерирует C, а не Rust.

Разве что код для очередного микробенча (что не факт https://benchmarksgame-team.pages.debian.net/benchmarksgame/... )
с гарантиями и проверками вида "Соколиный глаз посмотрел код" и "зуб даю".

Ответить | Правка | Наверх | Cообщить модератору

214. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 09-Апр-22, 15:07 
Я хочу сказать то, что сказал.

Эквивалентный код на С работает быстрее чем на Rust. Оптимизируется современными компиляторами лучше, ассемблерный код генерирует лучше.

Но Zig это же делает лучше C.

Все просто поверили в мантру чёрного ящика "оптимизирующего компилятора". Однако современные компиляторы достаточно слабы.

Ну умеют даже SIMD использовать, нужно ручками.

Поэтому "вот сейчас компилятор проверит всё в compile-time" и сгенерирует оптимальный код - лучше чем С - сказки это всё. Практика и куча тестов показала что это не так.

Обещали "Rust быстрее С", но не случилось.

Это факт, который глупо отрицать.

Насчёт проверок - я хочу сказать что система типов очень ограниченна.

Это круто, это лучше чем ничего, это значительно лучше чем было "до".

Zig пошёл другим путём - он делает максимальное количество проверок в runtime. Система типов значительно проще (но всё равно очень продвинутая по сравнению с С и С++). Код читать и понимать значительно легче.

И как на системе типов Rust ты докажешь что нет утечек памяти? Или что вектор содержит ровно N элементов? Или ...

Ответить | Правка | Наверх | Cообщить модератору

215. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 15:44 
> Я хочу сказать то, что сказал.
> Эквивалентный код на С работает быстрее чем на Rust. Оптимизируется современными компиляторами
> лучше, ассемблерный код генерирует лучше.

Ты просто смешал в кучу _проверки_ времени компиляции и оптимизацию - и оспорил какие-то, выдуманные тобой же, якобы мои "утверждения".
> Но Zig это же делает лучше C.
> Все просто поверили в мантру чёрного ящика "оптимизирующего компилятора". Однако современные
> компиляторы достаточно слабы.

Опять сам придумал, сам опроверг. Попробуй использовать gcc 3.x и потом порассуждать еще раз про "слабость".

> Ну умеют даже SIMD использовать, нужно ручками.
> Поэтому "вот сейчас компилятор проверит всё в compile-time" и сгенерирует оптимальный код
> - лучше чем С - сказки это всё. Практика и куча тестов показала что это не так.

...
Я ж говорю - "смешались в кучу кони, люди". Извини, но мне лень спорить с твоими фантазиями и додумками.

Ответить | Правка | Наверх | Cообщить модератору

242. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 23:58 
> Но Zig это же делает лучше C.

Нельзя ли примеры с конкретными асмовыми листингами?

> Все просто поверили в мантру чёрного ящика "оптимизирующего компилятора". Однако современные
> компиляторы достаточно слабы.

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

> Ну умеют даже SIMD использовать, нужно ручками.

А он не у всех таргетов есть, увеличивает в разы контекст, использование стэка и времена переключений, так что в системном программировании, где зачастую надо работать с минимальными допущениями это скорее дурной тон. Или premature optimization, который root of all evil. К тому же там все не так просто и у simd обычно есть специфичные требования (например выравнивание). Их выполнения и подготовка окружения к соответствю им не бесплатны: больше RAM жрется и если то что есть сразу в требования не лезло надо дополнительный код, жирнее и медленнее оригинала. Сетап этого может иногда отыграть взад. А настоящие гуру - те кто без всякого SIMD может в скорость железа упереться, как LZ4 например.

Есть вещи на которые это не распостраняется. Но их немного. Типа memcpy в стандартной либе. Но даже там переросточный glibc в сях например - да, быстрый, но если размер кода интересовал, эта быстрота дорого обходится: большая платформозависимая функция. Много кода разом. А если было много мелких операций оно еще и проиграть более простым может.

> Обещали "Rust быстрее С", но не случилось.

В идеале си может код который даже на голом асме не обставишь из-за глобальных оптимизаций. Реально компилятор иногда глупит, очевидно имея свои взгляды на косты операций. Поэтому вот тут мы вам критичный кусок испортим в разы, зато вон там (куда менее критичный) код гораздо лучше из-за этого. В этом случае если это было важно кодер может выругаться и написать кусок на асме. Втопив в разы.

> Это факт, который глупо отрицать.

А они что, волшебники?

> Насчёт проверок - я хочу сказать что система типов очень ограниченна.
> Это круто, это лучше чем ничего, это значительно лучше чем было "до".

Тут можно поспорить. Хруст пытается рыбку съесть и на ... сесть ценой заставления кодера все нудно аннотировать. Это не имеет костов в ран тайм но не дает кодеру забить на явный баг.

> Zig пошёл другим путём - он делает максимальное количество проверок в runtime.

К сожалению в отличие от того что делает Rust это отливается в более жирный и медленный код. А без этого - отпадают гарантии.

> Система типов значительно проще (но всё равно очень продвинутая по сравнению
> с С и С++). Код читать и понимать значительно легче.
> И как на системе типов Rust ты докажешь что нет утечек памяти?
> Или что вектор содержит ровно N элементов? Или ...

Они решая одни проблемы изобрели много новых. А си хорош тем что проблем относительно немного и они хорошо известны.

Ответить | Правка | Наверх | Cообщить модератору

246. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним215 (?), 10-Апр-22, 00:27 
>> Ну умеют даже SIMD использовать, нужно ручками.
> А он не у всех таргетов есть, увеличивает в разы контекст, использование

Не, это конечно забавно, когда один любитель приписывания своих фантазий решил поспорить с другим (надо было запастись попкорном). Но лично у меня еще gcc5 -O3 для amd64 разворачивал


int vec1[100];
int vec2[100];
...
for(int i=0;i<100;i++) vec2[i]=vec1[i]+vec2[i];

в

.L3:
        movdqa  xmm0, XMMWORD PTR [rbp+0+rax]
        paddd   xmm0, XMMWORD PTR [rbx+rax]
        movaps  XMMWORD PTR [rbx+rax], xmm0
        add     rax, 16
        cmp     rax, 400
        jne     .L3

И это, подписывайся как нибудь, если уж тоже влезаешь в обсуждение с таким же ником.


Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

253. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 10-Апр-22, 01:02 
Да, только все библиотеки высокопроизводительные используют ручные компиляторно-специфичные интрисинки.

Так почему же? Может потому что SIMD он впихнет в самых примитивных случаях? И шаг вправо, шаг влево и компилятор уже того... сложил ручки.

Ваш пример тому не опровержение, а доказательство. Это всё на просторах интернета неплохо разобрано.

Увы, магией, компиляторы не обладают.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

298. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (-), 13-Апр-22, 08:31 
>> А он не у всех таргетов есть, увеличивает в разы контекст, использование
> Не, это конечно забавно, когда один любитель приписывания своих фантазий решил поспорить
> с другим (надо было запастись попкорном). Но лично у меня еще
> gcc5 -O3 для amd64 разворачивал

А теперь смотрим во что разворачивается сохранение подобных контекстов при случае. При переключении задач тоже придется. Как и регистры FPU еще. Посмотрим на размер контекста задачи и подхоренеем. А если захочется low latency кернел - тыщу раз в секунду такие блоки таскать уже и не нулевой оверхед. Это же актуально при вызове множества функций и т.п..

Не забываем включить мозги. Код бывает разный. И там удобны и хороши разные вещи, серебряных пуль не бывает. Аксиома: чем больше регистров задействуеися - тем жирнее контекст. И в зависимости от кода и алгоритма результат - очень варьируется. Может быть и профит и пролет.

А тот код - прям так может и работать, а попробуйте это указателем сделать (вы же не собираетесь int[100] передавать дальше значением, задвигая про эффективность?!) - и узнаете много нового и интересного про simd, alignment и в чем там прикол. У simd есть довольно специфичные требования к выравниванию адресов и веселые приколы если это не выполняется.

> 

 
> int vec1[100]; 
> int vec2[100]; 
> ...
> for(int i=0;i<100;i++) vec2[i]=vec1[i]+vec2[i]; 
>

Ну да, ну да, только отложенных грабель в этом коде около дюжины разложено. На всех уровнях. Шажок в сторону и бомбанет этот код, там или тут. И с точки зрения статического анализа и декларации намерений такой код - дно. Начиная прямо с (signed) индекса массива.

> И это, подписывайся как нибудь, если уж тоже влезаешь в обсуждение с таким же ником.

А нафига? Есть некие мысли, их и обсуждаем.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

302. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним215 (?), 13-Апр-22, 11:54 
> А теперь смотрим во что разворачивается сохранение подобных контекстов при случае. При
> переключении задач тоже придется. Как и регистры FPU еще. Посмотрим на

Опять оспорил свои фатназии. Тезис был "компилятор не умеет, нужно ручками", а не "оно может быть не эффективным".

> А тот код - прям так может и работать, а попробуйте это
> указателем сделать (вы же не собираетесь int[100] передавать дальше значением, задвигая
> про эффективность?!) - и узнаете много нового и интересного про simd,
> alignment и в чем там прикол. У simd есть довольно специфичные
> требования к выравниванию адресов и веселые приколы если это не выполняется.

Особо забавно оспаривание своих же фантазий анонимом в контексте опыта написания нехилых кусков SIMD еще ручками, в асме ...

>> И это, подписывайся как нибудь, если уж тоже влезаешь в обсуждение с таким же ником.
> А нафига? Есть некие мысли, их и обсуждаем.

А то, что до #215 Аноним(-) был другой ... ну да, я и забыл - 294й считает нетикет глупым предрассудком.


Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

254. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 10-Апр-22, 01:57 
Все листинги есть в GitHub Issues, и их довольно много. "Навскидку" я их не приведу, они мне попадались случайно.

Одна из заявленных главных целей - быть быстрее С. Поэтому performance на втором месте.

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

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

@Vector для SIMD, а если SIMD не поддерживаются то будет fallback на обычный вектор, т.е. поэлементное сравнение.

inline for, calling conventions можно выбирать для каждой функции.

Там куча всего есть, что делает его именно системным низкоуровневым, чего С и в помине не может.

Про то что SIMD что-то там увеличивает...это конечно требует серьезных пруфов. Жду.

Но никто не заставляет их использовать. Не хочешь - не используй.

И нет, конструкции языка переводятся в инструкции процессору. Если у процессора есть SIMD, который может делать до 8х ускорения, а язык программирования не знает об этом без хаков, для конкретного компилятора... скажем мягко...нет, это не преимущество.

Архитектур которые поддерживает Zig куча. Спасибо LLVM. И нет, это не делает язык более "системным", как вы сказали.

Может для какого-то embedded, и плат нужны отдельные подархитектуры и компиляторы, которых нет в LLVM. Возможно, не знаю. Я не железячник.

Но это либо совсем никому не нужно, либо вопросы к вендору. Архитектуру в LLVM можно добавить, и это делали не раз.

Про то что Rust не имеет якобы костов в runtime из-за якобы крутых проверок - я хотел бы увидеть доказательства. Например, как он делает проверки выхода за границы массива? Вы опять это пишите, а доказательства где?

Rust проверяет корректность некоторых конструкций, довольно ограниченную. Просто из "у Rust такая крутая система типов, что он теоретически МОЖЕТ делать более продвинутые оптимизации" это превратилось на просторах интернета в факт, бездоказательный.

Или Rust умеет проверять переполнение float?

Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

299. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 13-Апр-22, 09:10 
> Все листинги есть в GitHub Issues, и их довольно много. "Навскидку" я
> их не приведу, они мне попадались случайно.

И даже ссылки на гитхаб не дадите? А так - алгоритмов и процовых архитектур много и вот так огульно утверждать что X быстрее Y и это цель - ну, так себе затея. Разве что чисто статистически в совсем явных случаях, типа сказав что "си быстрее питона" вы врядли особо соврете. И то ярый питонист в пику накопает краевые случаи, они ничего не доказывают, но все же так бывает.

> Одна из заявленных главных целей - быть быстрее С. Поэтому performance на втором месте.

Быстрее чем си - ну, очень абстрактно. Особенно когда кодеген у обоих на одном и том же LLVM, а если параллельность хотелось и проч, сишники нынче могут OpenMP поюзать одной pragma-ой, например.

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

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

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

Он также может заинлайнить все нахрен, если явно не запрошено экспортировать вон то наружу для других под стандарнтым ABI. И там вообще не будет ни параметров, ни функции, лишь несколько команд делающих

> @Vector для SIMD, а если SIMD не поддерживаются то будет fallback на
> обычный вектор, т.е. поэлементное сравнение.

Да так то на самом деле неплохо, но у simd есть не совсем очевидные но отличные от ноля требования и side effects. И чем больше таких грабель тем хуже оно как именно системный тул.

> inline for, calling conventions можно выбирать для каждой функции.

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

> Там куча всего есть, что делает его именно системным низкоуровневым, чего С
> и в помине не может.

Например, чего?

> Про то что SIMD что-то там увеличивает...это конечно требует серьезных пруфов. Жду.

Чем больше регистров используется тем больше регистров сохранять. Особенно при полном переключении контекста, типа переключения задачи/сохранения состояния потока и проч. А, представляете, си достаточно низкоуровневый для того чтобы на нем например корутины самому сделать было?!

> Но никто не заставляет их использовать. Не хочешь - не используй.

Вопрос не в том - а в количестве грабель которые вылезут. И в реюзабельности кода, особенно, вот именно в системных вещах. У сей очень удобно что многий код можно оттестить на писюке а потом в какой мелкий мк запихнуть. Где с инструментацией все же хуже и кривее (супротив perf/gdb/asan/ubsan/etc). Хотя, знаете, по минимуму сделать ubsan можно даже на мк. Только ваши любимые проверки индексов и математики не халявные. А в ubsan таки сделали ультралайт версию, когда при завале проверки случается всего лишь bad opcode например. Дешево, сердито, и вот именно системный обработчик исключения в мелочи таки заметит что шит произошел. А в этом зигхайле так вообще можно в системные вещи вклиниться?

> И нет, конструкции языка переводятся в инструкции процессору. Если у процессора есть
> SIMD, который может делать до 8х ускорения, а язык программирования не
> знает об этом без хаков, для конкретного компилятора... скажем мягко...нет, это
> не преимущество.

Он может дать до 8x ускорения. А может дать до нескольких раз торможения. Характерный пример будет glibc'шный memcpy. Да, он на вот этом вот выезжает в разы - если условия подошли. А если caller его абы как на куче мелочи дернет с абы какими указателями, копируя по 10 байтов за вызов, оно там будет в рантайме дольше одуплять - можно ли с данным адресом SIMD вообще, или это нарушает constraints. Единственный вариант как-то это гарантировать - прибить форсированый align все и вся на гвозди, но будет другая проблема: RAM и стэка больше жрать будет. Чисто на округление адресации.

> Архитектур которые поддерживает Zig куча. Спасибо LLVM. И нет, это не делает
> язык более "системным", как вы сказали.

Вообще-то LLVM поддерживает не так уж и много архитектур. По сравнению с тем же GCC например. И оптимизация у него хороша только под 1-2, на остальные они просто положили.

> Может для какого-то embedded, и плат нужны отдельные подархитектуры и компиляторы, которых
> нет в LLVM. Возможно, не знаю. Я не железячник.

Если вы не это - тогда какого фига про системность рассказывать? Системность языка все эти вещи подразумевает. Ну ладно, может там хоть стандартный способ положить "эту функцию в вон ту секцию" сделали? Если уж более системное? А то в си вот это подбешивает, нестандартно и в разных компилерах по разному. И без этого фиг фирмвару или бутлоадер какой сделаешь.

> Но это либо совсем никому не нужно, либо вопросы к вендору. Архитектуру
> в LLVM можно добавить, и это делали не раз.

Да как-то не особо эффективно делали. Реально живое там x86-64. Ну ARM'ы еще слегка. Остальное постольку-поскольку, спущено на тормозах. Да даже с ARM оно прикалываться умеет если тематически форумы именно системной направленности почитать.

> Про то что Rust не имеет якобы костов в runtime из-за якобы
> крутых проверок - я хотел бы увидеть доказательства.

Я так понимаю что он с своим borrow checker ухитряется часть проверок доказать в компил тайме и тогда выкинуть их все из кода с чистой совестью. Да что там, оптимизеры типа LTO и сами этим грешат, только уровнем пониже и наружу интерфейс в случае си не вывешивают. Но выпилить к черту проверки, доказав "always true" может на раз. Торвальдс очень ругался - в кернеле компилятор некоторые использования не видит :). И если кто заикается про системность - ему потом эти оптимизации с другого бока очень жестко вылезут так то.

> Например, как он делает проверки выхода за границы массива? Вы опять это пишите, а
> доказательства где?

Как я понимаю - таки в compile time просчитывает большую часть этого. Хотя рантайм panic() у него таки тоже есть. И можете зазырить в рассялке ядра что Торвальдс про такие вещи в СИСТЕМНЫХ вещах думает.

> Rust проверяет корректность некоторых конструкций, довольно ограниченную. Просто из "у
> Rust такая крутая система типов, что он теоретически МОЖЕТ делать более
> продвинутые оптимизации" это превратилось на просторах интернета в факт, бездоказательный.

И как я понял - это заодно и делает синтаксис довольно закорючным.

> Или Rust умеет проверять переполнение float?

Да без понятия, я не растаман так то. Но float вообще большая проблема с точки зрения надежности и предсказуемости всего этого. Более того - чтобы все это было, надо хотя-бы какие-то жесткие стандарты определить, для всех краевых случаев, гарантированной точности и проч. Что начинает клещиться с умениями разнообразного железа. С точки зрения системщины и надежности плавучка проблемный топик. Ряд стандартов безопасности типа MISRA прямым текстом запрещает использование таковой по этим причиным.

Ответить | Правка | К родителю #254 | Наверх | Cообщить модератору

211. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 09-Апр-22, 13:25 
Как это связано с низкоуровневостью?

Можно собрать с отключенными проверками, есть Release и Release Safe.

Низкоуровневый он по совершенно другим причинам.

Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

220. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 09-Апр-22, 17:35 
> Можно собрать с отключенными проверками, есть Release и Release Safe.

К сожалению оно дает риск про@#$ться - или оверхед в рантайм.

> Низкоуровневый он по совершенно другим причинам.

Из которых ни 1 не перечислена...

Ответить | Правка | Наверх | Cообщить модератору

228. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 09-Апр-22, 19:03 
А зачем?
Ответить | Правка | Наверх | Cообщить модератору

243. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (-), 10-Апр-22, 00:00 
> А зачем?

Правильно, кого сейчас интересуют пруфы громких заявлений...

Ответить | Правка | Наверх | Cообщить модератору

251. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 10-Апр-22, 00:51 
Меня выше спросили - я ответил.
А распинаться и пытаться что-то доказать непонятно зачем анониму...

Всё есть в Issue на GitHub, и коммитах.

А ты умеешь делать проверки выхода за границы массива не в runtime? Или так умеет делать Rust? Может он умеет доказывать в compile time?

Шанс про...ться всегда есть. Только это сразу же отлавливается примитивными тестами.

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

Ответить | Правка | Наверх | Cообщить модератору

200. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от А где же каменты (?), 08-Апр-22, 23:54 
Какие книги почитать чтобы понять что ты написал? Про хидден флоу итд
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

201. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 09-Апр-22, 02:17 
Вот этого достаточно https://ziglang.org/learn/why_zig_rust_d_cpp
Ответить | Правка | Наверх | Cообщить модератору

219. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (-), 09-Апр-22, 17:32 
> 1. No hidden control flow. Т.е. нет exception. Нет переопределения методов. Нет
> конструкторов и деструкторов.

А как же panic содраный из хруста и вычисления в compile time?

> 2. Error это отдельный тип и ошибки обрабатывать придётся (что-то типа Maybe
> / Optional, но в процедурном стиле), иначе не скомпилипуется.

При том вот именно это - вызывает вопросы какими веществами они пользовались. Хотя выглядит забавно.

> 4. Тесты пишутся прямо в файле как test {...zig code...} и сразу
> запускаются командной zig test - ничего делать не надо. Очень поощряет
> test-driven программирование.

С другой стороны, прелесть сей в отсутствии hardwired допущений прибитых на гвозди. Нравится тестить так - берем то. Эдак - берем это. Либ для тестов - есть.

> 5. Тесты можно дебажить и все breakpoint работают в VS Code.

Вы перепутали вебмакак с системщиками.

> 6. Билд система тоже на Zig, не надо учить отдельный язык синтаксис
> (cmake/Gradle).

С другой стороны - см выше про прибито на гвозди. Единственный Правильный Путь - это не путь сишника.

> 7. Максимальная безопасность - все значения по умолчанию const (настоящий, а не
> как константная ссылка), проверки выхода за границы, и т.д. и т.п.

Только стоит уточнить что оно либо с пеналти в рантайме - либо без некоторых проверок.

> Т.е. в отличие от Rust много проверок в runtime в Debug
> режиме, вместо статического доказывания системе типов, как в Rust -

ЧСХ спорный вопрос что это фича. Хруст в этом пожалуй имеет преимущество: с одной стороны хоть какие-то проверки-гарантии, с другой - это не портит код в ран тайм.

> притом что многие проверки можно реально выполнить только в runtime.

Оно как бы не бесплатно по размеру кода и его скорости.

> 8. Аллокатор передаётся как параметр - никаких скрытых аллокаций памяти.

А вот это прикольно придумано. С другой стороны - кодить аллокатор в bare metal ну так себе, знаете ли. А без аллокатора оно вообще способно жить?

> 10. Отличная интероперабельность с С (не тестировал сам)

И вообще вроде можно постепенно сишный сорц до этого заапгрейдить.

> defer / errdefer - крутейшая фича.

Вообще забавно сделано.

> Вообще ощущение что пишешь на высокоуровневом языке, хотя Zig самый низкоуровневый из всех.

Да ну ща. Си низкоуровнее некуда. А как на этом оформить помещение числа 0x20 в адрес 0x80000?

> Я очень доволен. Скажу честно, расчитывал что он быстро начнёт разваливаться и
> я его выкину как "не смогла".

На самом деле забавная штука. Более логичный чем хруст на вид.

> Но он превзошёл все мои ожидания даже в версии 0.10.0-dev.

Да? А как насчет поддержки в GCC? Надоели уже с шлангом гребаным, половину архитектур он тупо не умеет, что как бы аргумент если вы что-то там про системное программирование :P

> Ребята очень заточены на безопасность, но в меру, без фанатизма, и на performance.

Вообще они адекватнее раста с их оголтелым маркетинговым булшитом и пиханием во все дыры на кривой козе. И с сями оно менее дурно стыкуется на вид.

> Уже добавили переносимые SIMD в язык (тип @Vector())

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

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

255. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (53), 10-Апр-22, 02:05 
Никакого panic в Zig нет.

Вычисления в comptime - это одна из ключевых фич и особенностей языка.

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

В Rust это какой-то язык макросов над AST, который несколько раз переписывался и был unstable.

В Zig - это обычный код на Zig.
comptime {
...zig code
}

Что может быть проще.

Ответить | Правка | Наверх | Cообщить модератору

266. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (295), 10-Апр-22, 12:08 
> Вычисления в comptime - это одна из ключевых фич и особенностей языка.
> В Rust это какой-то язык макросов над AST, который несколько раз переписывался и был unstable.

Ну-ну.

const fn foo()
https://doc.rust-lang.org/reference/const_eval.html

Ответить | Правка | Наверх | Cообщить модератору

269. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (53), 10-Апр-22, 14:39 
Ну-ну. А println как там имплементирован?)))
Ответить | Правка | Наверх | Cообщить модератору

270. "Выпуск языка программирования Rust 1.60"  –1 +/–
Сообщение от Аноним (53), 10-Апр-22, 14:51 
А, так вы вообще не понимаете и не разбираетесь о чём пишете.

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

Сравнивать надо с этим убожеством в виде макросов https://doc.rust-lang.org/src/std/macros.rs.html#96-101.

Что-то на нормальный Rust совсем не похоже.

Вот это сделать на Rust слабо?

https://github.com/ziglang/zig/blob/master/lib/std/comptime_...

Да, все generic, и comptime полиморфизм сделано в Zig гораздо лучше чем в Rust.

Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

274. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (295), 10-Апр-22, 21:44 
> А, так вы вообще не понимаете и не разбираетесь о чём пишете.
> comptime используется гораздо шире, чем вычисление констант. Вы вообще не о том.  
> вычисление констант

"Свои недостатки мы очень любим приписывать другим"(с)

> Сравнивать надо с этим убожеством в виде макросов https://doc.rust-lang.org/src/std/macros.rs.html#96-101.
> Что-то на нормальный Rust совсем не похоже.

Опять что-то придумал и оспорил. Молодец, так держать!

> Вот это сделать на Rust слабо?
> https://github.com/ziglang/zig/blob/master/lib/std/comptime_...

Надул щечки, будто сам лично писал.
Погоди, шнурки поглажу ...


#![allow(unused)]
#![feature(const_for)]
#![feature(const_fn_trait_bound)]
#![feature(const_mut_refs)]

struct KV<'a,T> {key:&'a str,val:T}
struct MyMap<'a,T> {kvs:&'a [KV<'a,T>]}
const fn get<T:Copy>(key:&'static str, map:MyMap<T>) -> Option<T> {
   
   for kv in map.kvs.into_iter() {
     if (kv.key == key) {return Some(kv.val)}
   }
   return None; 
} 

fn main() {
const a:KV<i32> = KV {key: "hello", val: 1};
const b:KV<i32> = KV {key: "foo", val: 2};
const c:KV<i32> = KV {key: "bar", val:100500};
const map:MyMap<i32> = MyMap{kvs: &[a,b,c]};
println!("foo = {}, bar = {}", get("foo",map).unwrap(), get("bar",map).unwrap_or(42));
}

Да, оно проверяет все _полностью_ в компайлтайме.

% rustc -O -Zunleash-the-miri-inside-of-you=yes const.rs
% ./const 
foo = 2, bar = 100500
_ZN5const4main17hf11e025cf5259379E:
        .cfi_startproc
        sub     rsp, 88
        .cfi_def_cfa_offset 96
        mov     dword ptr [rsp], 2
        mov     dword ptr [rsp + 4], 100500
        mov     rax, rsp
        mov     qword ptr [rsp + 8], rax
        mov     rax, qword ptr [rip + _ZN4core3fmt3num3imp52_$LT$impl$u20$core..fmt..Display$u20$for$u20$i32$GT$3fmt17h3319aa4b4b98306eE@GOTPCREL]
        mov     qword ptr [rsp + 16], rax
        lea     rcx, [rsp + 4]
        mov     qword ptr [rsp + 24], rcx
        mov     qword ptr [rsp + 32], rax
        lea     rax, [rip + .L__unnamed_1]
        mov     qword ptr [rsp + 40], rax
        mov     qword ptr [rsp + 48], 3
        mov     qword ptr [rsp + 56], 0
        lea     rax, [rsp + 8]
        mov     qword ptr [rsp + 72], rax
        mov     qword ptr [rsp + 80], 2
        lea     rdi, [rsp + 40]
        call    qword ptr [rip + _ZN3std2io5stdio6_print17h07b90b286b5e6a91E@GOTPCREL]
        add     rsp, 88
        .cfi_def_cfa_offset 8
        ret


Ответить | Правка | Наверх | Cообщить модератору

277. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 11-Апр-22, 03:36 
Код делает немного не то, что по ссылке. Точнее совсем не то.

Предположу что ещё с парой включенных фич можно сделать что нужно.

Неплохо для языка, в который влили тонну бабла. Правда в 1.0 это не вошло, как я понял.

Через 5 лет после появления умеет то что сделал бывший студент-программист из Орегона, по вечерам после работы в версии 0.6.0.

А теперь мы подошли к главной фиче Zig. Как из const fn вернуть тип? Например для параметра 1 (Mac OS) я хочу получить одну структуру (с одними полями и их типами), а для 2 (Linux) другую структуру (другие поля. Ну и пусть методы будут одинаковыми.

Ответить | Правка | Наверх | Cообщить модератору

306. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (152), 15-Апр-22, 13:21 
О! Это то что я давно хотел получить от растоманов. Но они какой-то хней отмазывались.

Может я не туда смотрел. Можно ли пример, как подобное делается в zig?

Достаточно ссылочку и пару поясняющих фраз.

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск языка программирования Rust 1.60"  +/–
Сообщение от Аноним (53), 08-Апр-22, 02:42 
Из интересного - alignment вшит в систему типов (указателя), поэтому туда-сюда указатели с разными alignment таскать не получится, только в безопасную сторону.

Я работаю с Direct I/O и там специальные требования к памяти.

Минус целый класс ошибок.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру