Кстати, а у рекрутёров нет возможности включить сопроводительный текст вместе с предложением дружбы, или они ею не пользуются? Мне уже 3 запроса пришло, но вот кто все эти люди и зачем я им нужен — непонятно на данный момент.
А я правильно понимаю, что в этом режиме Go работает без GC и нельзя использовать ничего, что вызвало бы выделение памяти в куче? Или GC включается в образ ядра как часть среды исполнения? Хотя тогда, конечно, интересно, как он без виртуальной памяти будет работать.
Я бы не упоминал этот пример. Добраться-то до него добрались, но если посмотреть на код победителя (C++), то мы опять сравниваем людоеда с бегемотом: в Rust намного больше кода и там реализована своя хэш-таблица (зачем? уж не знаю).
На самом деле, это не эквивалентно, потому что во всех функциях бросаемые ошибки на самом деле могут быть разные. Тогда `f` возвращает только `ErrorF`, `e` — `ErrorF | ErrorE`, и так далее. Придётся объявить кучу типов, и они ещё и сочетаться друг с другом не будут.
Действительно неудобно.
Другое дело, что такой код на Rust вряд ли кто-то станет писать.
Если на уровне объявления на функцию вешается атрибут типа `#![throws]`, то он же заражает все функции, вызывающие данную. Так, если у вас хотя бы одна функция в самой глубине графа вызовов бросает, то заражается по сути весь граф. Полезность аннотации и «опциональности» теряется.
Это так не только синтаксически — как только кто-то где-то бросает исключение, все, кто вызывает бросающего, должны иметь площадки для приземления чтобы вызывать `finally` и, если надо, `catch`.
То есть я понимаю, что в софте для каких-нибудь самолетов или АЭС это выполнено, но для какого-нибудь более приземленного программирования вроде какой-нибудь змейки или тетриса обычно этого не делают.
Ну делайте везде `.unwrap()`, можете это делать в реализации, тогда в интерфейсе вообще будет возврат чистого значения T (а не Result<T, String>, например).
Rust предполагает либо явную обработку возвращаемых значений, либо перехват паники на границе потока — можно потенциально ломающееся вычисление сделать в отдельном потоке, и узнать, завалился ли он, в родителе: doc.rust-lang.org/stable/std/thread/struct.JoinHandle.html#method.join
Да, исключения удобно бросать-ловить — как раз потому, что они в интерфейсе никак не декларируются. И как раз поэтому они создают трудности в больших проектах или там, где критична надёжность. Вот в Java, насколько я знаю, можно объявить, какие исключения может бросить метод.
Думаю, ничего особо нового мы тут не выведем. Да, решение Rust — это компромисс. Как и большинство решений в принципе — мало у чего нет минусов. Я думаю, что в цели Rust этот компромисс вписывается хорошо (хотя вы вольны не согласиться).
Жесть какая-то, по-моему.
> мои друзья
Хотелось бы как в LinkedIn хотя бы.
Что такое «event loop» и чем это отличается от веб-сервера? От веб-фреймворка?
А я правильно понимаю, что в этом режиме Go работает без GC и нельзя использовать ничего, что вызвало бы выделение памяти в куче? Или GC включается в образ ядра как часть среды исполнения? Хотя тогда, конечно, интересно, как он без виртуальной памяти будет работать.
Если человек не хочет обрабатывать ошибки, он способ найдёт :)
На самом деле, это не эквивалентно, потому что во всех функциях бросаемые ошибки на самом деле могут быть разные. Тогда `f` возвращает только `ErrorF`, `e` — `ErrorF | ErrorE`, и так далее. Придётся объявить кучу типов, и они ещё и сочетаться друг с другом не будут.
Действительно неудобно.
Другое дело, что такой код на Rust вряд ли кто-то станет писать.
Если на уровне объявления на функцию вешается атрибут типа `#![throws]`, то он же заражает все функции, вызывающие данную. Так, если у вас хотя бы одна функция в самой глубине графа вызовов бросает, то заражается по сути весь граф. Полезность аннотации и «опциональности» теряется.
Это так не только синтаксически — как только кто-то где-то бросает исключение, все, кто вызывает бросающего, должны иметь площадки для приземления чтобы вызывать `finally` и, если надо, `catch`.
Ну делайте везде `.unwrap()`, можете это делать в реализации, тогда в интерфейсе вообще будет возврат чистого значения T (а не Result<T, String>, например).
Rust предполагает либо явную обработку возвращаемых значений, либо перехват паники на границе потока — можно потенциально ломающееся вычисление сделать в отдельном потоке, и узнать, завалился ли он, в родителе: doc.rust-lang.org/stable/std/thread/struct.JoinHandle.html#method.join
Ещё можно запустить замыкание в том же потоке с поимкой паники ( doc.rust-lang.org/stable/std/thread/fn.catch_panic.html ), но это сейчас нестабильно — идёт обсуждение того, как это влияет на безопасность ( github.com/rust-lang/rust/issues/25662 )
Да, исключения удобно бросать-ловить — как раз потому, что они в интерфейсе никак не декларируются. И как раз поэтому они создают трудности в больших проектах или там, где критична надёжность. Вот в Java, насколько я знаю, можно объявить, какие исключения может бросить метод.
Думаю, ничего особо нового мы тут не выведем. Да, решение Rust — это компромисс. Как и большинство решений в принципе — мало у чего нет минусов. Я думаю, что в цели Rust этот компромисс вписывается хорошо (хотя вы вольны не согласиться).