Были, но я на них не нарывался. Насколько помню они в каких-то специфических случаях происходили (дедупликация, или что-то такое), иначе бы их автоматизированное тестирование ловило.
close() возвращает ошибку, насколько я вижу в основных имплементациях, только если данные не были синхронизированы на диск.
Раст в доках по ссылке выше пишет на этот счёт:
This can be used to handle errors that would otherwise only be caught when the File is closed, as dropping a File will ignore all errors. Note, however, that sync_all is generally more expensive than closing a file by dropping it, because the latter is not required to block until the data has been written to the filesystem.
Ман по close тоже пишет:
A careful programmer who wants to know about I/O errors may precede close() with a call to fsync(2)
Поэтому в большинстве случаев семантика вполне достаточна. Наверное есть какие-то кейсы в редких ОС, где семантика сисколлов иная - тогда такой подход возможно принесёт проблемы, но я пока не сталкивался.
Проекты на Расте без оптимизаций собираются у меня вполне быстро, я бы сказал сравнимо с Go, и уж гораздо быстрее чем всякие плюсы. Релизные бинари с оптимизациями, LTO и прочим собираются, может быть, минуту.
Докер, как и k8s, сам по себе не выполняет никакой особой нагруженной работы - он оркестрирует системное ПО как раз - ядро, cgroups, namespaces и т.п, которое написано не на Go.
Лично моя практика показывает что подход Раста удобнее чем боилерплейт Го. Я писал долго на обоих.
Случаев когда надо что-то закрыть "потом" в череде веков крайне мало - в основном это открыть, прочитать/записать байты, закрыть. Возможно у других иначе, но у меня вот так вот.
Поэтому RAII вместе с обработкой ошибок через ? делает код на Расте чище.
С другой стороны этот ? часто при рефкторинге можно случайно просто не увидеть, но компилятор подскажет :)
Были, но я на них не нарывался. Насколько помню они в каких-то специфических случаях происходили (дедупликация, или что-то такое), иначе бы их автоматизированное тестирование ловило.
Проблема не в кровавом энтерпрайзе, а в том что её пилит один чувак, и тот скандальный.
ZFS я использую уже лет 15 и данные ни разу не терял, а этой штуке пока доверять особых причин нет...
Возможно, я не утверждаю что моё видение единственно-правильное.
С моей точки зрения системное ПО критично к производительности и надёжности, в основном.
Да, но тут уж се-ля-ви...
close() возвращает ошибку, насколько я вижу в основных имплементациях, только если данные не были синхронизированы на диск.
Раст в доках по ссылке выше пишет на этот счёт:
Ман по close тоже пишет:
(c) https://man7.org/linux/man-pages/man2/close.2.html
Поэтому в большинстве случаев семантика вполне достаточна. Наверное есть какие-то кейсы в редких ОС, где семантика сисколлов иная - тогда такой подход возможно принесёт проблемы, но я пока не сталкивался.
Проекты на Расте без оптимизаций собираются у меня вполне быстро, я бы сказал сравнимо с Go, и уж гораздо быстрее чем всякие плюсы. Релизные бинари с оптимизациями, LTO и прочим собираются, может быть, минуту.
Не бенчмаркал, но дискомфорта вообще не вызывает.
DNS вполне себе раздаются внутри Router Advertisements - роутер же вам всё равно нужен (RFC)
NTP и прочее - да, уже нужен DHCP. Но, по факту, большинство клиентов всё это игнорирует и использует свои сервера времени.
Про сетевую загрузку - это вообще достаточно маргинальная ниша внутри ДЦ и подобного, так что наверное там DHCP вполне уместен.
Смотря в каком смысле. Системд - да, по большей части только оркестрирует (если не брать всякие резолверы и т.п.)
Нжинкс - нет, он обрабатывает запросы сам.
Считать нжинкс системным ПО? Думаю нет.
Как по мне - аппликуха.
Докер, как и k8s, сам по себе не выполняет никакой особой нагруженной работы - он оркестрирует системное ПО как раз - ядро, cgroups, namespaces и т.п, которое написано не на Go.
А у сокетов и page cache нет. Если оно улетело в TCP/IP стек, то там уже зависит от ядра. Гарантировать доставку всё равно не получится.
Кстати File.Close() в Го тоже судя по всему не делает fsync и отсутствие ошибок при закрытии не гарантирует запись.
Если нужно подтверждение, то делаем явный fsync ручками. После этого результат закрытия значения не имеет.
Это очередной неконтроллируемый закон, который не заставишь исполнять нормально.
Будут выборочно кого-то наказывать за сдохшие камеры и всё. В большинстве мест небось вообще муляжи повесят...
Свят-свят
Лично моя практика показывает что подход Раста удобнее чем боилерплейт Го. Я писал долго на обоих.
Случаев когда надо что-то закрыть "потом" в череде веков крайне мало - в основном это открыть, прочитать/записать байты, закрыть. Возможно у других иначе, но у меня вот так вот.
Поэтому RAII вместе с обработкой ошибок через ? делает код на Расте чище.
С другой стороны этот ? часто при рефкторинге можно случайно просто не увидеть, но компилятор подскажет :)
Ну Escape Analysis в Go есть же. Borrow Checker в Расте тоже как-то справляется с похожей задачей.
Просто нужно улучшать эти механизмы, я думаю. И тогда можно будет завести RAII даже в Го и облегчить жизнь сборщику мусора :)
Гм, вы почитайте значение термина что-ли. Системное программирование и микросервисы мешать в одну кучу?
Язык с ГЦ для системного программирования? Ну такое. СУБД если относить к СП то ещё как-то где-то наверное...
Это перевод
Камеры на выборах 2.0
Последняя ни разу не летала...
Плюсую, лютое зло, но иногда приходится пользоваться, хоть и редко, т.к. оплаты другим способом нет на некоторых сайтах.