Исправление byko3y, (текущая версия) :
А теперь сравни это с JS/CPython
Там нет параллелизма. В Python только вспомогательные неявные треды используются
Асинхронщина на других языках и вовсе с явными функциями обратного вызова применяется, так что не питоном одним.
Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов
У меня весьма странное смешанное впечатление производит этот Роб Пайк. С одной стороны, чел вроде двигает новые технологии, с другой стороны, эти технологии такие упоротые, что я даже не знаю, как к ним относиться. Предком Go является Limbo, а предком Limbo является Alef. Однако, Alef написан ни разу не Пайком.
В итоге получается, что Пайк как бы «донашивает» новые технологии. Можно аппелировать к тому, что только так получится (и таки получилось) ввести в индустрию новую технологию. Например, у тебя не получится сделать ОС для многопоточного кода, пока в твоей ОС есть сигналы, форк, сплошные синхронные функции в API, и некооперирующийся планировщик. А это и есть краткая характеристика POSIX. На линуксе новый API нарастает отдельно, но необходимость поддерживать совместимость с POSIX очень тяготит разработку софта, причем, как самого ядра, так и юзерспейса, дергающего системные вызовы.
Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы
Данные могут существовать в каждый момент врекмени только с одной стороны канала. Потому они никогда не разделяются. Да, можно передавать ссылку, но, опять же, позиция разрабов: обращаться по этой ссылке в каждый момент времени можно только с одной стороны.
Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства
Java. Которую он, по сути, и заменяет. По крайней мере последних версий, с лямбдами и локальным выводом типов.
Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go)
Если бы решение проблем гонок было бы таким простым, то я бы первым побежал пользоваться Go. Но, к сожалению, опция "-race" — это простой ThreadSanitizer, который имеет какой-то шанс словить параллельный доступ во время выполнения, но только если этот шанс будет достаточно большим и если сами дополнительные инструкции не изменят выполнение так, что гонки перестанут случаться. То есть, оно помогает хотя бы увидеть, что ошибка произошла, потому что гонка сама по себе не выдает никакой ошибки, в отличие от какого-нибудь segmentation fault.
Исходная версия byko3y, :
А теперь сравни это с JS/CPython
Там нет параллелизма. В Python только вспомогательные неявные треды используются
Асинхронщина на других языках и вовсе с явными функциями обратного вызова применяется, так что не питоном одним.
Вообще Go по идее универсальный, но Rob Pike(или кто другой) должен был найти лазейку популяризовать язык(идеи ещё со времён ОС Plan9), потому одним рассказывали что это именно для серверов
У меня весьма странное смешанное впечатление производит этот Роб Пайк. С одной стороны, чел вроде двигает новые технологии, с другой стороны, эти технологии такие упоротые, что я даже не знаю, как к ним относиться. Предком Go является Limbo, а предком Limbo является Alef. Однако, Alef написан ни разу не Пайком.
В итоге получается, что Пайк как бы «донашивает» новые технологии. Можно аппелировать к тому, только так получится (и таки получилось) ввести в индустрию новую технологию. Например, у тебя не получится сделать ОС для многопоточного кода, пока в твоей ОС есть сигналы, форк, сплошные синхронные функции в API, и некооперирующийся планировщик. А это и есть краткая характеристика POSIX. На линуксе новый API нарастает отдельно, но необходимость поддерживать совместимость с POSIX очень тяготит разработку софта, причем, как самого ядра, так и юзерспейса, дергающего системные вызовы.
Не такая позиция у разрабов Go. Они советуют разделять данные с помощью сообщений через каналы
Данные могут существовать в каждый момент врекмени только с одной стороны канала. Потому они никогда не разделяются. Да, можно передавать ссылку, но, опять же, позиция разрабов: обращаться по этой ссылке в каждый момент времени можно только с одной стороны.
Простота языка нужна для аудита кода. Ни один другой язык не предоставляет такие удобства
Java. Которую он, по сути, и заменяет. По крайней мере последних версий, с лямбдами и локальным выводом типов.
Но если надо разделение данных, то пожалуйста. Есть опция -race которая покажет все data race в коде который вызывается. Стандартный инструмент. Для этого нужен полный test coverage(что удобно в Go)
Если бы решение проблем гонок было бы таким простым, то я бы первым побежал пользоваться Go. Но, к сожалению, опция "-race" — это простой ThreadSanitizer, который имеет какой-то шанс словить параллельный доступ во время выполнения, но только если этот шанс будет достаточно большим и если сами дополнительные инструкции не изменят выполнение так, что гонки перестанут случаться. То есть, оно помогает хотя бы увидеть, что ошибка произошла, потому что гонка сама по себе не выдает никакой ошибки, в отличие от какого-нибудь segmentation fault.