#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 процента за раз уже даёт выигрыш.