Виталий Яковенко

Вместимость 400 символов. До версии 4.1 в байтах.

Нашел на stackoverflow.
Документация.

После нажатия в бд в ячейку пользователя в отдельный столбик записываем true или 1.
Потом на странице делаем условие и вывод кнопки.

Screeps.com тоже весьма интересен. Правда сейчас доступен только сингл плеер, но скоро обещают ввести мультиплеер.

Сначала отвечу на второй вопрос.
close() никакого отношения к scope не имеет вообще, он просто делает канал "закрытым", то есть таким, что при чтении значений из канала и записи из него возникает panic. Это всё. Соответственно...

что случится, если закрыть буферизированый канал до того, как считать из него все значения, успевшие туда попасть?

Канал закроется, при следующей попытке считать с него значение получите panic. Значения, что остались внутри, считайте потерянными, Вы их больше никак не получите.
UPD: Это не так! (см. конец поста и комментарии)

Соберется ли такой chan сборщиком мусора при уходе его в out of scope? Что будет с обьектами внутри канала?

Соберется он сборщиком мусора только тогда, когда на него никто больше не будет ссылаться (если он объявлен локально, то да, out of scope). Объекты внутри тоже соберутся, если на них больше никто не ссылается. Те, на которые еще ссылается кто-то, останутся.

Теперь замечания по Вашему примеру:

select {
case b <- number:
    fmt.Printf("Sent into b: %d\n", number)
default:
    fmt.Printf("b chan closed\n")
}

Этот кусок здорово дезинформирует. Во-первых select на запись c default секцией никоим образом не спасает от panic при записи в закрытый канал. Он всего лишь делает запись в канал всегда неблокируемой. Как только Вы таким select'ом попытаетесь записать в закрытый канал что-то, словите сразу панику. Потому правильно для восприятия это место выглядит следующим образом:

select {
case b <- number:
    fmt.Printf("Sent into b: %d\n", number)
default:
    fmt.Printf("Number %d just has been thrown away\n", number)
}

Если Вы сделаете канал a буферизированным, то тут Вам Ваши panic'и и полетят, потому что Вы пишете в закрытый канал.
Закономерный вопрос: почему тогда panic'и не летят при небуферизированном канале а?
Ответ: Вам просто везет =)
Во-первых, на playground'е runtime.GOMAXPROC=1 и runtime.NumCPU=1. То есть в реальности все дело крутится в одном потоке и параллельность тут псевдо.
Во-вторых, у меня локально (OS X) этот скрипт выкидывает panic'у после получения числа 25 даже при runtime.GOMAXPROC=1. Вам банально повезло, что внутренний планировщик горутин на playground'е ведет себя именно таки образом. При буферизированном канале он ведет себя немного иначе и Вы получаете закономерную panic'у сразу.

Если совсем на пальцах по первому вопросу, то:
При небуферизированном канале close(b) по каким-то соображения планировщика выполняется только после того как отработали обе горутины, если глянуть на вывод, то надпись "B:1" будет в самом конце. Потому то все и отрабатывает нормально, хотя это поведение совершенно не гарантированно логикой программы, наоборот, программа рассчитана на то, что close(b) выполнится сразу после того, как мы оттуда что-то считаем. Это и происходит, если канал a сделать буферизированым (надпись "B: 1" вылетает сразу), так как в этом случае планировщик меняет свои соображения, и мы получаем закономерную panic'у.

Дополнительно:
Канал b должен быть буферизированным, иначе, если горутина судья отработает быстрее чем главная горутина вообще начнет слушать канал, то все значения просто выкинутся. Эта проблема хорошо описана в этой статье на двух предпоследних абзацах.

UPD:
Я допустил ошибку, как верно указали в комментариях Виталий Яковенко и SilentFl, закрытый канал не выдает panic при чтении с него. Он разрешает считать все значения, которые в нем остались, после чего отдает "пустые" значения для свое типа, больше никогда не блокируя выполнение.
Закрытый канал panic'ует только при попытке отправить в него значение.

Во втором варианте вроде как так. Чтобы объявить тело функции, нужно использовать ключевое слово func и никак иначе, что разумно по своим причинам. Как минимум, Вам не нужно помнить и держать в голове какая сигнатура кроется за каким типом, когда Вы смотрите на тело функции, то есть для каждого тела функции видно явно что оно должно принимать и возвращать. К тому же, дополнительная гибкость (в данном случае: объявление функции через алиасы типов, а не ключевое слово func) - это всегда удар по производительности, в данном случае - вероятное повышении времени компиляции, а для разработчиков языка это один из главных факторов, потому они очень и очень придирчиво относятся ко всем введениям и возможностям компилятора. Вон, от них даже дженериков никак допроситься не могут. Более того, выгода от возможности объявлять тело функции через алиасы типов (type aliases), а не ключевое слово func, крайне сомнительна, Вам так не кажется? К тому же не стоит путать объявление типа и объявление функции. Логично, что всегда сначала должен быть объявлен тип, а потом уже сама функция/переменная/структура, просто синтаксис языка позволяет сократить писанину. А Вы в данной ситуации хотите обойтись только созданием типа. А как тогда будете именовать входные параметры функции при её объявлении, если таковы имеются?

Выгода же абсолютно такая же, как и при других вариантах применения алиасов типов. В первую очередь - это возможность дополнительного контроля типов.
Например: Вы разрабатываете библиотеку (свой package) и Вам нужно, чтобы какая-то функция получала на вход только те функции, которые определены у Вас в библиотеке и никакие другие. Тогда Вы создаете алиас типа на сигнатуру функции и делаете его невидимым для внешних потребителей (объявляете с маленькой буквы).

package mylib

type someFunc func() bool

var (
	Apple someFunc = func() bool {
		return true
	}
	Dog someFunc = func() bool {
		return false
	}
)

func Consume(f someFunc) {
	f()
}

После этого внешний потребитель не сможет вызвать функцию Consume() передав туда какую угодно функцию, а только те функции, которые Вы ему приоткрыли.

package main

import "mylib"

func main() {
	externalFunc := func() bool {
		return true
	}
	
	mylib.Consume(externalFunc) 	// fail
	var extF mylib.someFunc		// fail
	
	mylib.Consume(mylib.Apple)	// success
}

Таким образом, обвязав свою библиотеку дополнительным контролем типов, Вы добились желаемого результата.
Во вторую очередь - это возможность сделать код более читаемым. Например, у Вас где-то есть достаточно громоздкая сигнатура и её нужно использовать во многих местах, чтобы не писать одно и то же много раз, Вы пишете сигнатуру только при объявлении функции и создании алиаса, а потом жонглируете алиасом.

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

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

Квайнам нельзя читать самих себя, это не считается.

Не должно оно освобождать, если система не попросит. Так работает большинство сборщиков, они отдают память «обратно в программу».