Не знаю о чём вы, но аллокаторов много разных бывает, хотите свой пишите, Rust явно не ограничивает вас, это не относится к языку вообще никак, пишите no_std и он не будет выделять в куче вообще ничего сам, как и в Си вообще никакого аллакатора нет и что? В ядре ОС никто в здравом уме не будет пользоваться динамическим распределением памяти, это приведёт к жёсткой дефрагментации
Я попытался вспомнить всё неявное в Rust, пока ехал с работы , времени было полно повспоминать, нашёл только три случая:
1) создание копии через маркерный трейт Copy, это когда он сам создаст вам копию переменной, чтобы передать её в функцию/замыкание, работает на простых типах, которые можно дешево скопировать, либо на выведенных через derive/руками реализованных алгебраических типах, это легко понимается просто из соображений с каким типом работаем и как быстро его можно скопировать
2) автоматическое разыменовывание ссылок/умных указателей, тут тоже легко понять что сырой указатель в safe rust не имеет смысла
3) неявный вызов drop, всё, что выходит за область видимости или при потере владения он будет немедленно уничтожать
Если найдёте ещё что-то - готов обсудить
По сути все три случая просто синтаксический сахар в том смысле, что вы можете и явно их выполнить, первую через трейт Clone, вторую руками разыменовать, третью так же руками вызвать drop в любом удобном вам месте, но почему они существуют? Очевидно уменьшить бойлерплейт, ибо в любом контексте итак понятно, что другой вариант не имеет смысла вообще, разве что у вас прям в этой критической секции нельзя копировать или освобождать память, там какие-то важные операции паралельно начались, но тогда вызывайте явно где удобно,в чем проблема, Rust примет к сведению и вашу копию и что объект уже дропнут раньше, чем там гражданин Линус не доволен не знаю, может вы его не так поняли и он наезжал на что-то другое?
Есть ещё неявный вывод типа... Но это не совсем операция, которая попадет в бинарник, поэтому не знаю стоит ли считать, в любом случае если компилятор хоть немного не уверен что правильно понял ваш тип он вам об этом сообщит и ничего не соберёт, я бы это не считал за неявную операцию
вроде всё, всё остальное там явно, это уберегает от многих сюрпризов при отладке, в проде или чтении листинга неизвестной вам программы. Вопросы в стиле "а что выведет вот эта программа" как принято в C++ там не уместны, не нужно собирать конференции, где десяток гиков будут до хрипоты спорить какой же конструктор тут вызовется, что к чему будет неявно преобразовываться и в каком приоритете произойдут операции, взглянув на текст программы вы можете однозначно сказать чем кончится дело
По поводу LL(1):
Если на пальцах, вот возьмём строчку
(x) * y
В термах C/C++ это может значить три разных операции
Привести к типу x значение из адреса y
Помножить x на y
Объявить указатель на y типа x,
А может быть и 4 вариант - если * перегружена для x,y, зависит от контекста
В LL(1) языках такого нет, там нет неоднозначности, всё явно, в Rust привести y к x - это y as x
Помножить x * y
Объявить - let y:x
Мне не нужно много контекста и листать код туда сюда выясняя как определена операция для данного случая
Оба последних варианта нужно рассматривать в OpenMP, раз вы говорите, я процитирую "распараллеленный отказоустойчивый код" у вас очевидно в один поток всё фигачило, я взял примеры конкретно известные из самой библиотеки OpenMP, посмотрите темы aliasing и data races в OpenMP, возможно я не точный код дал, а только примерный, из-за незнания нюансов самого Фортрана, но эти проблемы не я придумал, сами авторы не отрицают этих проблем, и предлагают барьеры, включите параллельность то и увидите UB
Rust код напротив распараллелится без UB
" в Rust извернуться и гонку данных устроить, в Rustonomicon даже пара примеров на такой случай есть"
В теории можно извернуться и дрелью каску на стройке просверлить и говорить что она небезопасна, только вот это нужно прямо специально стараться, случайно или по невнимательности это не выйдет, нужно прям знать что ты делаешь, компилятор rustc имеет очень хорошие сообщения об ошибках и подозрениях, он вас на этом пути много раз за руку одернет, что "чем-то вы не тем занимаетесь, посидите подумайте лучше, вот вам ссылки для размышления"
Что значит нативная поддержка массивов без обращения к библиотекам? Типа не надо писать include или что? Так то массивы обычно всегда в std... Давайте возьмём
let c: Vec<f64> = a.iter()
.zip(b.iter())
.map(|(x, y)| x + y)
.collect();
Никаких внешних библиотек не нужно, это считается нативной поддержкой? По поводу безопасности, Фортран
1) молча может прочитать память за границами массива, UB
2) так же молча перекрыть диапазоны массива: REAL, DIMENSION(6) :: ARR = [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
ARR(2:5) = ARR(1:4) + ARR(3:6)
Снова UB
3) устроить гонку данных
REAL :: TOTAL = 0.0
DO I = 1, 1000
C(I) = A(I) + B(I)
TOTAL = TOTAL + C(I)
END DO
Что снова UB
В Rust все три ситуации впринципе невозможны, о каком отказоустойчивом коде мы говорим, если я навскидку дал три варианта развития событий, где можно получить UB на простом сложении массивов...
Ну это другой вопрос, я варюсь в embedded, нам тут отродясь go не нужен был, но если есть возможность 90% бюджета вкладывать в девайсы с кучей ОЗУ, почему бы не побаловаться гошечкой....
Алгебра предполагает кроме операций и нейтральные элементы для этих операций, 0 для сложения и 1 для произведения.
Статья не полна без затрагивания единичного типа unit type, нейтрального для типа-произведения и нулевого типа never type нейтрального для типа-суммы в Rust именно они позволяют полностью замкнуть алгебраическую систему типов с целью, с которой она задумывалась - доказать корректность программ, о чем мечтал Дейкстра, соответственно на примере Rust:
Мне наоборот он нравится, синтаксис явный, что написано, то и будет, никаких скрытых махинаций, преобразований или непонятных порядков вызова убойного набора конструкторов, и даже почти LL(1)
Я действительно хотел вложить оригинальный вклад в хабр, но как видите мне слили карму, за что, если я в чём виноват - скажите, моё мнение вы просто токсики, я не хочу впринципе делиться никаким опытом тут, читайте рекламные статьи, переводы чужих статей и творчество нейросетей
Я здесь часто читал и читаю разные статьи как сделать то, как устроено это, в какой-то момент сделал по работе на Embedded Rust корректор коэффициента мощности, так был горд собой, что сам разобрался и хотел было выложить серию статей как отлаживать код в микроконтроллерах на Rust, как писать ПИД, как виенна-преобразователь, зарегистрировался, но пока писал первую часть - мне карму быстрее слили, я и забил, сошёлся нафиг в токсиков чего-то вкладывать, лучше на github выложу
Наверное не зашумленым у них считается всякие гольф на perl/ruby, типа -2%{2+.2/@*\/10.3??2*+
Каждая закорючка что-то да делает, а про читаемость кода никто не думает, на мой взгляд любой код на Pascal, тем более Rust на порядок более читабелен, чем типичный код C/C++
Но давайте напишите на C/C++/Java например объявление функции
Procedure Foo(const a,b,c,d,e:Word),
Хочу сравнить зашумленность, сколько раз встречу const unsigned int вместо одного const Word?
В паскале таки есть сборщик мусора, не полноценный, но лучше , чем ничего - конкретно строки, динамические массивы и объекты интерфейсов уничтожаются сами
Wubuntu... Проприетарная лицензия на Линукс с закрытым исходным кодом от автора, которого уже ловили на шпионском и вредоносном коде в его дистрибутивах
Отключайте аллокатор, в чём проблема, он не будет ничего аллоцировать, как в чистом Си, проблема аллакатора не имеет отношения к языку
Ни одно из этого не входит в стандарт Си и нигде в языке не упоминается, аналогично можно приписать что проблема С в баге какого-то модуля firefox
Не знаю о чём вы, но аллокаторов много разных бывает, хотите свой пишите, Rust явно не ограничивает вас, это не относится к языку вообще никак, пишите no_std и он не будет выделять в куче вообще ничего сам, как и в Си вообще никакого аллакатора нет и что? В ядре ОС никто в здравом уме не будет пользоваться динамическим распределением памяти, это приведёт к жёсткой дефрагментации
Не знаю какие там тенденции в Java, но не многовато ли дублирования кода, что никак не обобщить эти простыни?
Я попытался вспомнить всё неявное в Rust, пока ехал с работы , времени было полно повспоминать, нашёл только три случая:
1) создание копии через маркерный трейт Copy, это когда он сам создаст вам копию переменной, чтобы передать её в функцию/замыкание, работает на простых типах, которые можно дешево скопировать, либо на выведенных через derive/руками реализованных алгебраических типах, это легко понимается просто из соображений с каким типом работаем и как быстро его можно скопировать
2) автоматическое разыменовывание ссылок/умных указателей, тут тоже легко понять что сырой указатель в safe rust не имеет смысла
3) неявный вызов drop, всё, что выходит за область видимости или при потере владения он будет немедленно уничтожать
Если найдёте ещё что-то - готов обсудить
По сути все три случая просто синтаксический сахар в том смысле, что вы можете и явно их выполнить, первую через трейт Clone, вторую руками разыменовать, третью так же руками вызвать drop в любом удобном вам месте, но почему они существуют? Очевидно уменьшить бойлерплейт, ибо в любом контексте итак понятно, что другой вариант не имеет смысла вообще, разве что у вас прям в этой критической секции нельзя копировать или освобождать память, там какие-то важные операции паралельно начались, но тогда вызывайте явно где удобно,в чем проблема, Rust примет к сведению и вашу копию и что объект уже дропнут раньше, чем там гражданин Линус не доволен не знаю, может вы его не так поняли и он наезжал на что-то другое?
Есть ещё неявный вывод типа... Но это не совсем операция, которая попадет в бинарник, поэтому не знаю стоит ли считать, в любом случае если компилятор хоть немного не уверен что правильно понял ваш тип он вам об этом сообщит и ничего не соберёт, я бы это не считал за неявную операцию
вроде всё, всё остальное там явно, это уберегает от многих сюрпризов при отладке, в проде или чтении листинга неизвестной вам программы. Вопросы в стиле "а что выведет вот эта программа" как принято в C++ там не уместны, не нужно собирать конференции, где десяток гиков будут до хрипоты спорить какой же конструктор тут вызовется, что к чему будет неявно преобразовываться и в каком приоритете произойдут операции, взглянув на текст программы вы можете однозначно сказать чем кончится дело
По поводу LL(1):
Если на пальцах, вот возьмём строчку
(x) * y
В термах C/C++ это может значить три разных операции
Привести к типу x значение из адреса y
Помножить x на y
Объявить указатель на y типа x,
А может быть и 4 вариант - если * перегружена для x,y, зависит от контекста
В LL(1) языках такого нет, там нет неоднозначности, всё явно, в Rust привести y к x - это y as x
Помножить x * y
Объявить - let y:x
Мне не нужно много контекста и листать код туда сюда выясняя как определена операция для данного случая
Оба последних варианта нужно рассматривать в OpenMP, раз вы говорите, я процитирую "распараллеленный отказоустойчивый код" у вас очевидно в один поток всё фигачило, я взял примеры конкретно известные из самой библиотеки OpenMP, посмотрите темы aliasing и data races в OpenMP, возможно я не точный код дал, а только примерный, из-за незнания нюансов самого Фортрана, но эти проблемы не я придумал, сами авторы не отрицают этих проблем, и предлагают барьеры, включите параллельность то и увидите UB
Rust код напротив распараллелится без UB
" в Rust извернуться и гонку данных устроить, в Rustonomicon даже пара примеров на такой случай есть"
В теории можно извернуться и дрелью каску на стройке просверлить и говорить что она небезопасна, только вот это нужно прямо специально стараться, случайно или по невнимательности это не выйдет, нужно прям знать что ты делаешь, компилятор rustc имеет очень хорошие сообщения об ошибках и подозрениях, он вас на этом пути много раз за руку одернет, что "чем-то вы не тем занимаетесь, посидите подумайте лучше, вот вам ссылки для размышления"
Что значит нативная поддержка массивов без обращения к библиотекам? Типа не надо писать include или что? Так то массивы обычно всегда в std... Давайте возьмём
Никаких внешних библиотек не нужно, это считается нативной поддержкой? По поводу безопасности, Фортран
1) молча может прочитать память за границами массива, UB
2) так же молча перекрыть диапазоны массива: REAL, DIMENSION(6) :: ARR = [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
ARR(2:5) = ARR(1:4) + ARR(3:6)
Снова UB
3) устроить гонку данных
REAL :: TOTAL = 0.0
DO I = 1, 1000
C(I) = A(I) + B(I)
TOTAL = TOTAL + C(I)
END DO
Что снова UB
В Rust все три ситуации впринципе невозможны, о каком отказоустойчивом коде мы говорим, если я навскидку дал три варианта развития событий, где можно получить UB на простом сложении массивов...
Ну это другой вопрос, я варюсь в embedded, нам тут отродясь go не нужен был, но если есть возможность 90% бюджета вкладывать в девайсы с кучей ОЗУ, почему бы не побаловаться гошечкой....
Если человек не осилил Rust, то почему бы и не побаловаться с гошечкой, не осуждаем
Когда вы работаете вообще?, если столько времени планируете то?
"естественная запись математических формул"
Настолько ли она естественна, как например в Haskell, где буквально можно из учебника матана вставлять определения
"Python или C++ для сложения массивов требуется цикл или специальная библиотека"
Или почитать что такое ФП...
Алгебра предполагает кроме операций и нейтральные элементы для этих операций, 0 для сложения и 1 для произведения.
Статья не полна без затрагивания единичного типа unit type, нейтрального для типа-произведения и нулевого типа never type нейтрального для типа-суммы в Rust именно они позволяют полностью замкнуть алгебраическую систему типов с целью, с которой она задумывалась - доказать корректность программ, о чем мечтал Дейкстра, соответственно на примере Rust:
Unit type - () и struct Foo;
Never type - ! и enum Foo {};
Требую рассмотреть!
Мне наоборот он нравится, синтаксис явный, что написано, то и будет, никаких скрытых махинаций, преобразований или непонятных порядков вызова убойного набора конструкторов, и даже почти LL(1)
Я действительно хотел вложить оригинальный вклад в хабр, но как видите мне слили карму, за что, если я в чём виноват - скажите, моё мнение вы просто токсики, я не хочу впринципе делиться никаким опытом тут, читайте рекламные статьи, переводы чужих статей и творчество нейросетей
Я здесь часто читал и читаю разные статьи как сделать то, как устроено это, в какой-то момент сделал по работе на Embedded Rust корректор коэффициента мощности, так был горд собой, что сам разобрался и хотел было выложить серию статей как отлаживать код в микроконтроллерах на Rust, как писать ПИД, как виенна-преобразователь, зарегистрировался, но пока писал первую часть - мне карму быстрее слили, я и забил, сошёлся нафиг в токсиков чего-то вкладывать, лучше на github выложу
"объект воздействует на воду — круги от него всегда одинаковые и расходятся с одинаковой скоростью"
"Физику" на заметку все круги одинаковой формы и скорость волн на воде не зависит от упавшего объекта
Наверное не зашумленым у них считается всякие гольф на perl/ruby, типа -2%{2+.2/@*\/10.3??2*+
Каждая закорючка что-то да делает, а про читаемость кода никто не думает, на мой взгляд любой код на Pascal, тем более Rust на порядок более читабелен, чем типичный код C/C++
Но давайте напишите на C/C++/Java например объявление функции
Procedure Foo(const a,b,c,d,e:Word),
Хочу сравнить зашумленность, сколько раз встречу const unsigned int вместо одного const Word?
В паскале таки есть сборщик мусора, не полноценный, но лучше , чем ничего - конкретно строки, динамические массивы и объекты интерфейсов уничтожаются сами
Wubuntu... Проприетарная лицензия на Линукс с закрытым исходным кодом от автора, которого уже ловили на шпионском и вредоносном коде в его дистрибутивах
https://kernal.gitlab.io/posts/linuxfx/
Дважды...
https://kernal.gitlab.io/posts/linuxfx-part-2/
Звучит как нужно не только дома ставить, но и всю организацию переводить)
Забей там инженер-программист, работы полно, толковых мало