Поздравляю, у вас отличный повод во всеуслышанье объявить вашего учителя географии лжецом. На бумаге РФ может присоединить хоть Луну, но к реальности это, к счастью, не имеет никакого отношения.
Если скорость света в вашем мире почтовых голубей составляет 12548 м/с, то так и будет. Допустим, ровер не просто так садится на Марс, а снабжен карманным телепортатором сверхновых, который активируется при посадке. От момента посадки ровера до уничтожения Земли от вспышки сверхновой пройдет полгода с т.з. ИСО, расположенной в центре бывшего Марса. С точки зрения ИСО на Земле, ее уничтожение и посадка ровера происходит одновременно. Как вы, наверное, заметили, с точки зрения Земли вообще все равно, полгода прошло или 11 минут, исход это не поменяет — одновременно с посадкой ровера Землю испаряет к чертям.
Не нашел нигде в посте упоминания о том, что задержки распространения сигнала не существует. Задержка существует, просто она не играет роли (хоть секунда, хоть миллиард лет) с точки зрения регистрации событий. События происходят ровно тогда, когда их световой конус нас достигает, и не важно на каком расстоянии от нас находится точка возникновения события. Типичное заблуждение, которому, судя по комментаторам этого поста, подвержено огромное количество людей, заключается в том, что событиям назначается некое глобальное время, поэтому ведутся рассуждения о том, что событие "на самом деле" произошло N секунд назад, хотя так говорить как минимум некорректно, и такие утверждения не соответствуют действительности, так как подразумевают передачу информации о возникновении события быстрее скорости света.
"Я не понимаю, как вы не понимаете".
UPD: Автор поста в целом высказывает достаточно очевидную мысль. Я искренне удивлен этим удивительным случаем массового помешательства со стороны комментаторов Хабра, которые чуть ли не с религиозным фанатизмом опровергают инвариантность скорости света в ИСО и фундаментальное ограничение на скорость передачи информации. Ведь это не может быть всерьез, так ведь?
Не понимаю, почему на автора поста все накинулись, как будто он глупость написал, если то, что он пишет, совершенно верно и очевидно любому.
Так как любая информация о любых событиях путешествует со скоростью распространения взаимодействия, до того момента, пока нас не настигнет волновой фронт этого события, самого события не существует. Если какое-то событие произойдет внутри горизонта событий черной дыры, информация о нем никогда нас не достигнет, поэтому это событие никогда не произошло с точки зрения вселенной снаружи, и состояние вселенной снаружи одинаково независимо от того, произошло ли событие внутри черной дыры или нет. Если какое-то событие произойдет за пределами горизонта событий расширяющейся вселенной, фронт одновременности никогда не достигнет горизонта событий снаружи, т.к. точка возникновения гипотетического события удаляется от нас быстрее скорости света, поэтому она будет асимптотически приближаться к горизонту событий видимой вселенной с той стороны, но никогда его не достигнет. Это значит, что событие для нас никогда не произойдет, т.к. до нас не дойдет никаких взаимодействий, которые говорили бы об обратном.
Если мы увидим, что Солнце взорвалось, это не значит, что это произошло "на самом деле 8 минут назад" по некоему универсальному вселенскому времени — нет, это произошло только что в системе отсчета, прицепленной к Земле, потому что фронт одновременности достиг Землю вместе со светом взрыва, ну и потому что универсального вселенского времени не существует. То, что свету требуется 8 минут, чтобы пролететь от Солнца от Земли, не играет тут ровным счетом никакой роли.
Именно так. В отличие от go, где err и value извлекаются из результата функции автоматически при ее вызове, и про err элементарно забыть, вы не сможете провернуть этот же фокус с Either. У Either есть только одно значение — это либо left-значение (ошибка), либо right-значение (результат), и вы не можете извлечь оба сразу. Вам нужно статически решить, что вы делаете, и обработать оба варианта, иначе ваша программа не соберется.
Ну или передать Either как есть в функцию, которая явно принимает аргументом конкретный типоэкземпляр Either.
Это отличается тем, что Either вы обязаны либо распаковать, либо передать в Either-aware функцию. Вы не можете просто передать Either<E, int> в функцию, которая хочет int, потому что ваше приложение просто не соберется. Вы не можете получить из Either одновременно и Left, и Right-значение, так как у Either есть только одно, и вам предстоит как раз узнать, какое. Почему именно так, видно на примере ошибки дизайнеров golang, которые распаковывают результаты функций в err и value автоматически, благодаря чему err можно смело игнорировать, а в value может быть мусор (и вы об этом не узнаете).
Но если ваша функция что-то выбрасывает, то вы можете передать ее результат куда угодно, и если функция при этом вылетит, вы рискуете ничего не словить, потому что вы не были в курсе, что вам что-то в принципе нужно ловить. А раз вы исключение не словите, то оно полезет вверх по стеку и в лучшем случае обрушит сервис, а в худшем будет словлено чем-то не тем, и приложение перейдет в неопределенное состояние.
Это хорошее поведение для незапланированных ситуаций (закончилась оперативка), и плохое для штатных ситуаций (мамкин хакир прислал нам обрезанный пакет).
Что касается ловли подклассов — вы можете в Left-части Either передавать экземпляры классов с произвольной иерархией и тестировать их каким-нибудь instanceof на принадлежность к базовому классу. То же касается приоритета и порядка.
Бросать исключения, чтобы срезать путь и тем самым нарушить инкапсуляцию, создав протекающий интерфейс, который может себя вести произвольным образом, считаю порочной практикой.
Если компонент в глубине коллстека не знает, что делать с ошибкой, то ошибка ли это? Почему компонент в глубине стека считает, что если пользователя нет в БД, то это ошибка, которую он обязан выбросить, а не просто вернуть пустой Maybe вызывающей стороне, и пусть уже бизнес-логика с этим разбирается?
Правильно написано, не надо доводить до исключений, потому что исключения — это для ситуаций, которые нельзя исправить и невозможно предусмотреть (OOM, повреждение стека, невозможное состояние конечного автомата, исполнение недоступного кода, невозможность прочитать обязательный файл и т.д.).
Если исключение является штатной ситуацией, то это значит лишь, что функция, которая его может выбросить, должна его на самом деле возвращать. Например, если функция валидирует инпут, и какие-то из комбинаций аргументов запрещены. Для того, чтобы удобно возвращать такие вещи, и отделять исключения от ошибок валидации, есть алгебраический тип Either, который может быть либо "нормальным значением" (Right), либо "значением-ошибкой" (Left).
Функции, которые могут возвращать такие ошибки валидации, должны возвращать Either, а вызывающая сторона должна всегда распаковывать Either и смотреть, была ли ошибка, и если была, то уведомлять об этом пользователя/отправлять 4хх-статус по HTTP/печатать матюки в лог и т.д., но не падать, т.к. было бы глупо падать от неправильного пользовательского инпута или от неправильно присланного пакета по сети.
А вот если нельзя открыть файл, или сменить директорию, или записать файл, или удалить файл, или выделить память под объект, или открыть сокет — то лучше упасть сразу же, согласно парадигме fail fast, чтобы потом, при разборе полетов, сразу увидеть причину, и чтобы некорректно работающая программа не успела наломать дров в чем-либо еще.
tl;dr — исключения нельзя исправлять и нежелательно ловить, т.к. программа, в которой возникло исключение, уже находится в неверном состоянии. Пусть они обрушат программу. Если исключения ожидаются, это value-объекты, которые должны возвращаться штатно через return.
Так а в чем функциональность описанного подхода? Хотелось бы увидеть реализацию какой-нибудь простой монады типа Maybe или List и пример того, как с ней удобно работать, чтобы в этом был смысл.
Нет, если пробросить сокет docker внутрь контейнера, это не даст docker-in-docker, потому что создаваемые контейнеры будут не child, а sibling. Чтобы контейнеры были вложенными, нужно сам dockerd запустить внутри контейнера, тогда сокет внутри будет свой собственный.
Все транзакции бткоина на самом деле состоят из таких "скриптов", т.к. ими задаются получатели. Плюс они могут использоваться для того, чтобы делать операции более сложные (множественные подписи, смарт-контракты, цепочки операций, отложенные платежи, платежи с ключом и т.д.), чем простое перечисление денег на указанный адрес, хоть, конечно, они и не настолько сложны и выразительны, как байткод Ethereum.
Прочитал про "позволяет приложению напрямую взаимодействовать с физическим диском, минуя файловую систему", закрались подозрения. Нашел оригинал:
Lykkegaard told BleepingComputer that he discovered the following Win32 device namespace path for the 'console multiplexer driver' that he believes is used for 'kernel / usermode ipc.'
Поздравляю, у вас отличный повод во всеуслышанье объявить вашего учителя географии лжецом. На бумаге РФ может присоединить хоть Луну, но к реальности это, к счастью, не имеет никакого отношения.
Только что буквально смотрел карту Украины — и Симферополь, и Севастополь на месте, никакой Россией не пахнет. Проверяйте факты что ли.
На месяц раньше запланированного статью опубликовали?
вы складываете "одновременно" в ИСО Земли и "одновременно" в ИСО Марса.
С т.з. Марса до момента получения Землей сообщения о посадке пройдет 11 минут. Еще 11 минут пройдет на Марсе прежде чем ровер получит поздравление.
С т.з. Земли посадка ровера и отправка поздравления происходят одновременно.
Если скорость света в вашем мире почтовых голубей составляет 12548 м/с, то так и будет. Допустим, ровер не просто так садится на Марс, а снабжен карманным телепортатором сверхновых, который активируется при посадке. От момента посадки ровера до уничтожения Земли от вспышки сверхновой пройдет полгода с т.з. ИСО, расположенной в центре бывшего Марса. С точки зрения ИСО на Земле, ее уничтожение и посадка ровера происходит одновременно. Как вы, наверное, заметили, с точки зрения Земли вообще все равно, полгода прошло или 11 минут, исход это не поменяет — одновременно с посадкой ровера Землю испаряет к чертям.
Не нашел нигде в посте упоминания о том, что задержки распространения сигнала не существует. Задержка существует, просто она не играет роли (хоть секунда, хоть миллиард лет) с точки зрения регистрации событий. События происходят ровно тогда, когда их световой конус нас достигает, и не важно на каком расстоянии от нас находится точка возникновения события. Типичное заблуждение, которому, судя по комментаторам этого поста, подвержено огромное количество людей, заключается в том, что событиям назначается некое глобальное время, поэтому ведутся рассуждения о том, что событие "на самом деле" произошло N секунд назад, хотя так говорить как минимум некорректно, и такие утверждения не соответствуют действительности, так как подразумевают передачу информации о возникновении события быстрее скорости света.
"Я не понимаю, как вы не понимаете".
UPD: Автор поста в целом высказывает достаточно очевидную мысль. Я искренне удивлен этим удивительным случаем массового помешательства со стороны комментаторов Хабра, которые чуть ли не с религиозным фанатизмом опровергают инвариантность скорости света в ИСО и фундаментальное ограничение на скорость передачи информации. Ведь это не может быть всерьез, так ведь?
Не понимаю, почему на автора поста все накинулись, как будто он глупость написал, если то, что он пишет, совершенно верно и очевидно любому.
Так как любая информация о любых событиях путешествует со скоростью распространения взаимодействия, до того момента, пока нас не настигнет волновой фронт этого события, самого события не существует. Если какое-то событие произойдет внутри горизонта событий черной дыры, информация о нем никогда нас не достигнет, поэтому это событие никогда не произошло с точки зрения вселенной снаружи, и состояние вселенной снаружи одинаково независимо от того, произошло ли событие внутри черной дыры или нет. Если какое-то событие произойдет за пределами горизонта событий расширяющейся вселенной, фронт одновременности никогда не достигнет горизонта событий снаружи, т.к. точка возникновения гипотетического события удаляется от нас быстрее скорости света, поэтому она будет асимптотически приближаться к горизонту событий видимой вселенной с той стороны, но никогда его не достигнет. Это значит, что событие для нас никогда не произойдет, т.к. до нас не дойдет никаких взаимодействий, которые говорили бы об обратном.
Если мы увидим, что Солнце взорвалось, это не значит, что это произошло "на самом деле 8 минут назад" по некоему универсальному вселенскому времени — нет, это произошло только что в системе отсчета, прицепленной к Земле, потому что фронт одновременности достиг Землю вместе со светом взрыва, ну и потому что универсального вселенского времени не существует. То, что свету требуется 8 минут, чтобы пролететь от Солнца от Земли, не играет тут ровным счетом никакой роли.
Могли видеть публичный ключ, на который отправляли деньги скрытые майнерские ноды, за которые его и арестовали.
В
а украинский Симферополь в этом списке как оказался?
Именно так. В отличие от go, где err и value извлекаются из результата функции автоматически при ее вызове, и про err элементарно забыть, вы не сможете провернуть этот же фокус с Either. У Either есть только одно значение — это либо left-значение (ошибка), либо right-значение (результат), и вы не можете извлечь оба сразу. Вам нужно статически решить, что вы делаете, и обработать оба варианта, иначе ваша программа не соберется.
Ну или передать Either как есть в функцию, которая явно принимает аргументом конкретный типоэкземпляр Either.
Это отличается тем, что
Eitherвы обязаны либо распаковать, либо передать вEither-aware функцию. Вы не можете просто передатьEither<E, int>в функцию, которая хочетint, потому что ваше приложение просто не соберется. Вы не можете получить изEitherодновременно иLeft, иRight-значение, так как уEitherесть только одно, и вам предстоит как раз узнать, какое. Почему именно так, видно на примере ошибки дизайнеров golang, которые распаковывают результаты функций вerrиvalueавтоматически, благодаря чемуerrможно смело игнорировать, а вvalueможет быть мусор (и вы об этом не узнаете).Но если ваша функция что-то выбрасывает, то вы можете передать ее результат куда угодно, и если функция при этом вылетит, вы рискуете ничего не словить, потому что вы не были в курсе, что вам что-то в принципе нужно ловить. А раз вы исключение не словите, то оно полезет вверх по стеку и в лучшем случае обрушит сервис, а в худшем будет словлено чем-то не тем, и приложение перейдет в неопределенное состояние.
Это хорошее поведение для незапланированных ситуаций (закончилась оперативка), и плохое для штатных ситуаций (мамкин хакир прислал нам обрезанный пакет).
Что касается ловли подклассов — вы можете в Left-части Either передавать экземпляры классов с произвольной иерархией и тестировать их каким-нибудь instanceof на принадлежность к базовому классу. То же касается приоритета и порядка.
Бросать исключения, чтобы срезать путь и тем самым нарушить инкапсуляцию, создав протекающий интерфейс, который может себя вести произвольным образом, считаю порочной практикой.
Если компонент в глубине коллстека не знает, что делать с ошибкой, то ошибка ли это? Почему компонент в глубине стека считает, что если пользователя нет в БД, то это ошибка, которую он обязан выбросить, а не просто вернуть пустой Maybe вызывающей стороне, и пусть уже бизнес-логика с этим разбирается?
Правильно написано, не надо доводить до исключений, потому что исключения — это для ситуаций, которые нельзя исправить и невозможно предусмотреть (OOM, повреждение стека, невозможное состояние конечного автомата, исполнение недоступного кода, невозможность прочитать обязательный файл и т.д.).
Если исключение является штатной ситуацией, то это значит лишь, что функция, которая его может выбросить, должна его на самом деле возвращать. Например, если функция валидирует инпут, и какие-то из комбинаций аргументов запрещены. Для того, чтобы удобно возвращать такие вещи, и отделять исключения от ошибок валидации, есть алгебраический тип Either, который может быть либо "нормальным значением" (Right), либо "значением-ошибкой" (Left).
Функции, которые могут возвращать такие ошибки валидации, должны возвращать Either, а вызывающая сторона должна всегда распаковывать Either и смотреть, была ли ошибка, и если была, то уведомлять об этом пользователя/отправлять 4хх-статус по HTTP/печатать матюки в лог и т.д., но не падать, т.к. было бы глупо падать от неправильного пользовательского инпута или от неправильно присланного пакета по сети.
А вот если нельзя открыть файл, или сменить директорию, или записать файл, или удалить файл, или выделить память под объект, или открыть сокет — то лучше упасть сразу же, согласно парадигме fail fast, чтобы потом, при разборе полетов, сразу увидеть причину, и чтобы некорректно работающая программа не успела наломать дров в чем-либо еще.
tl;dr — исключения нельзя исправлять и нежелательно ловить, т.к. программа, в которой возникло исключение, уже находится в неверном состоянии. Пусть они обрушат программу. Если исключения ожидаются, это value-объекты, которые должны возвращаться штатно через return.
Так а в чем функциональность описанного подхода? Хотелось бы увидеть реализацию какой-нибудь простой монады типа Maybe или List и пример того, как с ней удобно работать, чтобы в этом был смысл.
Нет, если пробросить сокет docker внутрь контейнера, это не даст docker-in-docker, потому что создаваемые контейнеры будут не child, а sibling. Чтобы контейнеры были вложенными, нужно сам dockerd запустить внутри контейнера, тогда сокет внутри будет свой собственный.
Да.
Все транзакции бткоина на самом деле состоят из таких "скриптов", т.к. ими задаются получатели. Плюс они могут использоваться для того, чтобы делать операции более сложные (множественные подписи, смарт-контракты, цепочки операций, отложенные платежи, платежи с ключом и т.д.), чем простое перечисление денег на указанный адрес, хоть, конечно, они и не настолько сложны и выразительны, как байткод Ethereum.
https://en.bitcoin.it/wiki/Script
Прочитал про "позволяет приложению напрямую взаимодействовать с физическим диском, минуя файловую систему", закрались подозрения. Нашел оригинал:
Что это за дремучая отсебятина?
Я, похоже, пропустил математическое доказательство, о котором вы пишете. Поделитесь ссылкой?
NSA считает, что есть, и использует эти более лучшие алгоритмы для шифровки государственной переписки.