кап на пальцах
1 консистентность данных
2 доступность
3 распределенность
если 1 и 3, то нам нужно время на синхранизацию разделенных систем, в которое она будет не доступна
или 2 3, теперь данные в ней не всегда консистентны, тк кк мы синхронизируемся на ходу(евеншуалли все будет консиснат(ne budet))
или 1 2 все в одном месте\атомик на врайт, синхронить не надо, но это нихера не скейлица
по крайней мере так я ето понимаю #info
1 консистентность данных
2 доступность
3 распределенность
если 1 и 3, то нам нужно время на синхранизацию разделенных систем, в которое она будет не доступна
или 2 3, теперь данные в ней не всегда консистентны, тк кк мы синхронизируемся на ходу(евеншуалли все будет консиснат(ne budet))
или 1 2 все в одном месте\атомик на врайт, синхронить не надо, но это нихера не скейлица
по крайней мере так я ето понимаю #info
👍2
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 легко выполнить все приложение или подмножество его кода в одном потоке ОС (или пуле потоков), чтобы полностью избежать переключения контекстов между потоками ОС, просто написав для этого соответствующий код.
топ объяснение отличия го горутин от котлин корутин
гуглтранслейт
Сопрограммы в 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 легко выполнить все приложение или подмножество его кода в одном потоке ОС (или пуле потоков), чтобы полностью избежать переключения контекстов между потоками ОС, просто написав для этого соответствующий код.
Stack Overflow
Which of coroutines (goroutines and kotlin coroutines) are faster?
Kotlin corutines is sugar for finite state machine and some task runner (for example, default ForkJoinPool). https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md#
gavr_sas
такс, удаляю обычный инглишь перехожу в фул колымак DH ОРТОЛИНЕЙНАЯ HD 4K+ GOTY на стимдеке
перешел на обычный колымак, третий раз уже перехожу на какую то раскладку за 2 недели, очинь больна
руки сначала тянуца к запоменной на автомате, потом подкюлчаеца мозг который вспоминает что теперь эта буква в другом месте, и так с каждой поменянной буквой из 4рех(отличие DH от обычной)
(в DH версии ctrl v это ctrl b)
перешел потому что ctrl v работает через жопу, какие то проги читают фактические буквы, какие то коды,
в итоге в некоторых в ру раскладке это ctrl м а в англ ctrl b
а в других и в ру и в ен ctrl b
и пользоваца таким невозможно, остальные шоткаты еще ладно, но ctrl v слишком частый
кста гном шелл также обосрался и кастомный шоткат на скриншот, который у меня ctrl s уже лет 10 на всех ОС, на колымаке он считывает как ctrl d(валдно для колымака), а на ру как ctrl s, аррррр
руки сначала тянуца к запоменной на автомате, потом подкюлчаеца мозг который вспоминает что теперь эта буква в другом месте, и так с каждой поменянной буквой из 4рех(отличие DH от обычной)
(в DH версии ctrl v это ctrl b)
перешел потому что ctrl v работает через жопу, какие то проги читают фактические буквы, какие то коды,
в итоге в некоторых в ру раскладке это ctrl м а в англ ctrl b
а в других и в ру и в ен ctrl b
и пользоваца таким невозможно, остальные шоткаты еще ладно, но ctrl v слишком частый
кста гном шелл также обосрался и кастомный шоткат на скриншот, который у меня ctrl s уже лет 10 на всех ОС, на колымаке он считывает как ctrl d(валдно для колымака), а на ру как ctrl s, аррррр
👍1
хелдайверс сгорели заставив PC(PC) юрезов логиница в PSN
1) не у всех стран есть доступ к PSN, не токо рф но еще Африка и Филиппины
2) зато теперь там можно показывать PS рекламу
1) не у всех стран есть доступ к PSN, не токо рф но еще Африка и Филиппины
2) зато теперь там можно показывать PS рекламу
gavr_sas
перешел на обычный колымак, третий раз уже перехожу на какую то раскладку за 2 недели, очинь больна руки сначала тянуца к запоменной на автомате, потом подкюлчаеца мозг который вспоминает что теперь эта буква в другом месте, и так с каждой поменянной буквой…
выставил колымак на маке(там кстати нет DH версии), ща смотрю на винде, а тут токо дроваки(((
UPD: https://colemak.com/Windows
UPD: https://colemak.com/Windows
GTK все еще единственный фреймворк которому удалось в универсальный UX между сенсой и десктопом, особенно со появлением LibAdwaita
-M$ попытался когда то в плитки и зафейлил задеприкейтив Metro
-Apple не пытается, развивая ipadOS паралельно
-Qt имеют 2 отдельных стака QtQuick для сенсы и Qt Widgets для десктопа(сумашедшие из тг не в счет, у них все кастомное)
-M$ попытался когда то в плитки и зафейлил задеприкейтив Metro
-Apple не пытается, развивая ipadOS паралельно
-Qt имеют 2 отдельных стака QtQuick для сенсы и Qt Widgets для десктопа(сумашедшие из тг не в счет, у них все кастомное)
👍1
https://github.com/haskell-infra/www.haskell.org/pull/292
UwU logo для хаскеля
LGTO
походу добавили только под флагом
haskell.org/?uwu=true
авойдят фан эт ол кост
UwU logo для хаскеля
LGTO
походу добавили только под флагом
haskell.org/?uwu=true
авойдят фан эт ол кост
This media is not supported in your browser
VIEW IN TELEGRAM
Штош, теперь это место занимает javanoscript