На Rust нельзя описать нормально многие структуры. Нужны либо unsafe, либо проверки в рантайме. Borrow checker ограничен в том, безопасность чего он может доказать. Довольно большой класс безопасных структур он не пропустит, из-за чего в том же Rust много библиотечных классов реализовано на unsafe.
Вы необходимо столкнетесь с чем-то подобным, буду ждать следующих статей как вы это решили.
Тот же full scan нормален на 1 мегабайте, не ОК на допустим 10 Тб. Но где граница, и как сделать так чтобы самый важный запрос не упал, когда самая главная таблица вдруг превысила этот порог на один байт?
Разные No/NewSQL базы тоже стабильные точечные запросы обеспечивают. А вот произвольный SQL не могут, и не видно как это было бы возможно.
В чем-то сходно с Rust, какие-то ограниченные структуры владения объектами можно описать и он гарантирует безопасность. А вот произвольный связи как в плюсах не сделать.
Выбор, и там и там, между универсальностью и гарантиями. В общем для обоих есть применения, но универсальность нужна чаще конечно.
Одно отличие я заметил, в С++ объект освобождается по выходу из области видимости, а тут иногда раньше, по месту "последнего" использования. Это память в каких-то случаях экономит, но редко. Зато ломает RAII паттерн.
Но разница как-то явно не достаточная чтобы избежать нормального borrow checker. А что компилятор делает если этот указатель передается в другие функции из статьи совсем не ясно.
Я бы даже сказал, что возможно стоит это позиционировать как механизм макросов, на уровне AST, может быть интересным, хотя видны и проблемы. Но это не про исключения.
А какой нибудь практический пример использования таких исключений есть? Не очень понятно, что в примере с делением на ноль можно написать внутри if (op == 0), кроме terminate(), а это не совсем то что обычно понимают под обработкой исключений. Ну может быть альтернативно установить какой-нибудь глобальный флаг ошибки, вернуть какую-нибудь ерунду, и продолжить вычисления? Тоже так себе идея. Да и сделать оба варианта можно эффективнее без лишних if через системные исключения.
Есть дата, когда запись появляется в базе (со всеми оговорками, что могут быть разные задержки, но идея понятна). Думаю что здесь это как раз sold_at, если другая - то надо использовать ее. Обычно по этому же полю происходит чистка базы.
И для этого поля PARTITION BY естественное решение, решающее сразу множество проблем. Для остальных полей очевидно индексы.
В некоторых базах данных, кстати, PARTITION BY по дате заказа ускорит запросы и по дате поставки, они сильно коррелируют. Но, увы, это пока не про Postgres.
С ежедневными отчётами, почему борьба за индекс, а не PARTITION BY? Казалось бы, как раз для таких случаев, исключает лишнее сканирование, и решает проблемы с вакуумом и пр.
Именно поэтому режим разморозки работает импульсами: магнетрон включается и выключается
Не, все импульсные режимы в микроволновке только потому что конкретная микроволновка не умеет плавно регулировать мощность магнетрона. Сначала это не умели, потом как это делать открыл и запатентовал Панасоник, а остальные не хотели ему платить. Уже несколько лет как патент истёк, но дизайн все меняют медленно, большинство до сих пор не умеют. Если глянуть на те же Панасоники, там разморозка давно не импульсная, а на малой мощности.
Может послать в Бразилию все свои ненужные зарядные устройства? Всё равно не используются, пользуюсь либо USB прямо в розетке, либо большими зарядниками с 4-5 USB выходами. На отдельные зарядники розеток не хватит. Когда очередной прибор приходит с проводом вместо зарядника, только радуюсь.
Это все же разные вещи, иногда помогать решать возникшие проблемы, и постоянный safety driver в Тесле. Хотя и Тесла конечно движется к автономии, пара десятков машин уже ездят без safety driver (а вместо филиппинца на случай проблем - вторая Тесла с водителем, следующая за "автономной"), но большинство с водителем.
Думаю через год - другой будет сравнимо статистики, чтобы сравнить с WayMo. Пока клеветники вроде Electrek считают, что у Теслы аварий на милю больше чем у людей.
В большинстве городов приглашения давно не нужны, а в паре WayMo интегрированы с Убером, опять же может вызвать кто угодно (можно выставить предпочтения, хотите ли вы AV). Приглашения нужны короткое время в новых местах на время тестирования.
На Rust нельзя описать нормально многие структуры. Нужны либо unsafe, либо проверки в рантайме. Borrow checker ограничен в том, безопасность чего он может доказать. Довольно большой класс безопасных структур он не пропустит, из-за чего в том же Rust много библиотечных классов реализовано на unsafe.
Вы необходимо столкнетесь с чем-то подобным, буду ждать следующих статей как вы это решили.
Тот же full scan нормален на 1 мегабайте, не ОК на допустим 10 Тб. Но где граница, и как сделать так чтобы самый важный запрос не упал, когда самая главная таблица вдруг превысила этот порог на один байт?
Разные No/NewSQL базы тоже стабильные точечные запросы обеспечивают. А вот произвольный SQL не могут, и не видно как это было бы возможно.
В чем-то сходно с Rust, какие-то ограниченные структуры владения объектами можно описать и он гарантирует безопасность. А вот произвольный связи как в плюсах не сделать.
Выбор, и там и там, между универсальностью и гарантиями. В общем для обоих есть применения, но универсальность нужна чаще конечно.
Выше это и не утверждалось, лишь что небольшая смена семантики не позволит избежать borrow checker'а (при декларируемой memory safety).
Одно отличие я заметил, в С++ объект освобождается по выходу из области видимости, а тут иногда раньше, по месту "последнего" использования. Это память в каких-то случаях экономит, но редко. Зато ломает RAII паттерн.
Но разница как-то явно не достаточная чтобы избежать нормального borrow checker. А что компилятор делает если этот указатель передается в другие функции из статьи совсем не ясно.
Я бы даже сказал, что возможно стоит это позиционировать как механизм макросов, на уровне AST, может быть интересным, хотя видны и проблемы. Но это не про исключения.
А какой нибудь практический пример использования таких исключений есть? Не очень понятно, что в примере с делением на ноль можно написать внутри
if (op == 0), кромеterminate(), а это не совсем то что обычно понимают под обработкой исключений. Ну может быть альтернативно установить какой-нибудь глобальный флаг ошибки, вернуть какую-нибудь ерунду, и продолжить вычисления? Тоже так себе идея. Да и сделать оба варианта можно эффективнее без лишнихifчерез системные исключения.Тогда я только хочу пожелать удачи вашим аналитикам в построении отчетов. Медленные индексы наверное наименьшие из их проблем.
Есть дата, когда запись появляется в базе (со всеми оговорками, что могут быть разные задержки, но идея понятна). Думаю что здесь это как раз sold_at, если другая - то надо использовать ее. Обычно по этому же полю происходит чистка базы.
И для этого поля PARTITION BY естественное решение, решающее сразу множество проблем. Для остальных полей очевидно индексы.
В некоторых базах данных, кстати, PARTITION BY по дате заказа ускорит запросы и по дате поставки, они сильно коррелируют. Но, увы, это пока не про Postgres.
Какие лимиты, только три дня назад была новость что продать удалось ровно ноль (0) карт.
https://habr.com/ru/news/1005268/
Все таки в таблице sales поле sold_at одно и весьма специальное. С остальными да.
С ежедневными отчётами, почему борьба за индекс, а не PARTITION BY? Казалось бы, как раз для таких случаев, исключает лишнее сканирование, и решает проблемы с вакуумом и пр.
А то что должна быть возможность отвязать карту там прописано? А то видал сервисы, где последнюю карту не удалить.
Не, все импульсные режимы в микроволновке только потому что конкретная микроволновка не умеет плавно регулировать мощность магнетрона. Сначала это не умели, потом как это делать открыл и запатентовал Панасоник, а остальные не хотели ему платить. Уже несколько лет как патент истёк, но дизайн все меняют медленно, большинство до сих пор не умеют. Если глянуть на те же Панасоники, там разморозка давно не импульсная, а на малой мощности.
А в топ Hackers News вошла страничка OpenAI – How to delete your account.
На русском наверное не "поддержку загрузки ReFS", а "поддержку загрузки с ReFS". Мы загружаем Виндоус, а не ReFS.
Мы не про абстрактные машины Waymo и Robotaxi, а те которые предлагаются пассажирам через сервис. Там у WayMo водителей давно нет.
В смерти собаки в 23ем (во время тестирования) safety driver'а WayMo не винили, а в 25ом (уже во время работы сервиса) его уже и не было.
Может послать в Бразилию все свои ненужные зарядные устройства? Всё равно не используются, пользуюсь либо USB прямо в розетке, либо большими зарядниками с 4-5 USB выходами. На отдельные зарядники розеток не хватит. Когда очередной прибор приходит с проводом вместо зарядника, только радуюсь.
Лучше бы с розетками у себя разобрались, до сих пор где 127, где 220 вольт.
Это все же разные вещи, иногда помогать решать возникшие проблемы, и постоянный safety driver в Тесле. Хотя и Тесла конечно движется к автономии, пара десятков машин уже ездят без safety driver (а вместо филиппинца на случай проблем - вторая Тесла с водителем, следующая за "автономной"), но большинство с водителем.
Думаю через год - другой будет сравнимо статистики, чтобы сравнить с WayMo. Пока клеветники вроде Electrek считают, что у Теслы аварий на милю больше чем у людей.
В большинстве городов приглашения давно не нужны, а в паре WayMo интегрированы с Убером, опять же может вызвать кто угодно (можно выставить предпочтения, хотите ли вы AV). Приглашения нужны короткое время в новых местах на время тестирования.