История изменений
Исправление tp_for_my_bunghole, (текущая версия) :
А теперь сравни это с JS/CPython
Там нет параллелизма. В Python только вспомогательные неявные треды используются. Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов.
Позиция разрабов Go — разделяемых данных у приложения быть не должно.
Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы. Можно передавать сами данные через каналы, или можно передавать сигнальные данные что какой-то массив(или его часть slice) теперь доступен горутине получившей сигнал через канал.
Есть статьи типа «а почему не использовать сырой Mutex? Channels are bad!». Но проблема Mutex в том что если надо запросить их несколько штук то обязательна последовательность их запроса во всех местах программы, иначе «deadly embrace»(обе горутины захватили по одному локу, а каждой нужно два сразу, и обе вечно ждут когда одна из них отпустит необходимый).
Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства.
Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go).
В использовании для обнаружении «data races» инструментария runtime может для кого-то отсутствует теоретическая академическая чистота реализации в языке, но если бы такая и была то для работы оно мало пригодно - слишком большой impedance mismatch между программистом и реализуемой идеей.
Исходная версия tp_for_my_bunghole, :
А теперь сравни это с JS/CPython
Там нет параллелизма. В Python только вспомогательные неявные треды используются. Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов.
Позиция разрабов Go — разделяемых данных у приложения быть не должно.
Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы. Можно передавать сами данные через каналы, или можно передавать сигнальные данные что какой-то массив теперь доступен горутине получившей сигнал через канал.
Есть статьи типа «а почему не использовать сырой Mutex? Channels are bad!». Но проблема Mutex что если надо запросить несколько штук то обязательна последовательность их запроса во всех местах программы, иначе «deadly embrace»(обе горутины захватили по одному локу, а каждой нужно два сразу, и обе вечно ждут когда одна из них отпустит необходимый).
Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства.
Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go).
В использовании для обнаружении «data races» инструментария runtime может для кого-то отсутствует теоретическая академическая чистота реализации в языке, но если бы такая и была то для работы оно мало пригодно - слишком большой impedance mismatch между программистом и реализуемой идеей.