https://stackoverflow.com/questions/46864623/which-of-coroutines-goroutines-and-kotlin-coroutines-are-faster/46865213
топ объяснение отличия го горутин от котлин корутин
гуглтранслейт

Сопрограммы в Kotlin реализованы иначе, чем горутины в Go, поэтому какой из них «быстрее», зависит от проблемы, которую вы решаете, и типа кода, который вы пишете.

В общем, очень сложно заранее сказать, какой из них лучше подойдет для решения вашей проблемы. Чтобы понять это, вам нужно запустить тесты для ваших конкретных рабочих нагрузок. Тем не менее, вот общий обзор ключевых различий, который должен дать вам некоторое представление.

Сопрограммы Kotlin требуют меньше памяти на один простой экземпляр, чем горутины Go. Простая сопрограмма в Kotlin занимает всего несколько десятков байт кучи памяти, тогда как горутина Go начинается с 4 КБ пространства стека. Это означает, что если вы планируете иметь буквально миллионы сопрограмм, то сопрограммы в Kotlin могут дать вам преимущество перед Go. Это также делает сопрограммы Kotlin более подходящими для очень кратковременных и небольших задач, таких как генераторы и ленивые последовательности.

Сопрограммы Kotlin могут работать с любой глубиной стека, однако каждый вызов функции приостановки выделяет объект в куче для своего стека. Стек вызовов в сопрограммах Kotlin в настоящее время реализован как связанный список объектов кучи. Напротив, горутины в Go используют линейное пространство стека. Это делает приостановку игры с глубокими стеками более эффективной в Го. Итак, если код, который вы пишете, приостанавливается очень глубоко в стеке, вы можете обнаружить, что горутины для вас более эффективны.

Эффективный асинхронный ввод-вывод — очень многомерная проблема проектирования. Подход, эффективный для одного типа приложений, может не обеспечить наилучшую производительность для другого. Все операции ввода-вывода в сопрограммах Kotlin реализуются библиотеками, написанными на Kotlin или Java. Для кода Kotlin доступно огромное количество библиотек ввода-вывода. В Go асинхронный ввод-вывод реализуется средой выполнения Go с использованием примитивов, недоступных для общего кода Go. Если подход Go к реализации операций ввода-вывода хорошо подходит для вашего приложения, то вы можете обнаружить, что его тесная интеграция со средой выполнения Go дает вам преимущество. С другой стороны, в Kotlin вы можете найти библиотеку или написать ее самостоятельно, реализующую асинхронный ввод-вывод таким образом, который лучше всего подходит для вашего приложения.

Среда выполнения Go берет на себя полный контроль над планированием выполнения горутин в физических потоках ОС. Преимущество такого подхода в том, что вам не придется обо всем этом думать. С помощью сопрограмм Kotlin вы получаете детальный контроль над средой выполнения ваших сопрограмм. Это чревато ошибками (например, вы можете просто создать слишком много разных пулов потоков и тратить время процессора на переключение контекста между ними). Однако это дает вам возможность точно настроить распределение потоков и переключение контекста для вашего приложения. Например, в Kotlin легко выполнить все приложение или подмножество его кода в одном потоке ОС (или пуле потоков), чтобы полностью избежать переключения контекстов между потоками ОС, просто написав для этого соответствующий код.

Обертка на гитом делающая его UX немного задизайненным
https://gitless.com/

перешел на обычный колымак, третий раз уже перехожу на какую то раскладку за 2 недели, очинь больна
руки сначала тянуца к запоменной на автомате, потом подкюлчаеца мозг который вспоминает что теперь эта буква в другом месте, и так с каждой поменянной буквой из 4рех(отличие DH от обычной)

(в DH версии ctrl v это ctrl b)

перешел потому что ctrl v работает через жопу, какие то проги читают фактические буквы, какие то коды,
в итоге в некоторых в ру раскладке это ctrl м а в англ ctrl b
а в других и в ру и в ен ctrl b
и пользоваца таким невозможно, остальные шоткаты еще ладно, но ctrl v слишком частый

кста гном шелл также обосрался и кастомный шоткат на скриншот, который у меня ctrl s уже лет 10 на всех ОС, на колымаке он считывает как ctrl d(валдно для колымака), а на ру как ctrl s, аррррр

паучья ель

выставил колымак на маке(там кстати нет DH версии), ща смотрю на винде, а тут токо дроваки(((

UPD: https://colemak.com/Windows

шашки на полигонах, сделано на polygonjs и threejs #indie

https://polyreplay.com/checkerstwist

ну и в чем он не прав

GTK все еще единственный фреймворк которому удалось в универсальный UX между сенсой и десктопом, особенно со появлением LibAdwaita
-M$ попытался когда то в плитки и зафейлил задеприкейтив Metro
-Apple не пытается, развивая ipadOS паралельно
-Qt имеют 2 отдельных стака QtQuick для сенсы и Qt Widgets для десктопа(сумашедшие из тг не в счет, у них все кастомное)

https://github.com/haskell-infra/www.haskell.org/pull/292
UwU logo для хаскеля
LGTO

походу добавили только под флагом
haskell.org/?uwu=true
авойдят фан эт ол кост

забиндил 2 функции из котлин сериалайзабл либы

Демократия победила, лол

Штош, теперь это место занимает javanoscript

Интересные наблюдения от колымаков

1) Идея продолжает распознавать написанное в неправильной раскладке(все остальные, вроде поисковиков, перестают)

2) Линь ваще невдупляет что в играх должна быть wasd, не знаю как винда распознает что есть игоры, но в них она включает wasd, добавлять обычный qwerty и убирать после игры супер запара

3) Если вы запомнили пароль не по символам а по расположению клавишь на линуксе вы его больше не введете, винда же добавляет обычную qwerty на экран входа, даже если в системе у вас только колымак

4) изза того что расположение клавиш помнят только обе руки вместе, набирать чето одной анриал

В CPP 23 добавили print
не прошло и 29ти лет

зато экзостив

(несетъся)

правильный вариант только один

; это месадж каскадинг, поэтому каждый контеинс применен к this
|> это пайпинг, так что ифту применяются к результатам контеинс

пара очевидных вещей
в раст версии кажется будто бы это могло быть сделано ради экзостивности чека, но в таком коде если добавлять новые варианты то придеца 3 раза менять
(_, _, true)
на
(_, _, true, _)