А firefox 57 всё ещё на безопасном уличном мозилловском С++ или уже на безопасном мозиловском расте?

https://wiki.mozilla.org/Oxidation#Completed

эх, у них так всё запутано, что сходу и не разберёшься

А пример файла можно?

кто из них наиболее безопасно повесил мне систему нахрен

Скорее всего, систему себе завесил ты, когда отключил своп.

Дальше кури, что такое memory safety и что именно она гарантирует.

Ты забыл ссылку прикрепить http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/

Если системник не упал на бок, значит повис безопасно.

Я не забыл, что у собеседника есть доступ к гуглу.

Начни с установки Firefox 59.

своп включён

там swf примерно метров на 100 переименованный в .html

Значит, благодари драйверы. Или прямо X-сервер, который даже C-A-B перестал ловить.

Да он уже при открытии 6 мб текста у меня сжирал 2 гб и падал.

Зависла система, а виновата программа? Поздравляю, у тебя DOS/Win9x

На C++ и некоторые части на Rust.

Как раз таки и надо своп отключать. Сталкивался с таким на ВК, огнелис вдруг начинал бешено жрать память и система свопилась с лютой скоростью. Естественно, всё намертво висит. А так пришёл бы oom-killer.

Прохладна былина твоя.

Программа из юзерспейса повесила систему? Мне кажется, тут не в программе дело.

Хватит так уныло тролить раст.

Пару дней назад наблюдал подобное на mint 18.3 (ubuntu 16.04) с firefox 59, очень удивился. Система не отвечала на Ctrl+Alt+Fx. При этом курсор двигался по экрану как ни в чём не бывало. Выключил долгим нажатием кнопки питания.

ctrl+alt+backspace не сработал

И не должен, он не для этого; осиль Alt+SysRq+F.

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

А раст-то тут причём? Это - инструмент. Если кто-то порезался безопасной бритвой, то виновата не бритва.

SysRq

такая клавиша отсутствует на моей клавиатуре

PrintScreen.

отсутствует на макбучных клавах, возможно эмулируется каким-то из Fn+что-то

Какой-то софтинкой ремапили клаву на макбуках, вроде.

Так менее уныло: Use opt-level=1 for Rust code by default? Потому что сильно тормозной компилятор. Но 2 - это ещё не предел, есть 3.

А кто быстрее? Неужто C++? То-то chromium у меня по 6 часов собирается.

А кто быстрее? Неужто C++?

Rust или C++ точно не знаю. А вот C и тем более Go точно быстрее :)

Судя по https://salsa.debian.org/chromium-team/chromium/commit/574f50058c936fbd400d6c... что-то там с хромиумом вообще не то:

chromium-browser (66.0.3359.26-2) unstable; urgency=medium

* Build using gcc6.

Sun, 08 Apr 2018 03:11:08 +0000

А чего им тормозить если в них нету никаких проверок. Я молчу про дженерики.

А чего им тормозить если в них нету никаких проверок.

Статический анализатор - полезная вещь, но зачем же его в компилятор запихнули, так что он при каждой компиляции активен, а не скажем только каждые N запусков компилятора?

Я молчу про дженерики.

Интересно, кто-то уже бенчил компиляцию более менее похожего C++ (или Rust) кода с дженериками и без.

Статический анализатор

Это не стат. анализатор, а часть гарантий языка.

Интересно, кто-то уже бенчил компиляцию более менее похожего C++ (или Rust) кода с дженериками и без.

На предмет чего? Ясное дело дженерики сильно тормозят компиляцию.

А так пришёл бы oom-killer.

У него с целкостью обычно большие проблемы.

SysRq

такая клавиша отсутствует на моей клавиатуре

беда и печаль.

Это не стат. анализатор, а часть гарантий языка.

Пусть и часть, но что это по сути, если не такой себе статический анализатор?

На предмет чего? Ясное дело дженерики сильно тормозят компиляцию.

От каких дженериков тормозит больше.

но что это по сути, если не такой себе статический анализатор?

У вас очень странное представление о Rust. Это не C++ + стат. анализатор, как вам видимо кажется.

От каких дженериков тормозит больше.

В смысле? В каком языке они медленнее? Зависит от самих дженериков. Они везде разные.

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

А зачем «статический анализатор» попроще запихнули в Си, ты понимаешь?

У вас очень странное представление о Rust. Это не C++ + стат. анализатор, как вам видимо кажется.

Надо же с чем-то знакомым сравнить.

В смысле? В каком языке они медленнее? Зависит от самих дженериков. Они везде разные.

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

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

А зачем «статический анализатор» попроще запихнули в Си, ты понимаешь?

Попроще - это более менее насущная необходимость.

Те, что попроще, стали насущной необходимостью 30 лет назад. С тех пор проекты несколько усложнились, а компьютеры несколько ускорились (несколько - это имеется в виду несколько порядков).

Но когда время компиляции падает на порядок

Давай два порядка. Или даже три - чего их жалеть.

Те, что попроще, стали насущной необходимостью 30 лет назад. С тех пор проекты несколько усложнились, а компьютеры несколько ускорились (несколько - это имеется в виду несколько порядков).

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

Давай два порядка. Или даже три - чего их жалеть.

Так сами мозиловцы предложили укрутить оптимизацию. Вот мне и показалось: раз уж так, то надо уже начинать чинить проблему: rustc.

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

А ты не замечаешь? Пора перестать писать на Си в nano - производительность и поднимется.

Но когда время компиляции падает на порядок

Давай два порядка. Или даже три - чего их жалеть.

Так сами мозиловцы

Сами мозиловцы сказали «на порядок»? Можно цитату?

А ты не замечаешь? Пора перестать писать на Си в nano - производительность и поднимется.

nano практически не приходилось использовать. vim.

Сами мозиловцы сказали «на порядок»? Можно цитату?

Так сами мозиловцы предложили укрутить оптимизацию.

Про порядок говорил я, сравнивая скорость компиляции rust.

А ты не замечаешь? Пора перестать писать на Си в nano - производительность и поднимется.

nano практически не приходилось использовать. vim.

Да никакой разницы. Кстати, vim - жирное поделие, требующее памяти больше, чем Linux 1.0

Про порядок говорил я

Так не ссылайся на Мозиллу, приведи свои цифры. А нет цифр - ври про два порядка, или три - не жалей, короче.

У C++ и Rust разные реализации дженериков. Сравнивать в лоб не выйдет. Всё очень сильно зависит от кода, а не от компилятора.

Но в среднем по больнице раст не то чтобы уступает gcc/clang. Цифр, естественно, - нет.

А вот сравнение с сишкой и го абсолютно бессмысленно.

https://buildd.debian.org/status/logs.php?pkg=rustc

rustc    1.25.0+dfsg1-1~exp2 (experimental)

Architecture    Build date             Builder
amd64           2018-04-07 04:48:05    binet

Build time    Disk space
3h 15m        4.93 GB

https://buildd.debian.org/status/logs.php?pkg=gcc-8

gcc-8    8-20180402-1 (sid)

Architecture    Build date             Builder
amd64           2018-04-03 03:58:35    binet

Build time    Disk space
5h 39m        22.36 GB

https://buildd.debian.org/status/logs.php?pkg=golang-1.10

golang-1.10    1.10.1-3 (sid)

Architecture    Build date             Builder
amd64           2018-04-22 22:58:47    binet

Build time    Disk space
18m           586.83 MB

И это доказывает... что именно? Что порядок производительности gcc8 и rustc одинаков? Или что сборка Go вообще мошенничает (судя по используемому дисковому пространству)?

А firefox 57 всё

Можно порассуждать, что именно.

В отличие от rustc, во время компиляции gcc-8 входят C, C++, D (gdc), Fortran, Ada (gnat), gccgo, Objective C, Objective C++ и при этом мультилиб (+i386, +x32) (кроме gnat).

Или что сборка Go вообще мошенничает (судя по используемому дисковому пространству)

А что с ним не так? В предыдущих логах 300..400+ МБ.

Можно порассуждать, что именно.

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

во время компиляции gcc-8 входят C, C++, D (gdc), Fortran, Ada (gnat), gccgo, Objective C, Objective C++ и при этом мультилиб

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

Или что сборка Go вообще мошенничает (судя по используемому дисковому пространству)

А что с ним не так?

Оно в 40 раз меньше, чем у gcc, с которым ты сравниваешь. Что намекает на гораздо меньший объем выполненной работы.