Максим Шоломов:
Переговоры:
«Нет» Кемпа, конечно же.
«Исскуство объяснять» Ли ЛеФевра — не относится напрямую к переговорам, но нужна.
Проходит боком, но в этот же раздел:
«Агрессия» Конрада Лоренца.
Самоуправление:
«Do It Tomorrow» Марка Форстера.
«Муза и чудовище» Яны Франк.
A_Modestov: из того, что я увидел — гем простой, как пробка и по большей части отвечает за визуальный вывод, нежели за какое-то гибкое управление событиями. Можно и дописать функционал.
Tolyan Otradny: Это не смертельно, хотя я предпочитаю обходиться одним шрифтом.
Если набираете лонгрид с врезками-фактоидами — можно подобрать третий(второй) шрифт для больших цифр, например 20Db (www.dafont.com/20-db.font)
Forrest_Gump: Броадкаст в комнату — это так: socket.broadcast.to( 'some room' ).emit('some event');
Тут еще штука в том, что такой код сработает внутри листенера вида io.on('event', function(){}).
Если хочется отправить сообщение вне листенера — надо писать примерно так: io.sockets.connected[socketid].to('some room').emit('some event');
Но лучше проверить, что это так работает. Судя по документации — должно.
Дело в том, что потоки в Erlang полностью изолированные, и в отличие от Go, в Erlang нет глобальных переменных. То есть каких-либо данных за пределами потоков нет. Даже ETS, которые несколько нарушают этот принцип, на самом деле просто долгоживущие потоки.
Никакой общей памяти. Никаких общих ресурсов. Все данные передаются копированием. Общение между потоками — только через посылку сообщений.
Благодаря этому GC работает очень эффективно — как только поток умер, вся его память освобождается.
Если какие-то данные нужно из потока сохранить — придется их явно отправить другому процессу, который этим займется.
Есть единственное исключение - это binary данные. Если мы создаем бинарник больше 64 байт, то он начинает вести себя иначе, не как все остальные данные потока. Тут в игру вступают указатели, бинарная куча и магия памяти. Долгая история.
Это хорошо известный косяк, единственный известный мне баг с утечкой памяти в Erlang. Решение — явно копировать бинарники через binary:copy перед передачей их в другие потоки и дергать erlang:garbage_collect вручную по необходимости.
Есть еще с атомами одна вещь, но там не утечка, там можно просто уронить ноду. Это тоже задокументировано, тут вообще магии нет — просто количество атомов на ноде конечно, просто нужно вести себя аккуратно с ними.
Super User: Подтекает, как же без этого.
Но есть некоторая разница в реализации.
Node.js построен поверх глобального event loop. Фактически, Node.js — однопоточный. К тому же, без возможности явно управлять памятью. Это плохо тем, что дебаг утечек уводит нас в глубины реализации.
Go использует для работы множество изолированных потоков (хоть и недостаточно изолированных).
Подход Go снижает вероятность утечки памяти по вине языка и повышает вероятность утечки памяти по вине программиста. Это хорошо тем, что такие утечки проще починить.