LINUX.ORG.RU

Правильно ли я пишу на Rust?

 , ,


1

7

Часто мелькает Rust и в новостях, и в темах. Решил попробовать переписать один тест с С на Rust. Для сравнения написал вариант и на C++. На Rust получилось в 4+ раза медленнее, чем на С и в 2+ раза медленнее, чем на C++. Есть подозрение, что я делаю что-то неправильно, но не знаю что. Помогите, пожалуйста, разобраться.

UPD. Мои цифры:

$ gcc c_v1.c -Ofast -march=native
$ ./a.out 3000
16.439091
-287.250083
$ g++ cpp_v2.cpp -Ofast -march=native
$ ./a.out 3000
31.3826
-287.25
$ rustc rust_v1.rs -C opt-level=3 -C target-cpu=native
$ ./rust_v1 3000
71.570172703s
-287.2500833333321
★★★

Последнее исправление: andalevor (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

UI в 2020 без HiDPI и аппаратного ускорения - тупик.

И как этому препятствует набор GUI-виджетов, которыми оперируют традиционные GUI-тулкиты (особенно, если они снабжены такими штуками, как spacer-ы и layout-ы)?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вы пробовали использовать винду на HiDPI? Узнаете много нового.

Сама архитектура никак не мешает. Но с поддержкой всё плохо. Ну и рендерить процом 4k холст - тупик.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вы пробовали использовать винду на HiDPI? Узнаете много нового.

У меня сейчас на одном из ноутов Win10 на 4K экране. Масштабирование кастомное (сейчас уже не помню какое, а самого ноута под рукой нет).

Проблемы пока наблюдаются только у gVim-а, в котором в тулбаре эконки милипиздрические. Ну еще в старом Lightroom-е курсор слишком мелкий.

Но с поддержкой всё плохо.

Что именно?

Ну и рендерить процом 4k холст - тупик.

Опять же, традиционные виджеты здесь каким боком?

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Не, Pathfinder отдельно, вроде на реддите видел

vertexua ★★★★★
()
Ответ на: комментарий от yetanother

Я уже запутался с какими флагами в итоге собирали, но сборка с -Ofast (или добавление -ffast-math) в случае перемножения с предварительным транспонирование (как здесь) сокращает время примерно на треть по сравнению с -O3.

grem ★★★★★
()
Ответ на: комментарий от yetanother

Но вывод неправильный. Ты пытаешься кренить в сторону что мол язык такой убогий что фундаментально невозможно написать аналоги Gtk/Qt. А реально это просто на данном этапе уже никому не нужно

vertexua ★★★★★
()
Ответ на: комментарий от grem

Одинаковая скорость, как с fast-math в обоих языках, так и без.

c
rust + fast-math

$ gcc -Ofast -ffast-math -march=native main.c -o main-c && ./main-c 3000
24.296654
-287.250083
$ clang -Ofast -ffast-math -march=native main.c -o main-clang && ./main-clang 3000
24.955027
-287.250083
$ rustc +nightly -C opt-level=3 -C lto -C target-cpu=native main.rs -o main-rs && ./main-rs 3000
time = 24.200126275s
n = 3000
result = -287.25008333333216
anonymous
()
Ответ на: комментарий от vertexua

Но вывод неправильный. Ты пытаешься кренить в сторону что мол язык такой убогий что фундаментально невозможно написать аналоги Gtk/Qt.

Почему фанаты такие категоричные? Я не говорю, что раст убогий, где я это писал? Просто в расте идет перекос в сторону одной единственной фичи, и в ущерб другим характеристикам языка. Здесь люди писали уже, что на расте сложнее чем на других языках создавать приложения, где используются сложные иерархические структуры данных. В силу особенностей языка. Потому что за все нужно платить.

А реально это просто на данном этапе уже никому не нужно

Ну как это не нужно то? То вы стремитесь RiR, то «не нужно». Фанбой детектед. И это уже второе противоречие с самим собой. Такой реакцией вы только кормите царя.

yetanother ★★
()
Ответ на: комментарий от anonymous

А где без? То есть просто с -O3?

Включать -fast-math при включенном -Ofast смысла нет, он уже включается во втором случае.

grem ★★★★★
()

Давай я тебе объясню почему твой бенчмарк говно и почему он ничего не бенчит, хотя я уже это тебе говорил.

Смотри, у тебя есть две матрицы. Одну сразу выкидываем - нам на неё насрать.

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

Таким образом алгоритм твой чисто memory-bound. Для справки - скорость памяти - это максимум до 50-60 гигов на ведро на интеле. В среднем в районе 30-40.

Скорость вычислителя - 64(на бичёвых avx)(на самом деле в 3раза больше, но мы считаем в данном кейсе) байта на такт. Т.е. ~60 гигов на ггц. Т.е. по-сути твоё говно ничего не бенчит, а бенчит чтение памяти.

Почему здесь помогает Ofast - потому что скорость чтения 8 байтными мувами - 16 байт на такт отовсюду. Но этого мало. Процессор может читать ограниченное кол-во операций за такт. Тебе нужно прочитать данные из двух мест, сложить их, записать куда-то. Таким образом при векторизации оно начинает читать большими кусками и остаётся место для всякого раст-говна.

Поэтому, если ты хочешь бенчить реальную производительность - тебе нужно либо менять алгоритм, что будет сложно. Либо умножать маленькие матрицы, которые вмещаются в l2/l1. l3 - говно.

anonymous
()
Ответ на: комментарий от anonymous

Я выше написал ответ на эту херню, читай выше. К тому же, клоун, где версии gcc/clang?

anonymous
()
Ответ на: комментарий от grem
--- main.rs	2019-09-27 17:34:04.965922630 +0300
+++ main.rs	2019-09-27 17:35:12.445924881 +0300
@@ -1,6 +1,4 @@
-#![feature(core_intrinsics)]
-
-use std::{env, intrinsics::fadd_fast, time::Instant};
+use std::{env, time::Instant};
 
 fn matrix_new(n: usize) -> Vec<f64> {
     let n = n as isize;
@@ -33,7 +31,7 @@
 fn inner_product(init: f64, a: &[f64], b: &[f64]) -> f64 {
     a.iter()
         .zip(b)
-        .fold(init, |acc, (&x, &y)| unsafe { fadd_fast(acc, x * y) })
+        .fold(init, |acc, (&x, &y)| x * y + acc)
 }
 
 fn main() -> Result<(), &'static str> {
$ gcc -O3 -march=native main.c -o main-c && ./main-c 3000
35.548648
-287.250083
$ clang -O3 -march=native main.c -o main-clang && ./main-clang 3000
38.556208
-287.250083
$ rustc -C opt-level=3 -C lto -C target-cpu=native main.rs -o main-rs && ./main-rs 3000
time = 38.602768895s
n = 3000
result = -287.25008333333216

anonymous
()
Ответ на: комментарий от vertexua

А уж когда одно накладывается на другое, то получаем то, что имеем. Или не имеем, как GUI в Rust-е :)

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

andalevor ★★★
() автор топика
Ответ на: комментарий от vertexua

Но вывод неправильный. Ты пытаешься кренить в сторону что мол язык такой убогий что фундаментально невозможно написать аналоги Gtk/Qt. А реально это просто на данном этапе уже никому не нужно

Ты такой смешной, сектант. «Нет на Расте, значит, GUI никому не нужен». GUI это не только Gtk/Qt и даже не только «retained mode gui», особенно в gamedev'е. Как видно из следующей статьи, на Расте не написать даже чего попроще:

https://hackernoon.com/why-im-dropping-rust-fd1c32986c88

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

anonymous
()
Ответ на: комментарий от eao197

Что именно?

Половина виндовых прог не масштабируется. У меня у самого Win10 с 4к, я это постоянно наблюдаю.

Опять же, традиционные виджеты здесь каким боком?

А кто их отрисовывает? libastral?

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Половина виндовых прог не масштабируется

Вы не поверите, но когда начался переход с 640x480 на 1024x768, было тоже самое. Проблема не в Windows, а в том, что горепогромисты не знают, что такое пункты, и хардкодят размеры контролов в пикселях.

А кто их отрисовывает?

От тулкита зависит. Но, опять же, что в принципе мешает тулкиту делать нормальное масштабирование?

eao197 ★★★★★
()
Ответ на: комментарий от andalevor

Но как быть если мне действительно надо гонять большие объемы данных?

Дело в не в том, что тебе нужно гонять. Проблема первая - бенчмарк ничего не бенчит. Он не бенчит ни возможности работы с памятью, ни возможности работы с cpu.

Объём может доходить до сотен Гб и надо взять кусок, что-то сделать и записать, взять следующий и так до конца. И иногда задача будет тривиальной, а иногда очень затратной.

Это ничего не значит. При работе с памятью так же есть свои нюансы. Никакие хомячки и мусорными растами тебе в этом не помогут. Причин много и ущербность самого недоязычка - это не самая большая твоя проблема. Твоя проблема - это нулёвость адептов.

Давай ещё раз. Здесь бенчмарк мусорный не потому, что используется много памяти, либо используется память. Здесь используется мусорный кейс - по-сути ты долбишь read на память. В реальном мире тебе почти никогда ненужно долбить read на память. У тебя почти всегда будет всё упираться в логику. И неважно что эта логика делает.

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

За примерами далеко ходить ненужно - ими завален лор/хабр. Вон тебе про гигабайты память: https://habr.com/ru/users/veslemay/comments/page3/ там тема про хаскель. Инвалиды про память не знают базовые вещи.

Поэтому, если ты хочешь что-то сравнивать - сравнивай что-то адекватное. Смотри первоисточники, ведь это крайне важно. Как только ты уйдёшь из мира С/С++ и у тебя возникнут проблемы - ты будешь потерян, сразу. Причины просты - раст-адепты несостоятельны. Одно дело спастить сишный код через unsafe и ffi, а другое дело его родить. И если это будет что-то, что неоткуда украсть - адепты тебе уже не помогут.

anonymous
()
Ответ на: комментарий от RazrFalcon

Все потому что ты илитка полпроцентная со своим 4k. У остальных никаких проблем с дедовскими гуи нет.

anonymous
()
Ответ на: комментарий от RazrFalcon

Половина виндовых прог не масштабируется.

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

anonymous
()
Ответ на: комментарий от anonymous

Все потому что ты илитка полпроцентная со своим 4k. У остальных никаких проблем с дедовскими гуи нет.

Подписываюсь под каждым словом.

P.S. Гордый пользователь 1440x900 монитора. 🔍👴

anonymous
()
Ответ на: комментарий от andalevor

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

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

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

В конечном итоге чем дальше - тем большая жопа. Даже самые адекватные адепты раста не выдерживают. Вначале тебе расскажут, что итераторы в крестах сложные, они говно. Зачем там какие-то разделения, зачем статика, зачем шаблоны. А потом бам и нужно запилить то, что я тут пастил. И всё, уже сразу оказывается, что итераторы говно.

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

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

Когда же ты берёшь раст-говно - никакого опыта у сектантов нет, никакого использования - нет. И весь этот мусор у тебя в руках рассыпается, потому что он фейковый. Его нет. Это обман.

anonymous
()
Ответ на: комментарий от eao197

хардкодят размеры контролов в пикселях

Это только одна из проблем. Много кода в принципе рассчитано на 96dpi.

Но, опять же, что в принципе мешает тулкиту делать нормальное масштабирование?

Спросите у M$. Qt до 5.6 в принципе не умел масштабировать виджеты (хотя баги до сих пор есть). GTK2/Tk тоже не умеют.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Много кода в принципе рассчитано на 96dpi.

Разверните мысль. В Windows еще со времен 3.0 можно было узнать какой DPI у дисплея.

Спросите у M$. Qt до 5.6 в принципе не умел масштабировать виджеты

Какое отношение M$ имеет к Qt? Ведь Qt, насколько я помню, сама пытается на каждой платформе нативный look-and-feel эмулировать.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

В Windows еще со времен 3.0 можно было узнать какой DPI у дисплея.

Можно конечно, но 95%-м пофиг. Я вообще хз как масштабирование в винде устроено. Последний раз когда я дёргал winapi для окна, оно возвращало размеры в пикселях, а не в поинтах, из-за чего приходилось перегонять всё вручную.

Ещё одна проблема - встраиваемые виджеты, типа виджета для DirectX/OpenGl. Они тоже ничего не знаю о DPI. Если автор не потрудился подумать об этом - получим ерунду. У меня даже была как-то работёнка, где я подобную прогу фиксил. Она тупо четверть виджета отрисовывала и всё.

Про иконки вообще молчу. Это типичная беда. И тут не важно растр или вектор - pixel perfect всё равно не достичь без редизайна под каждый размер (см. иконки breeze в kde).

Ещё одна большая проблема - дробный масштаб. Он нигде нормально не работает и поддерживать его тоже боль. Одно дело рисовать 2 пикселя вместо одного, а другое - 1.25 Придётся выкручиваться.

И таких примеров полно. Но зачастую это типичный тяп-ляп и в продакшен. У меня по работе macOS обязателен, а там HiDPI уже давно повсеместно, поэтому мне деваться некуда.

Какое отношение M$ имеет к Qt?

Большинство прог ведь на нативных тулктах. И там всё очень плохо. Взять тот же dependency walker, там и текст не масштабируется. Даже у таких титанов как Adobe, масштабирование строго фиксированное. Могу ошибаться, но 300% и 400% ещё не завезли. Хотя разницы-то никакой - меняешь коэффициент и всё. А нет.

Ведь Qt, насколько я помню, сама пытается на каждой платформе нативный look-and-feel эмулировать.

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

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

PS: HiDPI, и GUI в целом, - это моя больная тема, да.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Бездарность и без аутизма? Сильно.

anonymous
()
Ответ на: комментарий от RazrFalcon

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

Virtuos86 ★★★★★
()
Ответ на: комментарий от RazrFalcon

В свое время (правда, это было в середине 90-х), мы делали все самостоятельно: запрашиваешь у Windows размер экрана в мм и размер в пикселях, после чего вычисляешь DPI и пляшешь дальше от этого параметра. Но у нас была специфика. Нам нужно было показывать на экране и распечатывать на принтере технологические схемы, поэтому проще оказалось сразу привязаться к пунктам/миллиметрам и для отображения на экран, и для отображения на принтер. Плюс мы работали практически поверх голого WinAPI, без всяких OWL/VCL/MFC.

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

Внимания требовали контролы, которые приходилось создавать в окнах вручную, т.к. везде нужно было работать с пикселями. Характерный пример – статус-бар, который тогда многие любили делать высотой в 10px.

В таких случаях мы поступали проще: рассчитывали размер нужных нам контролов исходя из долей общего размера экрана. Скажем, высота статус-бара была 10% от высоты экрана. А уж сколько пикселей там получится зависело от разрешения. Соответственно, внутри статус-бара размер шрифта рассчитывался исходя из фактической его высоты.

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

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

eao197 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Да он же, как супергерой. Вот не нравится им, например, Раст. Но им сложно это аргументировать, а он не пасует перед трудностями. Получается, он реализует их сокровенное желание. Зачем такого игнорировать(?)

Virtuos86 ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

anonymous
()

Шутка.

Rust === Trus

anonymous
()
Ответ на: комментарий от anonymous

При чём тут высота кнопки? Основной посыл Qt Quick Controls 2 - производительность. Больше кода на C++, а не на JS. Быстрее отрисовка. И тд.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

При чём тут высота кнопки?

Вопросов больше не имею. Когда чистый теоретик рассуждает о чем-то - его не переубедишь. А я, если что, Qt-е стили лично фиксил.

anonymous
()
Ответ на: комментарий от eao197

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

В Qt таких проблем нет, так как всё задаётся в поинтах и прозрачно масштабируется (разве что растру нужно вручную dpi указывать).

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Шикарные у вас аргументы - «это не нужно», «все еще впереди».

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

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

yetanother ★★
()
Ответ на: комментарий от yetanother

То есть десятки людей в моззиле дураки и слепо переписывают лису на раст? Тем временем анонимы с лора уже поняли всю бесперспективность раста. Зсб чё.

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

Завязывайте мыслить категориями черное-белое.

yetanother ★★
()
Ответ на: комментарий от yetanother

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

В GUI не все связи равнозначны. Связи по владению образуют дерево. Остальные связи можно сделать на слабых указателях.

автор пишет что бросил раст из-за этого

Не, там автор пишет, что каждый раз проверять хэндлы на каждый вызов wayland в GUI приложении он не хочет. Проверка хэндла: одно сравнение значения в регистре с нулём, один условный переход. Условие практически никогда не выполняется, у предсказателя ветвлений проблем нет. Цена: около одного такта процессора, в программе нужно писать знак вопроса после вызова функции и вручную чистить ресурсы в соответствующем коллбэке.

Поэтому он решил разработать систему для получения статических гарантий при работе с ресурсами, которые могут появляться и исчезать не под контролем программиста (подключение/отключение монитора, например) заодно с системой автоматического управления памятью под ресурсы. И не смог.

red75prim ★★★
()
Ответ на: комментарий от yetanother

И были уже конкретные ссылки про то, что не смогли люди написать на расте

И было обсуждение, которое некоторые не осилили прочитать. Спойлер: ТС пытался натянуть сову на глобус и у него не вышло. Но виноват конечно же rust.

RazrFalcon ★★★★★
()
Ответ на: комментарий от red75prim

У этого автора другой момент, который заключается в том, что чтобы писать на расте по факту нужно чтобы весь стек был на расте, иначе приходится городить жуткие костыли и вообще все непросто. На мой взгляд это вполне логично, раст предоставляет определенные гарантии, но чтобы они выполнялись он тоже предъявляет определенные требования по принципу за все нужно платить. Это и делает раст нишевым языком, потому что не всегда требования раста выполняются. На низком уровне, например, где реальное железо, а не абстрактная красивая модель, без unsafe уже не обойтись вообще никак, что как бы сводит на нет все гарантии.

А так да, я имел в виду другую статью, которую анонимус привел.

yetanother ★★
()
Ответ на: комментарий от yetanother

без unsafe уже не обойтись вообще никак, что как бы сводит на нет все гарантии

Вы так и не поняли суть раста. unsafe не какая-то опциональная фича - это часть языка. Я сомневаюсь, что в принципе можно получить бинарь, который бы ни разу не задействовал unsafe.

Суть в чётком разделении Safe Rust и Unsafe Rust.

Читать до просветления: https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

RazrFalcon ★★★★★
()
Ответ на: комментарий от yetanother

без unsafe уже не обойтись вообще никак, что как бы сводит на нет все гарантии.

Вот почему история с динозавром («Или встречу, или нет, значит 50%») - это анекдот, а «гарантия не 100%, значит никаких гарантий нет» - нет?

red75prim ★★★
()
Ответ на: комментарий от anonymous

Боже мой, да сколько можно тыкать одной единственной статьей, одного единственного инженера-истерички из 2016го года.

Это как эталонный пример anecdotal evidence, достанутого из жопы, чтобы покормить свой confirmation bias (недостаток человеческого мозга выраженный в cклонности к подтверждению своей точки зрения). Надо в книгу по психологии это.

Когда жаба тормозит, то вся планета орет что жаба тормозит. Это очевидно всем у кого не лапти не на глазах. Другое дело что это бывает не важно для задачи, не в том месте узкое место или не так формируется стоимость решения.

Или реально одно и то же c Rust «но как же циклические графы, я хочу чтобы и в них компилятор угадывал кто чем владеет!».

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.