Или берем fiber у которого соответствующее решение уже сделано и решается флагом в конфиге. При чем nginx не нужен, под капотом используется сокет с опцией reuse port
Дело не в частоте обновления развертки, а в частоте мерцания подсветки. Именно из-за нее глаза устают от длительного просмотра контента на экране. И эта проблема частично решена в некоторых IPS матрицах, но oled(и его вариации) страдают низкой частотой мерцания чуть ли не поголовно. И именно тут раскрывается преимущество e-ink дисплеев: если ЖК экранам различных технологий обязательна подсветка для работы, и желательно отсутствие попадания света извне, то e-ink, наоборот, своя подсветка не нужна для работы, и нужно только внешнее освещение, которым при чтении вы в 90% случаев будете пользоваться
Не знаю как оно сейчас у Самсунга, но раньше я часто ездил в Украину и постоянно при смене оператора в роуминге мне навязчиво телефон устанавливал местные "рекомендованные приложения". При чем из всех телефонов, что у меня были, такой ерундой только самсунг занимается
Есть небольшое отличие. Когда вам понадобится привести ваш слайс байт к строке, у вас произойдет аллокация новой строки. strings.Builder под капотом применяет unsafe приведение, чтобы избежать аллокаций. Конечно вы все это можете сделать сами, но зачем вам в вашем коде unsafe?
Вы слышали про такой подход, как event sourcing? Вот тут такая же логика: ваш баланс - это результат всех операций. При совершении транзакции, восстанавливается баланс исходя из всех событий. Естественно когда событий много, это может быть проблемой в производительности. Для таких случаев делаются снапшоты каждые n-событий или периодически. Таким образом оптимизированная версия будет восстанавливать баланс из снапшота и событий после снапшота. При грамотном подходе к блокировкам можно добиться хорошего уровня параллелизма
Вообще-то в абсолютном большинстве проектов на раст такой приписки нет. Такой суффикс ставится потому что проект повторяет уже существующий проект, но на другом языке
Ну вообще есть, просто в Go нужно иметь понимание ошибок, которые нужно именно обработать и которые должны прервать выполнение(panic). Если очень надо именно выбросить ошибку вверх по стеку, паникуйте и отлавливайте ее централизовано
В данном случае это вообще не будет ошибкой, потому что компилятор спокойно заинлайнит функцию, а затем разыменует указатель так как в нем не будет необходимости после инлайна. Автор нарушил свой же пункт о преждевременной оптимизации.
Кстати даже если допустить, что функция не заинлайнится, то передача по значению чаще всего быстрее, так как создание копии на стеке как правило дешевле алокации в куче и сборки мусора. Копия на стеке дороже только в случае больших структур
Мда, как говорится "Молчи - за умного сойдешь"
Или берем fiber у которого соответствующее решение уже сделано и решается флагом в конфиге. При чем nginx не нужен, под капотом используется сокет с опцией reuse port
Вы забываете, что всегда можно взять пк и найти все, что нужно на небезызвестных площадках)
Некоторые вообще пилили калькулятор на html/css без единой строки на js-е)
Дело не в частоте обновления развертки, а в частоте мерцания подсветки. Именно из-за нее глаза устают от длительного просмотра контента на экране. И эта проблема частично решена в некоторых IPS матрицах, но oled(и его вариации) страдают низкой частотой мерцания чуть ли не поголовно. И именно тут раскрывается преимущество e-ink дисплеев: если ЖК экранам различных технологий обязательна подсветка для работы, и желательно отсутствие попадания света извне, то e-ink, наоборот, своя подсветка не нужна для работы, и нужно только внешнее освещение, которым при чтении вы в 90% случаев будете пользоваться
Скорее говорится не об идентичности процессоров, а о той же базе данных, которую заложили в обоих
Чипсет x99 - это HEDT платформа. Он официально совместим топовыми i7
Не знаю как оно сейчас у Самсунга, но раньше я часто ездил в Украину и постоянно при смене оператора в роуминге мне навязчиво телефон устанавливал местные "рекомендованные приложения". При чем из всех телефонов, что у меня были, такой ерундой только самсунг занимается
Есть небольшое отличие. Когда вам понадобится привести ваш слайс байт к строке, у вас произойдет аллокация новой строки. strings.Builder под капотом применяет unsafe приведение, чтобы избежать аллокаций. Конечно вы все это можете сделать сами, но зачем вам в вашем коде unsafe?
Это неправда. Для запуска даже самых продвинутых моделей достаточно игровых видеокарт. Конечно только для личного пользования
Должны были иметь в команде QA, которые додумались бы попытаться "ломать" систему в том числе и таким образом
Зачем ИИ для задачи, которая решается без ИИ гораздо меньшими затратами? В данном случае просто проверять кодировку символов
Вы слышали про такой подход, как event sourcing? Вот тут такая же логика: ваш баланс - это результат всех операций. При совершении транзакции, восстанавливается баланс исходя из всех событий. Естественно когда событий много, это может быть проблемой в производительности. Для таких случаев делаются снапшоты каждые n-событий или периодически. Таким образом оптимизированная версия будет восстанавливать баланс из снапшота и событий после снапшота. При грамотном подходе к блокировкам можно добиться хорошего уровня параллелизма
Вообще-то в абсолютном большинстве проектов на раст такой приписки нет. Такой суффикс ставится потому что проект повторяет уже существующий проект, но на другом языке
Можно попытаться написать фронтенд для llvm)
В особо крупных проектах Go и так не использовался часто
Тут скорее должен быть вопрос к написавшему: а почему бы ошибку не обработать на месте или не добавить ей контекста?
Ну вообще есть, просто в Go нужно иметь понимание ошибок, которые нужно именно обработать и которые должны прервать выполнение(panic). Если очень надо именно выбросить ошибку вверх по стеку, паникуйте и отлавливайте ее централизовано
V8 научился запускать typescript без компиляции в js. По сути это оно и есть: js со статической типизацией
В данном случае это вообще не будет ошибкой, потому что компилятор спокойно заинлайнит функцию, а затем разыменует указатель так как в нем не будет необходимости после инлайна. Автор нарушил свой же пункт о преждевременной оптимизации.
Кстати даже если допустить, что функция не заинлайнится, то передача по значению чаще всего быстрее, так как создание копии на стеке как правило дешевле алокации в куче и сборки мусора. Копия на стеке дороже только в случае больших структур