Привет, Хабр! Меня зовут Константин, я работаю в команде файлового доступа в YADRO. Помимо основной работы, я пишу в open source, работаю над несколькими проектами — в том числе над дебаггером BugStalker (BS) на Rust. 

В этой статье речь пойдет о разработке дебаггеров. Расскажу, какие технологии лежат в основе любого популярного отладчика и как с их помощью реализуются точки останова или функции step. Особое внимание уделим нюансам отладки Rust-кода и поддержке Rust в дебаггерах.

Если уже решили писать свой отладчик, дочитайте до конца — там будет аналитика, которая поможет не наступить на Rust-грабли.

Всем привет! Симулятор написания echo-server'ов на связи. Сегодня завершающая часть из цикла посвященного io_uring. В этом материале мы поговорим о настройке io_uring, режимах работы и перформансе. Полученные знания используем чтобы улучшить конкурента netpoller'у из предыдущей статьи. 

Всем привет! Продолжаем разбираться с io_uring. Сегодня попробуем использовать io_uring для решения прикладных задач. А именно напишем полноценный TCP сервер. Для этого мигрируем наши приложения с C на GO. Не буду писать длинные вступления, вперед экспериментировать!

Всем привет! Наверное, многие уже слышали о новом интерфейсе ядра Linux — io_uring. Это новый способ работы с асинхронным I/O (и не только) в Linux. Кстати, новый он не только из-за даты выхода в свет, но и в плане подходов, которые предлагает разработчику.

Заинтересовало? Более подробно разберемся под катом.

Пока GO-сообщество томится в ожидании версии 1.18 и обещанных в ней дженериков язык продолжает развиваться и в других направлениях. В вышедшей недавно версии 1.17 хватает интересных нововведений. Среди них есть одно, давно ожидаемое, изменение — новый calling convention. Что же это такое, в чем отличие от старого соглашения о вызовах, какое влияние будет оказано на прикладную GO разработку? Постараемся разобраться в этой статье.

В последнее время на хабре, и не только, можно наблюдать интерес GO сообщества к луковой/чистой архитектуре, энтерпрайз паттернам и прочему DDD. Читая статьи на данную тему и разбирая примеры кода, постоянно замечаю один момент — когда дело доходит до хранения сущностей предметной области — начинается изобретение своих велосипедов, которые зачастую еле едут. Код вроде бы состоит из набора паттернов: сущности, репозитории, value object’ы и так далее, но кажется, что они для того там “чтобы были”, а не для решения поставленных задач.
В данной статье я бы хотел не только показать, что, по моему мнению, не так с типичными DDD-примерами на GO, но также продемонстрировать собственную ORM для реализации персистентности доменных сущностей.

Мотивация

$arr = [];

for ($i =0; $i < 300; $i++)
{
  $arr[rand(1,1000)] = 1;
}
 
$sum = 0;
for ($i = 1001; $i < 200000000; $i++){
  if (array_key_exists($i, $arr)){
    $sum++;
  }
}

$arr = [];

for ($i =0; $i < 300; $i++)
{
  $arr[rand(1,1000)] = 1;
}

sort($arr);
 
$sum = 0;
for ($i = 1001; $i < 200000000; $i++){
  if (array_key_exists($i, $arr)){
    $sum++;
  }
}