Ок, не все ошибки легко ловимы.
Но мы сравниваем "при прочих равных", когда ошибка в конкретном месте, которое можно разными способами дебажить и тестировать, и когда ошибка возникает в таком же месте, но по каким-то стихийным причинам и при определённом схождении звёзд, которые вы будете в этом месте искать до того момента, как поймёте, что ошибки на самом деле здесь нет.
Гонки бывают разные.
Гонки данных — лишь частный случай.
Rust не может исключить те же dead-lock'и на мьютексах, например. Но Rust не позволит просто так взять и забыть освободить мьютекс. И Rust не позволит иметь ссылку на данные, защищённые мьютексом, после его освобождения.
Нет, результат — можно отследить как он был вычислен.
UB, приведшее к невидимой поломке кода, не проявляющейся в отладочной сборке — сильно сложнее обнаружить.
Статический анализ не способен отследить перемещения ссылок для объектов которых еще не существует на момент компиляции
Статический анализ при наличии соответствующих деклараций может гарантировать исключительность ссылок или их иммутабельность. Там, где он не может гарантировать — Вы не сможете использовать бесплатный механизм заимствования в таком виде, и Вам придётся использовать "платные" механизмы доступа/синхронизации в runtime. Цена "платных" механизмов тоже может существенно различаться и у программиста есть выбор. Но это совершенно не значит, что, если в каком-то месте пришлось задействовать runtime, то его придётся использовать везде, как в языках с GC. Механизм заимствований продолжает приносить пользу для всего кода между обращениями к runtime-механизмам.
На самом деле это действительно мощный инструмент, использующий систему типов для исключения большого класса ошибок, которые достаточно трудоёмко отлаживать.
И вместо SIGFAULT вы получите некорректный результат.
Некорректный результат мы получим там, где ошиблись, а не в произвольном месте программы. Вообще никто не обещает, что будет SEGFAULT, а не некорректные значения в месте, где в программе нет ошибок. Получить SEGFAULT, а не мусор в работе корректно алгоритма очень далеко от причины этого мусора — это в каком-то смысле даже удача.
Не то, чтобы, совсем целиком, модульность, если она есть, спасает. Но да, малейшие изменения кодогенератора цепляют крупные куски кода. Особенно, если этот генератор генерирует другие генераторы :-)
Согласен, это более простой случай — если программа успешно собирается, то с ней уже можно как-то работать. IntelliJ строит виртуальное AST и работает с ним, в том числе, и для упомянутого автокомплита, так же как позволяет и полностью развернуть сгенерированный макросами код (без этого вообще очень многое не работало, поскольку в библиотеках Rust очень много сгенерированного кода).
Однако это пока совершенно не касается процедурных макросов. Хотя для Rust и есть практически официальный интерпретатор, который уже используется для некоторых задач в компиляторе, вроде вычисления значений константных функций. Полагаю, со временем, по мере развития, он будет более плотно использоваться.
Всё это в каком-то виде будет переиспользовано и в RLS 2.0, поскольку он в значительной мере пишется с оглядкой на опыт, получаемый с IntelliJ, но я плохо представляю, как с этим будут взаимодействовать другие IDE.
Время работы скрипта между несколькими запросами — порядка десятков миллисекунд (спасибо высокоуровневым ORM решающим уйму вопросов небесплатными абстракциями "просто для удобства").
Время работы скомпилированного кода на Rust с теми же запросами — порядка нескольких миллисекунд.
Этой разницы на порядок в скорости завершения транзакций достаточно, чтобы базе вообще нужно было гораздо меньше вовлекать механизм блокировок.
Хранимые процедуры — да, полезный компромис, но он сложнее в поддержке и имеет немало ограничений. Сам встроенный язык хранимых процедур — не так богат по возможностям. Если приходится думать о таких оптимизациях, база — уже бутылочное горлышко, и нагружать её исполнением интерпретируемого кода — не всегда подходящее решение. Если же это компилируемый код — мы вернулись к выгодам от компилируемого эффективного языка в среднем звене (клиент базы) и как следствие коротких транзакций, в противовес сложности обновления и поддержки хранимых процедур в самой базе и проблеме бутылочного горлышка.
Я не буду спорить с тем, что в предложенном Вами подходе есть рациональное зерно и я сам бы так поступал во многих случаях. Но это скорее вопрос целесообразности и обстоятельств в каждом конкретном случае.
Вот из-за ошибки в работе с базой данных можно потерять намного-намного больше времени.
Ошибку, всё-же, можно обнаружить и исправить. Скорость же работы клиента — это скорее фундаментальное ограничение, исправить которое будет очень дорого.
Проблема, в общем-то, не в том, что компиляторы "мудрят", а в самом дизайне системы с пунктом "человек не должен ошибаться". Если человек что-то пишет, компилятор обязан предполагать, что человек — всё точно продумал и знает, что делает. Этот подход исключительно плохо работает из-за того, что человек невероятно склонен совершать ошибки. И чем сложнее система, тем человеку сложнее удержать в голове все её особенности, а значит вероятность ошибок растёт с развитием возможностей этой системы.
Тут палка о двух концах. Сначала язык даёт возможность, которую иногда куда-то применяют, но не зная зачем она в большинстве случаев, потому что до этого самой возможности не было, не сложилось практики. Потом народ изучает, как эту возможность использовать во благо монетизации и с этого момента она становится исключительно востребованной, и без неё никуда.
Маленький лайфхак: с быстрым клиентом из базы данных можно выжать гараздо больше. Некорректно говорить, что всё упирается в базу данных, если всё упирается в дорогие локи из-за неоправданно долго живущих транзакций.
Сложностью. Взрывообразным ростом сложности. Специфика IDE в том, что она, в отличие от компилятора, должна большую часть своего времени работать с некорректным кодом, как-то догадываясь, что там программист сейчас наживо пишет. При этом помогать программисту нужно с кодом до преобразования, как-то предполагая, что будет в результате преобразования при том, что точного совпадения с правилами преобразования прямо сейчас нет. И это действительно нетривиальная задача по сравнению с "поработать обозревателем преобразований в готовом корректном коде", а тем более, подсказывать исходя из проработанной модели языка, где всё на своих местах.
Собственно, для Rust сейчас эту задачу пытаются решать в IntelliJ и Ferrous Systems. Но уже очевидно, что она — не всегда (или исключительно непросто) решаема.
Конечно пишут. А куда деваться?
Тот случай когда действительно такты процессора считают.
Но я как минимум знаю компании, где от плюсов именно отказались и зареклись.
И вот Rust теперь предлагает эту плюсовую скорость без компромиссов с надёжностью. Его осторожно пробуют и находят лучшей заменой. Разумеется, жизнь сложная штука: не везде и не все, подобное было бы странно утверждать. Природа поощряет разнообразие :-)
Одна из ниш, где Rust уверенно завоёвывает себе место под солнцем — HFT. Как раз по причине того, что нужно максимум скорости, при этом действительно надёжно и без эзотерических багов как в C/С++. Ибо бизнес в случае чего теряет столько, что мало не покажется. До последнего времени здесь доминировала Java.
Как сказать "присматриваются".
Например, один из локомотивов асинхронного Rust — Actix — творение рук одного из сотрудников Microsoft: есть сведения, что очень даже активно используется ин-продакшн. Есть и другие примеры.
Ну, так можно жаловаться на то, что все люди как люди, говорят на простом и понятном английском, а нативные носители английского — на каком-то инопланетном английском. Это язык. Как и любой другой язык, чтобы им полноценно пользоваться — его нужно знать. Иначе будет непонятно.
Ещё есть интересная особенность, касающаяся любого языка: когда у языка появляется новое свойство, большинство, с этим свойством не знакомые, желают более "вербозный" синтаксис. Опытные же пользователи, привыкшие к этому свойству, желают его записывать покомпактней. Этот вопрос регулярно всплывает, когда обсуждается будущий дизайн новых свойств Rust (весь процесс, кстати, происходит открыто и с участием всех желающих).
Даже не знаю, за три года, что пишу на Rust — не замечал проблемы с многословностью.
Но есть хорошая примета, как я уже в соседней ветке сказал: когда начинает получаться слишком много кода для простых вещей — это признак того, что что-то делается очень неправильно и стоит вернуться и проанализировать, почему так получается, нельзя ли как-то проще.
На самом деле здесь больше информации с вполне конкретной целью: мы сообщаем компилятору, "что мы на самом деле имеем в виду". Впоследствии компилятор забирает у разработчиков массу головной боли и ручной работы, проверяя за них "всё ли согласованно написано в программе".
На примере в несколько строчек эта полезность не так заметна и выглядит несколько странно. В крупном же и важном проекте, над которым работает немаленькая команда — можно только молиться на компилятор, который избавляет тебя от сегфолтов и прочих очень неприятных недоразумений, которые можно часами ловить в отладчике, или вообще до часа X не догадываться об их существовании.
Потому что, когда такой час X "пробивает", обычно остаётся только устраивать сеанс спиритизма в три часа ночи, чтобы понять, ГДЕ этот чёртов косяк, из-за которого всё внезапно начало падать или почему остатки на счетах превратились в тыкву, и как это побыстрее исправить, ибо бизнес несёт убытки.
Это, конечно, не серебряная пуля и не избавляет от всех багов вообще, но за то, от чего избавляет — это не такая уж и высокая цена писать всё чуть более многословно. Тем более, разработчики языка постарались насколько это возможно многословность нивелировать синтаксическим сахаром.
Я бы даже добавил, что когда получается слишком раздутый код — в Rust это примета того, что "что-то пошло не так" и используется не лучшее архитектурное решение. Это особенно актуально для новичков, которые пытаются натягивать на Rust привычный стиль написания программ из других языков.
Это звучит очень странно, учитывая, что свойство буквально содержится в корне слова
Это не переменные, это — биндинги. В большинстве случаев переменные не нужны. Поэтому и let mut, чтобы ленивые люди предпочитали не использовать мутабельность там, где она не нужна.
К слову, в Rust вплоне можно перекрывать старое значение с тем же именем: let x = x + 1. Кроме того время жизни биндингов ограничено блоками, где они объявлены. И это тоже позволяет часто обходиться без мутабельности.
Прошу прощения, здесь стоит уточнить: "если мы не ожидаем какое-то конкретное значение". if x == Some(42) и более сложные — точно так же прекрасно работают.
Ок, не все ошибки легко ловимы.
Но мы сравниваем "при прочих равных", когда ошибка в конкретном месте, которое можно разными способами дебажить и тестировать, и когда ошибка возникает в таком же месте, но по каким-то стихийным причинам и при определённом схождении звёзд, которые вы будете в этом месте искать до того момента, как поймёте, что ошибки на самом деле здесь нет.
Гонки бывают разные.
Гонки данных — лишь частный случай.
Rust не может исключить те же dead-lock'и на мьютексах, например. Но Rust не позволит просто так взять и забыть освободить мьютекс. И Rust не позволит иметь ссылку на данные, защищённые мьютексом, после его освобождения.
Нет, результат — можно отследить как он был вычислен.
UB, приведшее к невидимой поломке кода, не проявляющейся в отладочной сборке — сильно сложнее обнаружить.
Статический анализ при наличии соответствующих деклараций может гарантировать исключительность ссылок или их иммутабельность. Там, где он не может гарантировать — Вы не сможете использовать бесплатный механизм заимствования в таком виде, и Вам придётся использовать "платные" механизмы доступа/синхронизации в runtime. Цена "платных" механизмов тоже может существенно различаться и у программиста есть выбор. Но это совершенно не значит, что, если в каком-то месте пришлось задействовать runtime, то его придётся использовать везде, как в языках с GC. Механизм заимствований продолжает приносить пользу для всего кода между обращениями к runtime-механизмам.
На самом деле это действительно мощный инструмент, использующий систему типов для исключения большого класса ошибок, которые достаточно трудоёмко отлаживать.
Некорректный результат мы получим там, где ошиблись, а не в произвольном месте программы. Вообще никто не обещает, что будет SEGFAULT, а не некорректные значения в месте, где в программе нет ошибок. Получить SEGFAULT, а не мусор в работе корректно алгоритма очень далеко от причины этого мусора — это в каком-то смысле даже удача.
Не то, чтобы, совсем целиком, модульность, если она есть, спасает. Но да, малейшие изменения кодогенератора цепляют крупные куски кода. Особенно, если этот генератор генерирует другие генераторы :-)
Согласен, это более простой случай — если программа успешно собирается, то с ней уже можно как-то работать. IntelliJ строит виртуальное AST и работает с ним, в том числе, и для упомянутого автокомплита, так же как позволяет и полностью развернуть сгенерированный макросами код (без этого вообще очень многое не работало, поскольку в библиотеках Rust очень много сгенерированного кода).
Однако это пока совершенно не касается процедурных макросов. Хотя для Rust и есть практически официальный интерпретатор, который уже используется для некоторых задач в компиляторе, вроде вычисления значений константных функций. Полагаю, со временем, по мере развития, он будет более плотно использоваться.
Всё это в каком-то виде будет переиспользовано и в RLS 2.0, поскольку он в значительной мере пишется с оглядкой на опыт, получаемый с IntelliJ, но я плохо представляю, как с этим будут взаимодействовать другие IDE.
Время работы скрипта между несколькими запросами — порядка десятков миллисекунд (спасибо высокоуровневым ORM решающим уйму вопросов небесплатными абстракциями "просто для удобства").
Время работы скомпилированного кода на Rust с теми же запросами — порядка нескольких миллисекунд.
Этой разницы на порядок в скорости завершения транзакций достаточно, чтобы базе вообще нужно было гораздо меньше вовлекать механизм блокировок.
Хранимые процедуры — да, полезный компромис, но он сложнее в поддержке и имеет немало ограничений. Сам встроенный язык хранимых процедур — не так богат по возможностям. Если приходится думать о таких оптимизациях, база — уже бутылочное горлышко, и нагружать её исполнением интерпретируемого кода — не всегда подходящее решение. Если же это компилируемый код — мы вернулись к выгодам от компилируемого эффективного языка в среднем звене (клиент базы) и как следствие коротких транзакций, в противовес сложности обновления и поддержки хранимых процедур в самой базе и проблеме бутылочного горлышка.
Я не буду спорить с тем, что в предложенном Вами подходе есть рациональное зерно и я сам бы так поступал во многих случаях. Но это скорее вопрос целесообразности и обстоятельств в каждом конкретном случае.
Ошибку, всё-же, можно обнаружить и исправить. Скорость же работы клиента — это скорее фундаментальное ограничение, исправить которое будет очень дорого.
Проблема, в общем-то, не в том, что компиляторы "мудрят", а в самом дизайне системы с пунктом "человек не должен ошибаться". Если человек что-то пишет, компилятор обязан предполагать, что человек — всё точно продумал и знает, что делает. Этот подход исключительно плохо работает из-за того, что человек невероятно склонен совершать ошибки. И чем сложнее система, тем человеку сложнее удержать в голове все её особенности, а значит вероятность ошибок растёт с развитием возможностей этой системы.
Тут палка о двух концах. Сначала язык даёт возможность, которую иногда куда-то применяют, но не зная зачем она в большинстве случаев, потому что до этого самой возможности не было, не сложилось практики. Потом народ изучает, как эту возможность использовать во благо монетизации и с этого момента она становится исключительно востребованной, и без неё никуда.
Маленький лайфхак: с быстрым клиентом из базы данных можно выжать гараздо больше. Некорректно говорить, что всё упирается в базу данных, если всё упирается в дорогие локи из-за неоправданно долго живущих транзакций.
Сложностью. Взрывообразным ростом сложности. Специфика IDE в том, что она, в отличие от компилятора, должна большую часть своего времени работать с некорректным кодом, как-то догадываясь, что там программист сейчас наживо пишет. При этом помогать программисту нужно с кодом до преобразования, как-то предполагая, что будет в результате преобразования при том, что точного совпадения с правилами преобразования прямо сейчас нет. И это действительно нетривиальная задача по сравнению с "поработать обозревателем преобразований в готовом корректном коде", а тем более, подсказывать исходя из проработанной модели языка, где всё на своих местах.
Собственно, для Rust сейчас эту задачу пытаются решать в IntelliJ и Ferrous Systems. Но уже очевидно, что она — не всегда (или исключительно непросто) решаема.
Конечно пишут. А куда деваться?
Тот случай когда действительно такты процессора считают.
Но я как минимум знаю компании, где от плюсов именно отказались и зареклись.
И вот Rust теперь предлагает эту плюсовую скорость без компромиссов с надёжностью. Его осторожно пробуют и находят лучшей заменой. Разумеется, жизнь сложная штука: не везде и не все, подобное было бы странно утверждать. Природа поощряет разнообразие :-)
Одна из ниш, где Rust уверенно завоёвывает себе место под солнцем — HFT. Как раз по причине того, что нужно максимум скорости, при этом действительно надёжно и без эзотерических багов как в C/С++. Ибо бизнес в случае чего теряет столько, что мало не покажется. До последнего времени здесь доминировала Java.
Это далеко не так. Большая часть кода вполне хорошо себя чувствует в безопасном подмножестве.
Unsafes in Redox
Как сказать "присматриваются".
Например, один из локомотивов асинхронного Rust — Actix — творение рук одного из сотрудников Microsoft: есть сведения, что очень даже активно используется ин-продакшн. Есть и другие примеры.
Ну, так можно жаловаться на то, что все люди как люди, говорят на простом и понятном английском, а нативные носители английского — на каком-то инопланетном английском. Это язык. Как и любой другой язык, чтобы им полноценно пользоваться — его нужно знать. Иначе будет непонятно.
Ещё есть интересная особенность, касающаяся любого языка: когда у языка появляется новое свойство, большинство, с этим свойством не знакомые, желают более "вербозный" синтаксис. Опытные же пользователи, привыкшие к этому свойству, желают его записывать покомпактней. Этот вопрос регулярно всплывает, когда обсуждается будущий дизайн новых свойств Rust (весь процесс, кстати, происходит открыто и с участием всех желающих).
Даже не знаю, за три года, что пишу на Rust — не замечал проблемы с многословностью.
Но есть хорошая примета, как я уже в соседней ветке сказал: когда начинает получаться слишком много кода для простых вещей — это признак того, что что-то делается очень неправильно и стоит вернуться и проанализировать, почему так получается, нельзя ли как-то проще.
На самом деле здесь больше информации с вполне конкретной целью: мы сообщаем компилятору, "что мы на самом деле имеем в виду". Впоследствии компилятор забирает у разработчиков массу головной боли и ручной работы, проверяя за них "всё ли согласованно написано в программе".
На примере в несколько строчек эта полезность не так заметна и выглядит несколько странно. В крупном же и важном проекте, над которым работает немаленькая команда — можно только молиться на компилятор, который избавляет тебя от сегфолтов и прочих очень неприятных недоразумений, которые можно часами ловить в отладчике, или вообще до часа X не догадываться об их существовании.
Потому что, когда такой час X "пробивает", обычно остаётся только устраивать сеанс спиритизма в три часа ночи, чтобы понять, ГДЕ этот чёртов косяк, из-за которого всё внезапно начало падать или почему остатки на счетах превратились в тыкву, и как это побыстрее исправить, ибо бизнес несёт убытки.
Это, конечно, не серебряная пуля и не избавляет от всех багов вообще, но за то, от чего избавляет — это не такая уж и высокая цена писать всё чуть более многословно. Тем более, разработчики языка постарались насколько это возможно многословность нивелировать синтаксическим сахаром.
Я бы даже добавил, что когда получается слишком раздутый код — в Rust это примета того, что "что-то пошло не так" и используется не лучшее архитектурное решение. Это особенно актуально для новичков, которые пытаются натягивать на Rust привычный стиль написания программ из других языков.
Это не переменные, это — биндинги. В большинстве случаев переменные не нужны. Поэтому и
let mut, чтобы ленивые люди предпочитали не использовать мутабельность там, где она не нужна.К слову, в Rust вплоне можно перекрывать старое значение с тем же именем:
let x = x + 1. Кроме того время жизни биндингов ограничено блоками, где они объявлены. И это тоже позволяет часто обходиться без мутабельности.Прошу прощения, здесь стоит уточнить: "если мы не ожидаем какое-то конкретное значение".
if x == Some(42)и более сложные — точно так же прекрасно работают.