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

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

Надо бы поковыряться в мейкфайлах, чтобы повылавливать более точные тайминги.

Кстати, раз уж разговор зашёл о фронт- и бэкендах. Rust - это же всего лишь фронтэнд к LLVM. Этак будет порядок да и не один.

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

А, может, это из-за монстроидальной debug-инфы от плюсов?

Кстати, раз уж разговор зашёл о фронт- и бэкендах. Rust - это же всего лишь фронтэнд к LLVM. Этак будет порядок да и не один.

При сборке rustc собирается и LLVM, так что нет, не будет.

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

А, может, это из-за монстроидальной debug-инфы от плюсов?

Ты утверждаешь, что у Go компактная отладочная информация, поэтому, при сравнимом объеме кода, объем бинарей в 40 раз меньше, чем у Си++?

При сборке rustc собирается и LLVM, так что нет, не будет.

LLVM такой модульный, значит, что emscripten и rustc вместо положенной линковки собирают свою версию.

Ты утверждаешь, что у Go компактная отладочная информация, поэтому, при сравнимом объеме кода, объем бинарей в 40 раз меньше, чем у Си++?

Не на 100%, разумеется, но какую-то значительную часть, да.

LLVM такой модульный, значит, что emscripten и rustc вместо положенной линковки собирают свою версию.

И? Ты видишь в этом противоречие? Расскажи, в чем оно.

Ты утверждаешь, что у Go компактная отладочная информация, поэтому, при сравнимом объеме кода, объем бинарей в 40 раз меньше, чем у Си++?

Не на 100%, разумеется, но какую-то значительную часть, да.

Не на 100% что - ты не на 100% уверен? Ты не на 100% утверждаешь? Оно не на 100% компактнее? В любом случае, хотелось бы знать, на основании чего сделано утверждение.

И? Ты видишь в этом противоречие? Расскажи, в чем оно.

gcc - не модульный: хочешь использовать его в качестве бэкенда - внедряйся в его кодовую базу, мэйкфайлы и компилируй gcc (например, как в ghdl). Потом на сцену вышел модульный llvm. Наконец-то не надо трогать бэкенд. Бери инклюды, линкуй - и готово (собрать ghdl с llvm и nvc стало совсем просто). Ещё go-llvm и другие. Но модульность LLVM, очевидно, всё ещё сырая, раз для emscripten и rustc недостаточно линковать, а нужно собирать свой. emscripten вылетел из Debian из-за этого. Странно, что rustc тоже не выкинули.

Не на 100% что - ты не на 100% уверен? Ты не на 100% утверждаешь? Оно не на 100% компактнее? В любом случае, хотелось бы знать, на основании чего сделано утверждение.

Те 40 раз не на 100% из-за debug-инфы. Чутьё.

Но модульность LLVM, очевидно, всё ещё сырая

Лично мне очевидно, что в rustc свой форк LLVM (в emscripten, вероятно, тоже).

Кстати, время полной сборки (rustc + LLVM) не показательно для оценки скорости rustc, т.к. значительную часть времени занимает сборка LLVM на Си++.

Те 40 раз не на 100% из-за debug-инфы.

Конечно. 40 раз - это потому, что кода меньше. В связи с чем сравнение времен компиляции бессмысленно.

Кстати, раз уж разговор зашёл о фронт- и бэкендах. Rust - это же всего лишь фронтэнд к LLVM. Этак будет порядок да и не один.

При сборке rustc собирается и LLVM, так что нет, не будет.

Не нашёл в логе Debian, где там собирается LLVM.

$ ldd /usr/lib/x86_64-linux-gnu/librustc_llvm-7307c5aeac68d856.so 
	linux-vdso.so.1 (0x00007ffcad7aa000)
	libLLVM-4.0.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1 (0x00007fed9d2fb000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fed9cf76000)
	libstd-554069761594509f.so => /usr/lib/x86_64-linux-gnu/libstd-554069761594509f.so (0x00007fed9cc75000)
...