Очевидно, что через linkname

package main

import (
     _ "unsafe"
)

//go:linkname throw runtime.throw
func throw(v string)

func main() {
    throw("error")
    // Вызовется функция отсюдова
    // https://github.com/golang/go/blob/go1.26.2/src/runtime/panic.go#L1220
}

go позволяет линковаться с символами (переменными, функциями и тд) из некоторых других пакетов, даже если они не были экспортированы. Это может сильно не понравиться создателям библиотек (в данном случае стандартной библиотеке), всё-таки приватные (неэкспортируемые) функции приватны по какой-то причине.
Поэтому злоупотребление может привести к публичному и официальному позору. Зато можно делать так:

package main

import (
     _ "unsafe"

     _ "github.com/rs/zerolog"
)

//go:linkname needsQuote github.com/rs/zerolog.needsQuote
func needsQuote(s string) bool 

func main() {
    // Можно линковаться даже к сторонним библиотекам!
    println(needsQuote("plain"), needsQuote("with space"))
    // > false true 
}

// A
true false 0xabcd 0xabcd

// B
false true 0xabcd 0xabcd

Я придумал этот вопрос после случайного прочтения спецификации go и, признаюсь, сам не до конца понимаю, почему так происходит :)

По спецификации go адреса zero-sized объектов, например, структур, могут быть одинаковыми. Из-за этого довольно ожидаемо, что в обоих случаях println(a, b) даст одинаковый адрес. (*a == *b) == true тоже понятно, почему - обе структуры пустые, значит у них нет полей, что могли бы отличаться, поэтому они равны.
(&a == &b) == false - адреса самих переменных a и b, то есть адреса адресов, конечно, отличаются.
А вот почему само сравнение a == b в одном случае true, а в другом false?
Связано это с тем, что в коде, где мы не берём адреса a и b (то есть адреса адресов структур), компилятор оптимизирует сравнение a == b в false, потому что a и b порождены из разных new (случай B).
В первом же случае go не оптимизирует a == b в false, так как a и b материализуются, при этом они имеют один и тот же адрес и
go честно сравнивает адреса.

Важно отметить, что данный ответ не закреплён в спецификации go, в будущих версиях поведение может поменяться.
Поэтому GPT-5.6 SOL без гугления и использования go ответит:

// A
false false 0xabcd 0xabcd

// B
true true 0xabcd 0xabcd

А если ему дать время и go, то он получит правильный ответ.
Иными словами, если волк быстро отвечает - возможно, он использует LLM, но без компилятора.
Если тянет время - с компилятором.

Человек же, если знает, что адреса у пустых структур могут быть одинаковыми, скорее ответит так:

// A
true false 0xabcd 0xabcd

// B
true true 0xabcd 0xabcd

Хорошего решения нет, но можно так:

func goid() int {
    var buf [64]byte
    runtime.Stack(buf[:], false)
    
    spaceIdx := bytes.IndexByte(buf[:], ' ')
    if spaceIdx == -1 { return 0 }
    
    secondSpaceIdx := bytes.IndexByte(buf[spaceIdx+1:], ' ')
    if secondSpaceIdx == -1 { return 0 }
    
    id, err := strconv.Atoi(string(buf[spaceIdx+1 : spaceIdx+secondSpaceIdx+1]))
    if err != nil { return 0 }
    
    return id
}

Что?

Помните, когда вылетает паника, пишется stacktrace с айдишником горутины? Ну так вот, goid() как раз достаёт stacktrace как строчку и из него парсит айди горутины :). Есть, конечно, более быстрые решения на всяких ассемблерах

Кстати, из этой темы можно сделать адекватный вопрос: а почему в go нет хорошего решения для получения айди горутины?.

Причина - сознательное решение создателей go не делать goid, чтобы у разработчиков не было соблазна делать goroutine-local хранилища или как-либо иначе привязывать логику на идентификатор горутины.

fatal и throw - это что-то вроде внутренних паник из самого go. Пользователь go не может самостоятельно их вызвать (нормальным способом), при этом обе ошибки необрабатываемые, их нельзя зарекаверить.

Разница между throw и fatal в общем случае в том, что fatal вызывается, если накосячил разработчик, а throw - если создатели go.

Прекращение работы программы с ошибкой, выкинутой через fatal. Не паника, как могли бы сказать многие, а fatal (см. предыдущий вопрос).

Сделано это из-за того, что в случае конкурентного доступа без мьютексов память в мапе повреждается. Да и go не всегда может задетектить нарушение доступа, поэтому можно повредить память и даже не получить fatal.

Аналогичное, кстати, происходит с разблокировкой не заблокированного мьютекса.

В go нет пропагации паник по родительским горутинам, из-за чего любая паника, что не была обработана в какой-либо горутине, приведёт к остановке процесса.

Данный вопрос, так-то, полезный. Важно знать, что недостаточно поставить recover() в родительской горутине.

На этот вопрос есть 3 ответа:

1. Нет, потому что после удаления объекта из мапы её память подчищается, а так как мы удаляем то же количество, что и создаём, роста не будет

2. Да, будет увеличиваться, потому что в go мапы автоматически не уменьшаются в размере после delete

3. Да, вначале вырастет, а потом выйдет на плато, потому что хоть в мапе после удаления объекты не вычищаются, но после пересоздания для роста мапы они всё-таки удаляются. Также в go мапа может вырасти на тот же размер, что и занимает сейчас, то есть по сути просто очиститься.

Собственно, правильный ответ - 3.

6

Связано это с тем, что return 5, по сути, записывает в x значение 5, а defer увеличивает его на 1, после чего возвращается именно x, а не 5.

Да так просто удобнее :)

Не нужно постоянно конвертировать int в uint, не нужно опасаться за случайные переполнения uint и тд

Если кратко, то это so/dll для go. С их помощью можно написать гошный код, скомпилить его, а потом вызывать его, подключая его в runtime, а не на compile time.

1. Нестабильные - плагин и конечный код надо компилировать на одной и той же версии компилятора, архитектуре, машине, фазе луны и тд и тп.

2. Не работают на Windows (ну и не надо).

3. Требуют cgo.

Интересный факт

Плагины настолько никому не нравятся, что, например, terraform для своей системы плагинов, которые пользователи могут разработать, скачать и установить без рекомпиляции всего проекта, использует... gRPC! Каждый плагин буквально поднимает свой gRPC сервер и общается с родителем через него.

Очевидно, нам надо просто немного поменять сигнатуру и тело:

func trim[T any, PT interface {
    *T
    WithTime
}](arr []T, from time.Time) []T {
    var newArr []T
    for i := range arr {
        if PT(&arr[i]).Time().After(from) {
            newArr = append(newArr, arr[i])
        }
    }

    return newArr
}

Да, так можно делать, сами интерфейсы дженериков могут ссылаться на другие дженерики, а также встраивать их. В результате тип T - это просто любой тип, а PT - это поинтер на T и одновременно тип, реализующий интерфейс WithTime. А сам слайс arr всё так же остаётся []T, то есть слайсом не на поинтеры, а на копии объектов типа T.

Y из-за выравнивания.

Казалось бы, обе должны весить 15 байт (8+4+3), но в go, как и в других языках и даже базах данных (например, postgres) есть такая штука как выравнивание. Компилятор в структуре к некоторым полям добавляет пустые байты (padding), это нужно для удобства (и не только) работы процессора со структурой. Правило оптимизации довольно простое - сортируйте поля по размеру по убыванию (вначале слайсы, интерфейсы, стринги, далее мапы, int64, float64 и тд и тп). В данном же случае размер структуры X будет равен 24 байтам, а Y - 16 байтам.

type X struct { 
	a bool // 1 byte 
	b bool // 1 byte 
	// 2 byte padding 
	c int32 // 4 byte 
	d int64 // 8 byte 
	e bool // 1 byte 
	// 7 byte tail padding 
} // total: 24 byte

А как работает выравнивание?

Если очень упрощать, то правила такие:

1. Для каждого типа в структуре вычисляется выравнивание (alignment), равное минимальному из размера типа и 8 байт (в основном для 64-битных архитектур). Например, поля bool, int16, int64 и interface будут иметь выравнивания 1, 2, 8 и 8. Массивы с compile-time размером (e.g. [12]byte), по сути, являются просто последовательностью из элементов соответствующего типа.

2. Каждый элемент структуры должен начинаться с отступа (offset) кратного своему выравниванию. Например, int32 может начинаться с 0, 4, 8, 12 и тд байта. Если это невозможно, то добавляются пустые байты до выравнивания. Эти байты называются паддингом.

3. Финальный размер структуры должен быть кратен максимальному из выравниваний, например, если в структуре есть int64, то её размер может быть 8, 16, 24 и тд. Недостающий размер заполняется через tail padding.

По моему опыту, многие даже мидлы знают о выравниваниях, поэтому для синьоров можно поспрашивать про типы аллокаторов, классы размеров, green tea gc и тд.

Когда go может гарантировать, что в указанном коде используется только 1 конкретный тип. Грубо говоря, если можно вручную переписать код на конкретные типы и ничего не сломается.

Также с go 1.21 девиртуализация может быть через PGO

Сравнивать каналы, мьютексы и атомики, конечно, не совсем корректно, плюс однозначно ответить на указанный вопрос нельзя, так как архитектура процессора может влиять на ответ, но если попытаться хотя бы как-то ответить, то ответ будет таков:

• Любой канал состоит минимум из одного мьютекса.

• RW мьютексы состоят из мьютекса, 2 семафоров и 2 атомиков.

• Атомики работают на уровне CPU.

Следовательно, при прочих равных, атомик быстрее мьютекса, а мьютекс - канала.

В 1.26, конечно же, будет 1.

Но модели не обучались на 1.26 версии go, из-за чего они ответят, как было бы корректно раньше:

Можно просто брать любую фичу из последней версии go (да и любого другого проекта, фреймворка или языка) и спрашивать о ней.