#go

Мамой клянусь

Source

#prog #go #article

Understanding Real-World Concurrency Bugs in Go (PDF)

In this paper, we perform the first systematic study on concurrency bugs in real Go programs. We studied six popular Go software including Docker, Kubernetes, and gRPC. We analyzed 171 concurrency bugs in total, with more than half of them caused by non-traditional, Go-specific problems. Apart from root causes of these bugs, we also studied their fixes, performed experiments to reproduce them, and evaluated them with two publicly-available Go bug detectors.

<...>

Our study found that message passing does not necessarily make multithreaded programs less error-prone than shared memory. In fact, message passing is the main cause of blocking bugs.

<...>

We believe that message passing offers a clean form of inter-thread communication and can be useful in passing data and signals. But they are only useful if used correctly, which requires programmers to not only understand message passing mechanisms well but also other synchronization mechanisms of Go.

Надо отметить, что результаты могут быть искажены тем, что:
а) выборка только из шести проектов (Docker, Kubernetes, etcd, CockroachDB, BoltDB, gRPC-go);
б) рассматриваются только баги, которые были исправлены.

Статический анализ GitHub Actions

Сразу после релиза новой версии линтера, я задался вопросом обновления своего шаблона для создания новых питоновских библиотек: https://github.com/wemake-services/wemake-python-package

И я понял, что я несколько отстал в вопросе стат анализа GitHub Actions и прочей инфраструктуры.
Расскажу о своих находках.

pre-commit ci

Все знают про пакет pre-commit? Несколько лет назад он получил еще и свой собственный CI, который умеет запускаться без дополнительного конфига. И автоматически пушить вам в ветку любые изменения. Что супер удобно для всяких ruff / black / isort и прочего. У нас такое стоит в большом количестве проектов. Вот пример из typeshed. Вот что поменялось автоматически.

Строить CI на базе pre-commit очень удобно, потому что тебе просто нужно скопировать пару строк в конфиг. А плюсов много:
- Автоматически исправляются многие проблемы
- Автоматически запускается CI, 0 настроек
- Локально все тоже работает одной командой: pre-commit run TASK_ID -a

actionlint

Первый раз я увидел actionlint внутри CPython и затащил его в mypy. Actionlint на #go, он предлагает набор проверок для ваших GitHub Actions от безопасности до валидации спеки вашего yml. Довольно полезно, позволяет найти много мест для улучшений.

test.yaml:3:5: unexpected key "branch" for "push" section. expected one of "branches", ..., "workflows" [syntax-check]
  |
3 |     branch: main
  |     ^~~~~~~
test.yaml:10:28: label "linux-latest" is unknown. available labels are "macos-latest", ..., "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file [runner-label]
   |
10 |         os: [macos-latest, linux-latest]
   |                            ^~~~~~~~~~~~~
test.yaml:13:41: "github.event.head_commit.iss.onessage" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions for more details [expression]
   |
13 |       - run: echo "Checking commit '${{ github.event.head_commit.iss.onessage }}'"
   |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Даже умеет автоматом shellcheck запускать на ваши run: скрипты!

zizmor

Исходники. Уже на #rust, он более злой. Делает похожие вещи: находит проблемы безопасности. Находит много проблем.

Вот пример, сколько всего он нашел в mypy.

warning[artipacked]: credential persistence through GitHub Actions artifacts
  --> mypy/.github/workflows/mypy_primer.yml:37:9
   |
37 |         - uses: actions/checkout@v4
   |  _________-
38 | |         with:
39 | |           path: mypy_to_test
40 | |           fetch-depth: 0
   | |________________________- does not set persist-credentials: false
   |
   = note: audit confidence → Low

error[dangerous-triggers]: use of fundamentally insecure workflow trigger
 --> mypy/.github/workflows/mypy_primer_comment.yml:3:1
  |
3 | / on:
4 | |   workflow_run:
... |
7 | |     types:
8 | |       - completed
  | |_________________^ workflow_run is almost always used insecurely
  |
  = note: audit confidence → Medium

check-jsonschema

Еще есть вот такой проект, он в основном полезен за счет доп интеграций: можно проверять dependabot.yml, renovate.yml, readthedocs.yml и многое другое.

Ставится просто как:

  - repo: https://github.com/python-jsonschema/check-jsonschema
    rev: 0.30.0
    hooks:
      - id: check-dependabot
      - id: check-github-workflows

Выводы

Как всегда – статический анализ многому меня научил. Я узнал много нового про безопасность GitHub Actions, про вектора атаки, про лучшие практики. А сколько проблем в ваших actions?

Скоро ждите весь новый тулинг в python шаблоне v2025 😎

#go #quotes

#prog #typescript

В Microsoft решили из-за проблем с производительностью переписать компилятор Typescript с Typescript на... #Go. Выбор языка аргументируют сочетанием контроля над раскладкой структур в памяти вкупе со сборщиком мусора и лёгкостью портирования уже имеющегося кода. На мой взгляд, очень странный выбор.
Производительность, впрочем, действительно улучшилась — прототип уже в состоянии компилировать реальные проекты на порядок быстрее.

#prog #go

В феврале выпустили версию Go 1.24, в которой, помимо всего прочего, поменяли реализацию встроенного типа map. Теперь там используется дизайн Swisstable. Ожидаемо перформанс операций на мапах ощутимо подрос:

In microbenchmarks, map operations are up to 60% faster than in Go 1.23. Exact performance improvement varies quite a bit due to the wide variety of operations and uses of maps, and some edge cases do regress compared to Go 1.23. Overall, in full application benchmarks, we found a geometric mean CPU time improvement of around 1.5%.

Тем не менее, реализация всё равно теряет перф из-за гарантий на поведение итерации по мапе, изменяемой в процессе итерации.

#prog #rust... #menacingopensource? #go?

🦀 go_visibility_macro 🦀
Because Rust's pub keyword was just too explicit 🔥
Finally, a revolutionary crate that brings Go's brilliant visibility conventions to Rust — because who needs explicit keywords when you can just Capitalize Everything?

use go_visibility_macro::go_visibility;

#[go_visibility]
struct MyStruct {  // Automagically `pub`!
    PublicField: i32,  // Also `pub`!
    private_field: i32,  // Not `pub` (how sad)
}

#[go_visibility]
impl MyStruct {
    fn New() -> Self {  // `pub` because it's uppercase!
        Self { PublicField: 42, private_field: 69 }
    }

    fn get_secret(&self) -> i32 {  // Still private (loser)
        self.private_field
    }
}

#go #meme

#prog #go #article

[ On | No ] syntactic support for error handling (перевод)

this_is_fine.jpg

For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.

В статье приведены аргументы в пользу сохранения статуса-кво, но они почти все — полный мусор. Особенно доставляет следующая пара:

1. Один аргумент говорит о том, что IDE и LLM могут помочь с написанием бойлерплейта, а в IDE можно этот бойлерплейт потом скрывать.
2. Второй аргумент говорит о пользе печати отладкой и возможности поставить точки останова и о том, как специфичный синтаксис этому мешает — дескать, надо на if переписывать, а это затрудняет отладку (???) и может внести тонкие ошибки.

Автор тактично умалчивает о том, что инструменты, описанные в первом аргументе, могут помочь с проблемами во втором. Особенно дико это смотрится с учётом того, что в оригинальном тексте эти два аргумента идут подряд.

— У вас стандартная библиотека работает неправильно.
— Используйте железо, на котором работает правильно.

#prog #go #suckassstory

Source

#prog #go #article

How we found a bug in Go's arm64 compiler

TL;DR: для горутин с большим стеком (больше, чем может быть закодировано в литерале в одной инструкции на ARM) в эпилоге функций изменение sp, регистра, указывающего на верхушку стека, происходило через две операции ADD, обе из которых оперировали на sp непосредственно. Если переключение (preemption) между горутинами происходило между этими двумя операциями, любые операции, которые разворачивали стек — в частности, сборщик мусора — следовали вверх по стеку вызовов по частично обновлённому и потому невалидному значению из sp, и в результате предсказуемо крашились.

Может, ввести отдельный хештег для историй дебага? 🤔

#go #meme

#prog #go #article

The Green Tea Garbage Collector

Статья о дизайне нового сборщика мусора для Go, который идейно является всё тем же mark and sweep, но сканирует память страницами вместо того, чтобы отслеживать в очереди каждую индивидуальную аллокацию.

Разумеется, выигрыш по производительности сильно зависит от формы графа объектов (и в некоторых случаях может быть хуже предыдущего), но на практике даже сканирование страниц памяти по 2 процента за раз уже даёт выигрыш.