Рискну предположить, что у тех, у кого не воспроизводится, редактор пишет изменённый код в новый файл, который затем переименовывает поверх старого (чтобы гарантировать атомарность обновления). В таком случае у баша останется дескриптор старого файла, содержимое которого не менялось.
Замену в чём именно? В идеале предполагается заменить им LLVM для дебаг-билдов, потому что производительность LLVM — один из ключевых факторов, ограничивающих скорость их сборки.
Можно ли написать на Расте бэкенд с производительностью кода не хуже, чем у LLVM? Зависит от того, сколько человеко-лет в него вложить...
Я не так много вращался в Джаве и довольно много (но колхозно) вращаюсь в Шарпе, но мне, черт побери, нравится многословность и CamelCase. Это сделано для людей, а все остальное решает IntelliSense и нормально спроектированные библиотеки.
Лично мне кажется, что одним из критериев полноценного языка программирования является возможность сравнительно эффективно читать и писать код на этом языке без средств поддержки, конкретно под этот язык заточенных.
Без фанатизма – всё-таки подсветка синтаксиса сильно облегчает жизнь, не говоря уже про нормальную работу с отступами – но это вещи, которые умеет любой приличный редактор кода. А вот автодополнение и всплывающие подсказки типов уже должны бы быть опциональны для эффективной работы.
Не говоря уже про языки, обязывающие использовать единственную фирменную IDE, наподобие какого-нибудь там LabVIEW.
До тех пор, пока они локализованы, можно обойтись крейтами, собирающими и подключающими отдельные ассемблерные файлы. Quickstart для ARM не требует ночника.
Вот для чего потребуется nightly-версия — так это для тех архитектур, для которых недоступен собранный крейт core. Вот для его сборки, в первом приближении, обязательна nightly-версия.
Так в том-то и дело, что меня вполне устроит в качестве ответа линтер, который банит потенциально корректный код. Если он скажет "написанный так код потенциально опасен, так нельзя, пользуйтесь абстракцией такой-то" — оно и к лучшему. Если мне действительно будет нужно — найду в документации, как разрешить данное конкретное нарушение правил линтера (а заодно прочитаю, чем именно оно опасно, на что именно нужно проверить код вручную и о чём нужно предупредить комментарием следующего разработчика).
Не устраивает меня ситуация, в которой "разумеется, C++ позволяет всё это безопасно написать, но чтобы быть уверенным хотя бы на 90% в безопасности написанного, обязательно необходим ревьюер с опытом в современном C++ от N лет". Новые проекты в опенсорсе нередко начинаются с одного человека (или маленькой команды), и я не понимаю, как сейчас начать проект на современном C++ без хождения по всем стандартным граблям с нуля.
А можно небольшую просьбу от человека, знакомого с C, Rust, но плюсы знающего исключительно на уровне "Си с классами"?
В дискуссиях "C++ vs Rust" регулярно используется довод, что в C++ можно делать всё не менее безопасно, чем на Rust, и наверняка хорошо известно, что именно для этого требуется. Скорее всего, и компиляторы / линтеры это должны уметь.
Не могли бы вы (в значении "эксперты по языку C++", не обязательно лично Вы) показать пример конфигурации открытого компилятора и/или открытых линтеров, обеспечивающих адекватную степень безопасности? Чтобы была возможность начать проект на C++, включить их в этой конфигурации и быть уверенным, что они дадут мне по рукам, когда я случайно использую malloc вместо make_unique / напишу код с ошибкой инвалидации итератора / сделаю какую-нибудь ещё глупость, про которую я просто не в курсе. Потому что за себя я уверен, что даже если я прочитаю от корки до корки C++ Core Guidelines, как минимум поначалу такие ошибки всё равно будут.
Вот, например, clang-tidy --checks=cppcoreguidelines-*,modernize-* — это адекватно, избыточно или недостаточно?
А добавьте пожалуйста для Rust опцию -C target-cpu=native для более честного сравнения с C(++). На моём Skylake она снижает время работы приведённого кода с 0.65 секунды до 0.55.
(update: вижу, выше уже предлагали, но поиск по Rust тот комментарий не нашёл ввиду русскоязычного написания)
С прискорбием вынужден не согласиться. Нередко код потребляет много ресурсов не потому, что он простой, а потому, что он одновременно сложный и неоптимальный.
В Firefox есть точно та же проблема, только максимальная "короткая" строка не 12 байт, как в Chrome, а 23 / 11 символов (для Latin1 / двухбайтных — см. раздел inline strings по ссылке). На 24 символах проблема воспроизводится. Кстати, следует учитывать, что выбор режима между Latin1 и двухбайтным выполняется исключительно по тому, в каком режиме была изначальная строка — то есть если там был Юникод за пределами Latin1, то и все подстроки будут оставаться ссылками по лимиту в 11 символов, а не 23.
Что ещё веселее, если внимательно посмотреть на результаты теста в JSPerf на Firefox, то окажется, что "решение" через (' ' + str).slice(1) работает за время, не зависящее от длины подстроки. Дело в том, что в Firefox эта операция выполняется через строку типа Rope и не приводит к "отсоединению" от базовой строки, то есть не выполняет свою задачу. Лишний раз видим, что самые быстрые решения зачастую оказываются менее надёжными.
Длина свободного пробега молекул порядка единиц микрометров — это очень «грубый» вакуум. С точки зрения самого давления сойдёт, но, например, с точки зрения разрядов в высоковольтной электронике при пониженном давлении всё самое интересное начинается не выше единиц паскалей, сколько я помню… и заканчивается ещё на пяток порядков ниже, когда концентрация становится недостаточной для опасных пробоев.
Это и есть каталог, там отдельные файлы для разных смонтированных файловых систем. Защищать от создания файлов не пробовал, т.к. правильнее решить проблему в самом Firefox.
С Firefox на Linux всё не так хорошо, как хотелось бы. С версии 19 (изначальный репорт) он пишет эту информацию в хранилище GIO/GVFS (бинарную базу данных, находящуюся в ~/.local/share/gvfs-metadata). Проверить можно командой gio info $filename.
Что хуже, в приватном режиме он тоже это делает, о чём я оставил bug report.
Вообще говоря, способна. У роверов есть несколько антенн, и сигнал ненаправленной LGA с Земли вполне слышен. Для научных данных она плохо подходит ввиду низкой максимальной скорости, но на сигнал «я тут ещё жив» её бы хватило. Судя по пресс-релизам, пока ровер жив, он должен был ежедневно просыпаться, включать ненадолго этот сигнал и вновь уходить в спячку.
Это ж блин сигнатура функции, она должна говорить про типы параметров, а не требования к производительности определять.
Да, поэтому сигнатуру, которая сразу же ограничивает "а эта функция точно не сможет работать максимально быстро вне зависимости от реализации из-за отсутствия инлайнинга и т. п.", лучше делать явно видимой. Кроме того, dyn Trait не только в сигнатурах может возникать, но и, например, в структурах данных, где подобные ограничения также лучше видеть.
Аргумент с ортогональностью impl Trait тоже неубедителен — в одном случае это кодогенерация, которая делает возможным прежде недоступные вещи, а другое — просто алиас для уже существующей синтаксической конструкции, которую придется деприкейтить и писать тулзы для миграции.
Аргумент с ортогональностью — он скорее не про возможности, а про обучение. У новичков разница между dyn Trait и impl Trait будет, предположительно, вызывать сильно мешьную путаницу, чем между Trait и impl Trait при использовании в местах, где могут быть оба варианта. Rust и так имеет непростую кривую обучения, так что её локальное упрощение имеет смысл даже ценой небольших миграций.
На ExoMars Trace Gas Orbiter почему-то поставили такой же прибор для поиска воды, который стоял и на Mars Odyssey — хотя зона покрытия у него будет примерно та же.
Строго говоря, не такой же, а более продвинутый. В нем используется нейтронный коллиматор, что по предварительным оценкам позволит на порядок улучшить пространственное разрешение.
В servo есть минимум одна большая и сложная абстракция (интеграция с JavaScript-движком mozjs, вариантом SpiderMonkey, который написан на C++), плюс логические ошибки, которые ловят ручные или автоматические assert-ы разных видов, в некоторых случаях недостаточно оптимизированное потребление ресурсов на особо весёлых страницах (например, slither, создающий более 2000 canvas-ов). Иногда ещё драйверы GPU вылетают.
null в Rust есть только на уровне небезопасных абстракций ("сырые" указатели и им подобное). Да, код, работающий с ними напрямую, должен об этом беспокоиться — но это в худшем случае несколько абстракций, предоставляющих внешнему коду безопасный интрефейс, а не весь объём кода приложения.
Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.
Рискну предположить, что у тех, у кого не воспроизводится, редактор пишет изменённый код в новый файл, который затем переименовывает поверх старого (чтобы гарантировать атомарность обновления). В таком случае у баша останется дескриптор старого файла, содержимое которого не менялось.
Замену в чём именно? В идеале предполагается заменить им LLVM для дебаг-билдов, потому что производительность LLVM — один из ключевых факторов, ограничивающих скорость их сборки.
Можно ли написать на Расте бэкенд с производительностью кода не хуже, чем у LLVM? Зависит от того, сколько человеко-лет в него вложить...
Лично мне кажется, что одним из критериев полноценного языка программирования является возможность сравнительно эффективно читать и писать код на этом языке без средств поддержки, конкретно под этот язык заточенных.
Без фанатизма – всё-таки подсветка синтаксиса сильно облегчает жизнь, не говоря уже про нормальную работу с отступами – но это вещи, которые умеет любой приличный редактор кода. А вот автодополнение и всплывающие подсказки типов уже должны бы быть опциональны для эффективной работы.
Не говоря уже про языки, обязывающие использовать единственную фирменную IDE, наподобие какого-нибудь там LabVIEW.
До тех пор, пока они локализованы, можно обойтись крейтами, собирающими и подключающими отдельные ассемблерные файлы. Quickstart для ARM не требует ночника.
Вот для чего потребуется nightly-версия — так это для тех архитектур, для которых недоступен собранный крейт
core. Вот для его сборки, в первом приближении, обязательна nightly-версия.Cranelift-бэкенд потихоньку прогрессирует, кстати.
Так в том-то и дело, что меня вполне устроит в качестве ответа линтер, который банит потенциально корректный код. Если он скажет "написанный так код потенциально опасен, так нельзя, пользуйтесь абстракцией такой-то" — оно и к лучшему. Если мне действительно будет нужно — найду в документации, как разрешить данное конкретное нарушение правил линтера (а заодно прочитаю, чем именно оно опасно, на что именно нужно проверить код вручную и о чём нужно предупредить комментарием следующего разработчика).
Не устраивает меня ситуация, в которой "разумеется, C++ позволяет всё это безопасно написать, но чтобы быть уверенным хотя бы на 90% в безопасности написанного, обязательно необходим ревьюер с опытом в современном C++ от N лет". Новые проекты в опенсорсе нередко начинаются с одного человека (или маленькой команды), и я не понимаю, как сейчас начать проект на современном C++ без хождения по всем стандартным граблям с нуля.
А можно небольшую просьбу от человека, знакомого с C, Rust, но плюсы знающего исключительно на уровне "Си с классами"?
В дискуссиях "C++ vs Rust" регулярно используется довод, что в C++ можно делать всё не менее безопасно, чем на Rust, и наверняка хорошо известно, что именно для этого требуется. Скорее всего, и компиляторы / линтеры это должны уметь.
Не могли бы вы (в значении "эксперты по языку C++", не обязательно лично Вы) показать пример конфигурации открытого компилятора и/или открытых линтеров, обеспечивающих адекватную степень безопасности? Чтобы была возможность начать проект на C++, включить их в этой конфигурации и быть уверенным, что они дадут мне по рукам, когда я случайно использую
mallocвместоmake_unique/ напишу код с ошибкой инвалидации итератора / сделаю какую-нибудь ещё глупость, про которую я просто не в курсе. Потому что за себя я уверен, что даже если я прочитаю от корки до корки C++ Core Guidelines, как минимум поначалу такие ошибки всё равно будут.Вот, например,
clang-tidy --checks=cppcoreguidelines-*,modernize-*— это адекватно, избыточно или недостаточно?А добавьте пожалуйста для Rust опцию
-C target-cpu=nativeдля более честного сравнения с C(++). На моём Skylake она снижает время работы приведённого кода с 0.65 секунды до 0.55.(update: вижу, выше уже предлагали, но поиск по Rust тот комментарий не нашёл ввиду русскоязычного написания)
В Firefox есть точно та же проблема, только максимальная "короткая" строка не 12 байт, как в Chrome, а 23 / 11 символов (для Latin1 / двухбайтных — см. раздел inline strings по ссылке). На 24 символах проблема воспроизводится. Кстати, следует учитывать, что выбор режима между Latin1 и двухбайтным выполняется исключительно по тому, в каком режиме была изначальная строка — то есть если там был Юникод за пределами Latin1, то и все подстроки будут оставаться ссылками по лимиту в 11 символов, а не 23.
Что ещё веселее, если внимательно посмотреть на результаты теста в JSPerf на Firefox, то окажется, что "решение" через
(' ' + str).slice(1)работает за время, не зависящее от длины подстроки. Дело в том, что в Firefox эта операция выполняется через строку типа Rope и не приводит к "отсоединению" от базовой строки, то есть не выполняет свою задачу. Лишний раз видим, что самые быстрые решения зачастую оказываются менее надёжными.С Firefox на Linux всё не так хорошо, как хотелось бы. С версии 19 (изначальный репорт) он пишет эту информацию в хранилище GIO/GVFS (бинарную базу данных, находящуюся в
~/.local/share/gvfs-metadata). Проверить можно командойgio info $filename.Что хуже, в приватном режиме он тоже это делает, о чём я оставил bug report.
Да, поэтому сигнатуру, которая сразу же ограничивает "а эта функция точно не сможет работать максимально быстро вне зависимости от реализации из-за отсутствия инлайнинга и т. п.", лучше делать явно видимой. Кроме того,
dyn Traitне только в сигнатурах может возникать, но и, например, в структурах данных, где подобные ограничения также лучше видеть.Аргумент с ортогональностью — он скорее не про возможности, а про обучение. У новичков разница между
dyn Traitиimpl Traitбудет, предположительно, вызывать сильно мешьную путаницу, чем междуTraitиimpl Traitпри использовании в местах, где могут быть оба варианта. Rust и так имеет непростую кривую обучения, так что её локальное упрощение имеет смысл даже ценой небольших миграций.Строго говоря, не такой же, а более продвинутый. В нем используется нейтронный коллиматор, что по предварительным оценкам позволит на порядок улучшить пространственное разрешение.
В servo есть минимум одна большая и сложная абстракция (интеграция с JavaScript-движком mozjs, вариантом SpiderMonkey, который написан на C++), плюс логические ошибки, которые ловят ручные или автоматические assert-ы разных видов, в некоторых случаях недостаточно оптимизированное потребление ресурсов на особо весёлых страницах (например, slither, создающий более 2000
canvas-ов). Иногда ещё драйверы GPU вылетают.nullв Rust есть только на уровне небезопасных абстракций ("сырые" указатели и им подобное). Да, код, работающий с ними напрямую, должен об этом беспокоиться — но это в худшем случае несколько абстракций, предоставляющих внешнему коду безопасный интрефейс, а не весь объём кода приложения.Так, например, стек ядра каждого потока — это от 8k, то есть две последовательные страницы памяти, на большей части архитектур.
Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.