Здравствуйте, Cyberax, Вы писали:
C>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.
Писать надежные сетевые приложения позволяет дохрена чего. А вот использовать мартышек в разработке, при этом получая что-то полезное, раньше ничего кроме PHP не позволяло. А теперь есть Go
Здравствуйте, Тёмчик, Вы писали:
KP>>Смешная темя, спасибо! KP>>Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.
Тё>Плохому танцору ... мешают
Здравствуйте, C0x, Вы писали:
C0x>А уж если там люди выбирают Си# и Java то видимо все не так страшно
Совершенно не страшно со стороны биржи/matching engine, собственно там Java в полный рост со всеми вытекающими. Те же кто торгуют, и кому важна latency, в большинстве своём используют C++, ибо время — деньги
Здравствуйте, kaa.python, Вы писали:
KP>>>Квалификация Гошников и правда ниже плинтуса, но там и уровня мартышки хватает.
Тё>>Плохому танцору ... мешают
KP>Ты довольно верно причины создания Go описал
Веб на плюсах не взлетел. Значит, танцорам плюсникам мешали яйца? Бигдата пошла с жавы и потом в питон и js. Кто мешал плюсникам идти в бигдату? Теперь go стремится вытеснить питон из скриптов и жаву из микросервисов. С сферой применения C++ он не пересекается, хоть и декларируется "скорость компилируемого языка".
Так почему у тебя претензии к go?
Здравствуйте, kaa.python, Вы писали:
C>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен. KP>Писать надежные сетевые приложения позволяет дохрена чего.
На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.
Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.
KP>А вот использовать мартышек в разработке, при этом получая что-то полезное, раньше ничего кроме PHP не позволяло. А теперь есть Go
Писать код на Go ничуть не проще, чем на других языках.
Здравствуйте, Cyberax, Вы писали:
C>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.
Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное.
C>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное.
Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
C>Писать код на Go ничуть не проще, чем на других языках.
Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
Здравствуйте, Cyberax, Вы писали:
C>>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен. KP>>Писать надежные сетевые приложения позволяет дохрена чего. C>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек.
Плюс, даже без этой возможности — не забываем про резервирование адресного пространства/overcommit — по сути то же расширение по требованию.
C>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки
На Boost.Coroutine сотни тысяч запускаются без проблем
Здравствуйте, kaa.python, Вы писали:
C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек. KP>Да, этого нет.
Нет, это есть.
C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное. KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
Достаточно посмотреть на код Asio с корутинами и без них, вопросы об их удобстве и необходимости сразу отпадут
Именно поэтому автор Boost.Asio добавил в Asio реализацию stackless корутин. Именно поэтому как только появилась Boost.Coroutine в Asio добавили соответствующую обвязку.
Именно поэтому автор Asio является автором нескольких предложений в стандарт по корутинам.
Именно из-за громоздкости асинхронного кода автор Asio показывает в своих презентациях как его упрощать, и проще всего выглядит решение на корутинах (будь то stackless или stackful).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек. EP>Есть сегментированые стэки.
В Golang от них отказались из-за неустранимых проблем с производительностью, если из-за невезения горячая функция попадает как раз на границу сегментов.
EP>Плюс, даже без этой возможности — не забываем про резервирование адресного пространства/overcommit — по сути то же расширение по требованию.
Игры с защитой памяти — достаточно дорогое и сомнительное удовольствие. На 10 тысячах потоков семафор mmap/mprotect в ядре будет раскалён до температуры термоядерного синтеза.
C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки EP>На Boost.Coroutine сотни тысяч запускаются без проблем
, причём на древнем ноутбуке, и это без segmented stack
Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, reversecode, Вы писали:
R>>какая разница как он планируется если я говорю об имплементации переключения стека на асме C>А что, как-то можно по-другому переключать?
написать кода по переключению можно по разному, да
можно на 2 строки можно на 22, можно на 2222 в периоде
но суть не в этом
R>>хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое C>Такие библиотеки были ещё так года с 89-го.
вот именно были, так зачем же гугл изобрел велосипед в виде другого языка ?
R>>впрочем я уже раскрыл коварный замысел гугла по созданию языка гоу что бы создать рабочие места бездомным бродягам как минимум в сша C>Хватит бредить, а?
C>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен.
их и на С++ можно писать, а то что изобрел гугл это спрятал корутины под капот рантайма гоу
зачем это было делать ? ответ более чем очевиден
в сша не достаток программистов, стартапы ростут как грибы в сезон, тянуть программистов из за океяна долго и дорого
а здесь под боком очень много бездомных и просто дураков которых нужно-можно чем то занять
учить их С++ дорого и не каждому это дается
что делать ? дать им язык которым можно так же говнокодить как и на ява скриптах или пижке
и уровень вхождения в который был бы минимален
получите гоу
Здравствуйте, kaa.python, Вы писали:
C>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек. KP>Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное.
На Go оно практически бесплатное — стек в любой момент легко можно переместить за счёт того, что GC отслеживает все указатели на нём. Так что горутина может начать со стеком всего в килобайт.
C>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное. KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
Ну так можно и на ходулях ходить, столетиями шуты так делают. Речь идёт о том, что Go это делает простым и обыденным.
Ещё из плюсов Go — скорость компиляции. Boost.Asio компилируется ну, так скажем, неторопливо. Go позволяет просто писать "go run ..." и оно менее чем за секунду компилирует и запускает приложение.
C>>Писать код на Go ничуть не проще, чем на других языках. KP>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
И при это Go-шники делают такой же качественный код.
C>>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки EP>>На Boost.Coroutine сотни тысяч запускаются без проблем
, причём на древнем ноутбуке, и это без segmented stack C>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит.
в гоу какие то особенные корутины ? они используют какие то особенные инструкции цпу ?
да нет же, все тоже что делается на С++ с корутинами сделано и в гоу, только спрятано в рантайме
кстати там же в proc.go и ссылка на архитектуру где по ссылке расписаны и ограничения этой архитектуры корутин
глобальный мютекс на список корутин
Здравствуйте, reversecode, Вы писали:
C>>Если взять более реалистичный размер в 64Кб, то получим 6.5Гб только на стеки при 100000 потоков. Нет, оно будет работать, с этим никто не спорит. R>в гоу какие то особенные корутины ?
Да. Так как язык имеет точный GC, то горутины начинаются с небольшого размера. При необходимости стек копируется в больший блок, при этом все указатели автоматически корректируются.
В С++ такое просто невозможно.
R>кстати там же в proc.go и ссылка на архитектуру где по ссылке расписаны и ограничения этой архитектуры корутин R>глобальный мютекс на список корутин
Нет. Корутины находятся в P-local (процессорно-локальном) списке, мьютекс блокируется при создании системных потоков. В результате, планировщик при отдаче управления может обычно просто взять очередную сопрограмму из своего списка. Межпоточные блокировки нужны для work stealing — если у процессора нет своих задач, то он пытается их украсть от других процессоров.
В кратце, оно берёт инициализированную пустую структуру из локального списка (gfget#L3407), без всяких блокировок. Если локальный список пустой, то он пополняется из глобального (под блокировкой этого списка).
Затем в структуре горутины инициализируется область данных под стек, в него копируются аргументы начальной функции, и указатель стека в описании горутины ставится в начало запускаемой функции.
После всего этого, горутина добавляется в локальный runqueue (см. runqput#L4799), она lock-free. Затем управление передаётся обратно в вызвавшую функцию, которая продолжит себе работать.
Здравствуйте, kaa.python, Вы писали:
KP>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым
Десетилетия назад машины были одноядерными. Со временем ситуация начала меняться и появились многоядерные машины, на которых удобно стало гонять параллельные задачи.
Поэтому языки эволюционируют в соотвествии с требованиями железа.
KP>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым.
Ну естественно на порядок ниже, т.к. в Го есть сборщик муссора, а в Си++ его нет. Поэтому 80% вопросов касательно управления паматью отпадает за ненадобностью.
Только вот я не понимаю в чем тут минус Го. В сборщике муссора?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kaa.python, Вы писали:
C>>>На С++ это однозначно очень сложно. Некоторые примитивы в С++ в принципе отсутствуют, такие как расширяемый стек. KP>>Да, этого нет. Но оно надо ли? И оно, опять таки, не бесплатное. C>На Go оно практически бесплатное — стек в любой момент легко можно переместить за счёт того, что GC отслеживает все указатели на нём. Так что горутина может начать со стеком всего в килобайт.
корутина тоже может в С++ начать с любым стеком
C>>>Так что на Go легко можно запустить пару десятков тысяч горутин. А на С++ в boost::coroutine только стеки потоков съедят пол-оперативки, так что нужно будет мастерить безстековые генераторы или что-то подобное. KP>>Необходимость корутин ну очень сильно притянута за уши. Те же ASIO, ACE и прочие сетевые штуки отлично обходились без корутин десятилетия, а тут, вдруг, они стали чем-то необходимым C>Ну так можно и на ходулях ходить, столетиями шуты так делают. Речь идёт о том, что Go это делает простым и обыденным.
C>Ещё из плюсов Go — скорость компиляции. Boost.Asio компилируется ну, так скажем, неторопливо. Go позволяет просто писать "go run ..." и оно менее чем за секунду компилирует и запускает приложение.
если буст собрать динамически или архивной либой будет тоже самое
но многие любят компилять все с нуля
C>>>Писать код на Go ничуть не проще, чем на других языках. KP>>Из личного опыта последних 2-х лет: разы проще и требования к разработчикам на Go на порядок ниже чем к плюсовым. C>И при это Go-шники делают такой же качественный код.
код такой не благодаря гошникам а благодаря типизированному языку гоу
Здравствуйте, reversecode, Вы писали:
R>>>хотя гугл вместо этого мог просто написать библиотеку для С++ и получить тоже самое C>>Такие библиотеки были ещё так года с 89-го. R>вот именно были, так зачем же гугл изобрел велосипед в виде другого языка ?
Потому, что все эти библиотеки сложно использовать — кроме горутин ещё нужны каналы и полноценный планировщик. Это всё вполне возможно на С++, хотя каналы будет немного сложно сделать без полноценного GC.
Но при этом весь код на С++ должен писаться в стиле этой библиотеки, которая (в частности) заменит весь IO и будет требовать особых обёрток для вызова внешних функций.
Так что тут получается вопрос — нафиг вообще тогда С++ сдался?
C>>Golang позволяет писать надёжные сетевые и системные приложения. При этом сам язык, по сути, является практически самым минимальным языком, который только практичен. R>их и на С++ можно писать, а то что изобрел гугл это спрятал корутины под капот рантайма гоу
Ещё каналы и планирование. Ну и полноценный точный GC. И полноценную модульность. И компиляцию со скоростью миллионов строк в секунду.
А так да, ничего нового.
R>что делать ? дать им язык которым можно так же говнокодить как и на ява скриптах или пижке R>и уровень вхождения в который был бы минимален
Если вы говнокодите на С++, то не надо проецировать свои недостатки на других.
C0x>>Только вот я не понимаю в чем тут минус Го. В сборщике муссора?
R>в создании не нужной сущности (самого языка) порог входа в который ниже плинтуса
Погоди. Непойму никак твое возмущение с чем связано, с тем что теперь легко и просто писать сетевые приложения и так же легко и просто работать с байтовыми блоками данных и поэтому теперь станет выше конкуренция на рынке труда? Или всетаки язык дерьмо?
