Как не наступать на грабли в Go

[fogone]

Назвать статью «Как не наступать на грабли» стоило, если бы вы написали, как на них не наступать, а так это скорее «список граблей по инвентарному перечню», если вам прилетит в лоб, вы знайте, что действительно такие грабли есть. Статья хорошая, но очень в ней не хватает к каждому пункту, что же собственно нужно делать, чтобы на них не ступать, как создатели языка предполагали использовать все эти неочевидные моменты, видимо есть какие-то бестпрактис маневрирования между этими граблями, на мой взгляд эта информация очень лаконично дополняла бы список самих проблем и причин их появления.

[unixowl]

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

[divan0]

Да, пожалуй этого не хватает в статье — впрочем она не столько про сами грабли, сколько про понимание внутренностей, которое позволит обходить не только эти, но и другие грабли. Но спасибо за фидбек.

[den_golub]

<sarcasm Не использовать Go? sarcasm>

[lxsmkv]

я честно говоря подумал тоже самое. Но обьясню. Если понаблюдать за развитием языков программирования, то одни появляются чтобы избавиться от недостатков других. Но и они не получаются без недостатков. Поэтому возникает резонный вопрос, а надо ли оно в таком количестве. На самом деле надо — потому что прийти к совершенству можно только через эволюцию или революцию. Но скорее через революцию, потому что при эволюции мы пользуемся знанием предыдущих поколений, а они не совершенны и максимум, что получится в конце эволюции — идеальная раскоряка :) А при революции создается что-то принципиально новое. Получается, продолжу рассуждение, что если посредством революции не получилось идеального результата, скорее всего нет смысла его улучшать, а нужно готовить следующую революцию.

[divan0]

Нет никакого "совершенства". Язык это всегда сотни компромиссов.

[r3code]

По моему «грабли» лучше заменить на «подводные камни». И было бы вроде «Подводные камни в Go о которых мы должны помнить». Для меня это кажется, более наглядно и обыденно, т.к. подводные камни как раз то что вы описали — то чего не видно на поверхности и может причинить неприятности, если не знать, где они. И да — о них всегда узнаешь впервые, когда уже напоролся.

[xenolog]

ошибочка небольшая:

a := make([]int, 32)
b := a[1:16]
a = append(a, 1)
a[2] = 42

cap(b) будет не 15, как указано на рисунке, а 31
(https://play.golang.org/p/jnzXdQTGSCJ)

[tumbleweedd]

в первом случае изменяя переменную p в функции Foo(), вы будете работать с копией и не измените значение оригинальной переменной (p1), а втором — измените, поскольку указатель будет ссылаться на оригинальную переменную. 

Тут стоит упомянуть, что во втором случае не всегда, передавая указатель, мы изменим данные

В примере ниже будет выводиться Bob, так как мы передаём копию указателя в функцию, где затираем этот указатель (а не сами данные, так как не обращаемся напрямую к данным) новым

type Person struct {
	Name string
}

func main() {
	p := &Person{
		Name: "Bob",
	}

	fmt.Println(p.Name) // Bob

	changePerson(p)

	fmt.Println(p.Name) // Bob
}

func changePerson(p *Person)  {
	p = &Person{
		Name: "Vasya",
	}
}