рантайм любого целевого языка как правило пишется на языке более низкого уровня, менее безопасном
Всё верно: unsafe Rust — язык более низкого уровня, менее безопасный чем safe Rust
Все гарантии безопасности языка распространяются на программы написанные на этом языке
Всё верно: гарантии безопасности safe Rust распространяются только на safe Rust, при этом внутренняя реализация рантайма на unsafe Rust не играет никакой роли
любая успешно скомпилированная программа на этом языке может упасть только при
...любой случайной вашей опечатке в unsafe-коде runtime.c
и это само по себе не делает целевой язык менее safe
То есть вы признаёте свою неправоту и отказываетесь от пункта 4 своего изначального комментария
char chars[1]; // variable size zero terminated utf8
Здесь не только нет никаких гарантий безопасности (нет, комментарий «zero terminated» не является такой гарантией), но и вообще большие подозрения на неопределённое поведение. Вы проводите странные манипуляции со структурой, выделяя больше памяти чем размер структуры и обращаясь за пределы структуры, чтобы записать целую строку в массив размером один элемент — жутко страшный код.
Кроме того, вы вручную подсчитываете количество выделяемой памяти и столь же вручную пишете нулевой байт в s->chars[size] — ничего из этого язык C не проверяет, все эти операции являются unsafe и работают только благодаря вашей собственной аккуратности, а не каким-то там гарантиям.
Почти каждая строчка в runtime.c — это потенциальный выстрел в ногу, о каких вообще гарантиях может идти речь?
И снова ложь. Во-первых, паники не убивают приложение, их можно перехватить и обработать (хотя скорее всего не нужно). Во-вторых, здесь добавляется ваша ложь из пункта 5: вас никто не заставляет вызывать заведомо паникующие методы, вы вполне можете использовать try_borrow/try_borrow_mut
не позволяют создавать иерархии (графы) объектов
Обратите внимание, что это совершенно не то, что вы изначально написали в пункте 2, то есть вы сейчас подменили тезис
Получается, что язык не совсем safe?
Никакой язык не может быть полностью safe даже в теории. Аргентум тоже оказался unsafe, и, что гораздо хуже — Аргентум, будучи написанным на C/C++, не контролирует своё собственное использование unsafe. Rust лучше уже хотя бы в том плане, что он пытается изолировать unsafe-код в unsafe-блоках
Если простое выражение на языке успешно компилируется, а при исполнении с некоторой пероятностью падает - это не нормально. Вы не находите?
Если вы целенаправленно используете функции, в документации которых написано, что они предназначены для того чтобы падать, то падение это абсолютно нормально и является не проблемой, а ожидаемым поведением программы. Придумайте более адекватный пример (я знаю, что его можно придумать, но раз именно вы тут любите хейтить Rust, то вы и придумайте, я не буду)
Option<Rc<RefCell<dyn Any>>>
Давайте с самого начала — зачем такое значение в принципе существует? С некоторой вероятностью это может оказаться криворукостью написавшего это программиста — а рассматривать заведомый говнокод я не вижу смысла (говнокод можно написать на любом языке)
Классическая Maybe-monad в Расте == Option
А здесь подмена понятий с вашей стороны, потому что Option не является указателем и даже не обязан хранить в себе указатель
Домашнее задание для читателей — посчитать, сколько правил демагога использовал kotan-11 в своих комментариях
Загоревшись интересом, как такие чудеса в принципе возможны, я заглянул в исходники на гитхабе, а там стандартная библиотека написана на C — то есть она вся автоматически unsafe
За конкретным примером даже далеко ходить не пришлось, можно взять сразу хелловорлд — стандартная функция logне стесняясь напрямую вызывает fputs, вызов которой конечно же является unsafe: вызывающий её программист обязан самостоятельно проконтролировать, что строка s->chars является null-terminated и что её чтение не приведёт к чтению за пределами выделенной памяти
И если один пункт рекламы оказался ложным — возможно, и в других пунктах стоит засомневаться?
гарантий целостности для структур, размещённых в хипе
О чём конкретно речь?
Управление объектами в хипе основано на умных указателях с подсчётом ссылок
Ложь, контейнеры вроде Box<T> и Vec<T> не имеют подсчёта ссылок
Все приложения на Rust прямо или косвенно импользуют unsafe, теряя безопасность памяти и защиту от data races.
Вы не поняли суть Rust
Паники часто возникают
Ложь, в приведённом вами выражении вы сами целенаправленно вызываете панику, они не возникают сами по себе
(кстати, как вам такой синтаксис простого приведения типов?)
Никак, потому что вы не дали никакой информации о том, что такое result и зачем вы всю эту чушь вообще написали
maybe-null-указателю
У указателей не существует метода and_then, так что где-то тут вы опять лжёте
Вот пример того же кода на языке Аргентум
А, так это просто бездарная реклама от человека, который даже не потрудился изучить основы Rust, чего я тут распинаюсь вообще... Просто держите минус тогда
У меня получается странное: с маленьким bantime он как будто бесполезен, а с большим bantime сам fail2ban начинает грузить систему своими банами — вплоть до того, что у меня однажды ufw сдох (наверно мне пора прекращать использовать ufw)
Так а зачем здесь PHP? Отдать статическую html-страничку со столь же статическим js-кодом можно абсолютно любым веб-сервером или даже тупо на github.io закинуть
Синхронный интерфейс взаимодействия — обрабатывает запросы один за другим.
Из первого не следует второе — к WSGI вполне прикручивают потоки или гринлеты (о чём вы сами же потом пишете ниже)
Не поддерживает ... SSE (Server-Sent Events)
SSE — это всего лишь один из вариантов streaming response, который прекрасно делается через WSGI (другое дело, что он будет занимать собой воркер, поэтому делать так обычно не очень разумно)
Синхронный и асинхронный интерфейс взаимодействия — может обрабатывать множество запросов одновременно.
Из первого не следует второе — стандартный event loop в питоне принципиально однопоточный, поэтому, если не обмазываться костылями вроде воркеров или стороннего пула потоков, запросы будут обрабатываться конкурентно, но не одновременно
может применяться в Django (через Channels)
Django уже давно поддерживает ASGI нативно без Channels (единственный мой пост как раз об этом)
Работает по схеме prefork (несколько процессов-воркеров).
То есть для uWSGI вы гринлеты упомянули, а gunicorn, у которого буквально слово green в названии, почему-то решили обидеть
сторонние классы воркеров (gevent/eventlet)
Они не сторонние
Производительность: несколько лучше, чем у Gunicorn в бенчмарках
А вот этот бенчмарк говорит, что uWSGI самый медленный (впрочем, насколько можно верить бенчмарку девятилетней давности, не знаю — но мне до сих пор интересно, что не так с этим бенчмарком)
В них всех тоже есть GC, так что шило на мыло. Бывали истории о переходе с Go на Rust из-за тормозов
Всё верно: unsafe Rust — язык более низкого уровня, менее безопасный чем safe Rust
Всё верно: гарантии безопасности safe Rust распространяются только на safe Rust, при этом внутренняя реализация рантайма на unsafe Rust не играет никакой роли
...любой случайной вашей опечатке в unsafe-коде
runtime.cТо есть вы признаёте свою неправоту и отказываетесь от пункта 4 своего изначального комментария
И снова ложь. Открываем объявление структуры AgString:
Здесь не только нет никаких гарантий безопасности (нет, комментарий «zero terminated» не является такой гарантией), но и вообще большие подозрения на неопределённое поведение. Вы проводите странные манипуляции со структурой, выделяя больше памяти чем размер структуры и обращаясь за пределы структуры, чтобы записать целую строку в массив размером один элемент — жутко страшный код.
Кроме того, вы вручную подсчитываете количество выделяемой памяти и столь же вручную пишете нулевой байт в
s->chars[size]— ничего из этого язык C не проверяет, все эти операции являются unsafe и работают только благодаря вашей собственной аккуратности, а не каким-то там гарантиям.Почти каждая строчка в
runtime.c— это потенциальный выстрел в ногу, о каких вообще гарантиях может идти речь?И снова ложь. Во-первых, паники не убивают приложение, их можно перехватить и обработать (хотя скорее всего не нужно). Во-вторых, здесь добавляется ваша ложь из пункта 5: вас никто не заставляет вызывать заведомо паникующие методы, вы вполне можете использовать try_borrow/try_borrow_mut
Обратите внимание, что это совершенно не то, что вы изначально написали в пункте 2, то есть вы сейчас подменили тезис
Никакой язык не может быть полностью safe даже в теории. Аргентум тоже оказался unsafe, и, что гораздо хуже — Аргентум, будучи написанным на C/C++, не контролирует своё собственное использование unsafe. Rust лучше уже хотя бы в том плане, что он пытается изолировать unsafe-код в unsafe-блоках
Если вы целенаправленно используете функции, в документации которых написано, что они предназначены для того чтобы падать, то падение это абсолютно нормально и является не проблемой, а ожидаемым поведением программы. Придумайте более адекватный пример (я знаю, что его можно придумать, но раз именно вы тут любите хейтить Rust, то вы и придумайте, я не буду)
Давайте с самого начала — зачем такое значение в принципе существует? С некоторой вероятностью это может оказаться криворукостью написавшего это программиста — а рассматривать заведомый говнокод я не вижу смысла (говнокод можно написать на любом языке)
А здесь подмена понятий с вашей стороны, потому что Option не является указателем и даже не обязан хранить в себе указатель
Домашнее задание для читателей — посчитать, сколько правил демагога использовал kotan-11 в своих комментариях
Ну и раз уж речь зашла про Аргентум:
Загоревшись интересом, как такие чудеса в принципе возможны, я заглянул в исходники на гитхабе, а там стандартная библиотека написана на C — то есть она вся автоматически unsafe
За конкретным примером даже далеко ходить не пришлось, можно взять сразу хелловорлд — стандартная функция
logне стесняясь напрямую вызывает fputs, вызов которой конечно же является unsafe: вызывающий её программист обязан самостоятельно проконтролировать, что строкаs->charsявляется null-terminated и что её чтение не приведёт к чтению за пределами выделенной памятиИ если один пункт рекламы оказался ложным — возможно, и в других пунктах стоит засомневаться?
О чём конкретно речь?
Ложь, контейнеры вроде
Box<T>иVec<T>не имеют подсчёта ссылокВы не поняли суть Rust
Ложь, в приведённом вами выражении вы сами целенаправленно вызываете панику, они не возникают сами по себе
Никак, потому что вы не дали никакой информации о том, что такое
resultи зачем вы всю эту чушь вообще написалиУ указателей не существует метода
and_then, так что где-то тут вы опять лжётеА, так это просто бездарная реклама от человека, который даже не потрудился изучить основы Rust, чего я тут распинаюсь вообще... Просто держите минус тогда
У меня получается странное: с маленьким bantime он как будто бесполезен, а с большим bantime сам fail2ban начинает грузить систему своими банами — вплоть до того, что у меня однажды ufw сдох (наверно мне пора прекращать использовать ufw)
Насколько я знаю, браузеры не обрабатывают 429
И отпугиваем всех обычных пользователей, которые случайно даблкликнули ссылку или решили открыть много вкладок за раз для последующего чтения
Мне, поддерживающему несколько легаси-проектов, очень любопытно — а с Python 2.7? 🙃
Разумеется, ничего не мешает подгружать данные через тот же
requestsточно так же, как это делает JavaScript, без всяких селениумов и плейврайтовТак а зачем здесь PHP? Отдать статическую html-страничку со столь же статическим js-кодом можно абсолютно любым веб-сервером или даже тупо на github.io закинуть
Вам никто не запрещает открывать сцены через панельку FileSystem, наверное? Пока что продолжаю не понимать в чём неудобство
Оно раньше и было по умолчанию, но из-за большого количества жалоб на неожиданное поведение специально отключили
1. А как должно быть удобно?
2. Откроется, если вы поставите галочку Editor Settings → Text Editor → Behavior → Open Dominant Script on Scene Change
3. Я не очень понял в чём проблема, но в любом случае см. п. 2
5. Просто закрыть
Файл debian.cnf создаётся пакетом mysql-server (или пакетом mysql-server-8.0 в более старых убунтах)
Я ожидал эту ссылку, поэтому специально не стал писать «не стало проблемой» — но драйвера-то по-прежнему открытые
Почему для AMD и Intel это не стало настолько непреодолимой проблемой?
Из первого не следует второе — к WSGI вполне прикручивают потоки или гринлеты (о чём вы сами же потом пишете ниже)
SSE — это всего лишь один из вариантов streaming response, который прекрасно делается через WSGI (другое дело, что он будет занимать собой воркер, поэтому делать так обычно не очень разумно)
Из первого не следует второе — стандартный event loop в питоне принципиально однопоточный, поэтому, если не обмазываться костылями вроде воркеров или стороннего пула потоков, запросы будут обрабатываться конкурентно, но не одновременно
Django уже давно поддерживает ASGI нативно без Channels (единственный мой пост как раз об этом)
То есть для uWSGI вы гринлеты упомянули, а gunicorn, у которого буквально слово green в названии, почему-то решили обидеть
Они не сторонние
А вот этот бенчмарк говорит, что uWSGI самый медленный (впрочем, насколько можно верить бенчмарку девятилетней давности, не знаю — но мне до сих пор интересно, что не так с этим бенчмарком)
К вам это тоже относится
Почините лагающую прокрутку хотя бы, прежде чем демонстрировать сайт в качестве контрпримера
Как владелец мобилы из 2017 года я недоволен этим комментарием