Автор известного иструмента ESLint тоже про себя в блоге пишет, что у него тоже эта хроническая болезнь Лайма, а я и подозревал, что это какая-то блажь.
Из такого синтаксиса невозможно понять сходу, а бросаются или нет здесь какие-то исключения, потому что в Python именно исключения являются способом возврата ошибок из того или иного метода. Мы ничего здесь не видим.
В спецификации Java Virtual Machine, например, сказано, что теоретически исключение может вылететь в любом месте кода, на буквально каждом байте байт-кода. И это надо всегда иметь в виду. Жить с этим и программировать можно. Не забывать когда нужно ставить try-catch-finally.
В 95% случаев нам не нужны ошибки как значения, а нужно лишь прервать исполнение и показать где и что произошло. Исключения с этим справляются, а простыня из if err != nil избыточна.
Не проще ли взять икосаэдр (усечённый) и замостить его шестиугольниками? Как, например, в Rim World. Там тоже есть особые точки, но они не так заметны.
Короче, у нас есть чудесный оптимизатор, он чудесно всё оптимизирует до машинного кода, но только на тестах и сферических приложениях в вакууме. А в 90% типичных приложений оно не работает, ну извините, это вы плохой, негодный код пишете.
Хранятся такие коммиты не "вечно", а до тех пор, пока не будет выполнена сборка мусора через git gc, другое дело, что GitHub не предоставляет такой возможности запускать эту команду.
Кроме этого можно рассмотреть вариант с AsynchronousServerSocketChannel и AsynchronousSocketChannel. Их можно удобно использовать из Kotlin корутин. С селекторами всё немного запутанно. По производительности, вероятно, и то и то - примерно одинаково.
Может быть всё-таки проще с Kafka? После вот этих всех велосипедов.
Автор известного иструмента ESLint тоже про себя в блоге пишет, что у него тоже эта хроническая болезнь Лайма, а я и подозревал, что это какая-то блажь.
В спецификации Java Virtual Machine, например, сказано, что теоретически исключение может вылететь в любом месте кода, на буквально каждом байте байт-кода. И это надо всегда иметь в виду. Жить с этим и программировать можно. Не забывать когда нужно ставить try-catch-finally.
В 95% случаев нам не нужны ошибки как значения, а нужно лишь прервать исполнение и показать где и что произошло. Исключения с этим справляются, а простыня из if err != nil избыточна.
Если так склеено, то это топологически будет тор.
Не проще ли взять икосаэдр (усечённый) и замостить его шестиугольниками? Как, например, в Rim World. Там тоже есть особые точки, но они не так заметны.
Это редактор или 3D-шутер? В IDE тормозит обычно вовсе не графика, а куча внутренних структур, которые отвечают за анализ программы, библиотек и т.п.
Короче, у нас есть чудесный оптимизатор, он чудесно всё оптимизирует до машинного кода, но только на тестах и сферических приложениях в вакууме. А в 90% типичных приложений оно не работает, ну извините, это вы плохой, негодный код пишете.
Ну зачем я это до сих пор ношу с собой?...
Авторы в Paratype говорили, что PT Mono не предназначался для кодирования. А для заполнения и печати разных форм.
Очень похож на Spline Sans Mono.
Letter-spacing слишком большой на мой взгляд, впрочем, как и во многих других шрифтах.
Извиняюсь, ошибся,
-Fp -Z. Вопрос остаётся тот же.Plain SQL формат поддерживает сжатие (флаги
-Ft -Zодновременно) , это у вас учитывается?Хранятся такие коммиты не "вечно", а до тех пор, пока не будет выполнена сборка мусора через
git gc, другое дело, что GitHub не предоставляет такой возможности запускать эту команду.Тема: есть ли в банкомате редкоземельные металлы и сколько.
Гематит же много раз уже находили, чему они там ещё удивляются? https://ru.wikipedia.org/wiki/Марсианские_сферулы
Ну хотя бы как вариант, чтобы была настройка.
Можно сделать чтобы developer tools не только открывался по F12, но и закрывался (когда на нём фокус)? В Edge так работает.
uBlock Origin пока работает.
Кроме этого можно рассмотреть вариант с AsynchronousServerSocketChannel и AsynchronousSocketChannel. Их можно удобно использовать из Kotlin корутин. С селекторами всё немного запутанно. По производительности, вероятно, и то и то - примерно одинаково.
А что, Java "слишком сложная", чтобы на ней писать "простые сервера"?