а что вы такое считаете?

воткни в него Goshed :)

лучше кстати не втыкать, а повысить число тредов в пулле и запустить в нескольких горутинах вычисление

чтобы в пулле были свободные треды

ну то есть числа дробить надо аккуратно

дело в том, что по сравнению с event loop'ом который блокируется вычислением полностью - горутина блокирует лишь один из системных потоков, не блокируя при этом весь процесс. Однако с правильным подходом к написанию можно обойти и эту проблему просто мануально переключая горутины в алгоритме

лучше кстати не втыкать, а повысить число тредов в пулле и запустить в нескольких горутинах вычисление

или так, это надо мерить

а что вы такое считаете?

приходилось когда-то давно считать кое-какие показатели кое-каких случайных процессов траекторий случайных процессов приходилось генерировать очень много но я правда на крестах это писал

и в принципе для таких числодробилок как раз считаю кресты наилучшим вариантом

это очень, очень редкая задача

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

дело в том, что по сравнению с event loop'ом который блокируется вычислением полностью - горутина блокирует лишь один из системных потоков, не блокируя при этом весь процесс. Однако с правильным подходом к написанию можно обойти и эту проблему просто мануально переключая горутины в алгоритме

Ну так то вычисления на той же node js - это полюбому плохая идея

Ну так то вычисления на той же node js - это полюбому плохая идея

Это на основе чего был сделан такой вывод?

даже если в другие процессы выносить

Это на основе чего был сделан такой вывод?

ну не дробят на динамически типизированных языках числа

это очень, очень редкая задача

обычно да

именно у постгреса есть более эффективная конструкция, чем where id in (1,b,c,d,e...)

подскажите?) ANY?

ну не дробят на динамически типизированных языках числа

как раз на них и дробят, например на python + pandas + numpy + scipy

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

Вот тут я не согласен

с чем?

как раз на них и дробят, например на python + pandas + numpy + scipy

да, но только питон выступает в роли обвязки, сами числодробилки фактически на C/C++ написаны, либо вообще на GPU уходят

Фактически, у нас имеется два пула: один для вычислений, а второй для ввода-вывода. Динамический растет только тот, который для ввода вывода

да, но только питон выступает в роли обвязки, сами числодробилки фактически на C/C++ написаны, либо вообще на GPU уходят

Да, но ты же при этом не пишешь сишный код :)

Или фортрановский

Да, но ты же при этом не пишешь сишный код :)

это потому что его заранее написали

то есть питон фактически только дёргает, а вычисляет сишка

Это на основе чего был сделан такой вывод?

динамический язык в число-дробилках будет практически всегда медленее по причине своей динамики о чём говорят многочисленные бенчмарки включая всем известный https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html. это как в 3D графике, либо быстрая статика, либо дорогая динамика (think of lighting calculation). event loop это хорошо для I/O, но вычисления блокирующие весь event loop это вообще не гут. можно конечно разбить процесс на несколько процессов или воркеров внутри процесса, но это порадит новые проблемы такие как shared state, который придётся реализовывать через какую-то БД, либо IPC что гораздо сложнее и затратнее по производительности. У каждого языка/платформы есть свои сильные и слабые стороны. JavaScript подходит далеко не везде и бэкэнд API для продакшена на нём лучше не писать если есть выбор.

И неплохо вычисляет

и если нужно сделать что-то совсем кастомное, что не предусмотрено питоновскими либами, то тут уже питон будет больше мешать, чем помогать

и если нужно сделать что-то совсем кастомное, что не предусмотрено питоновскими либами, то тут уже питон будет больше мешать, чем помогать

Тут не поспоришь, хотя такую задачу еще придумать надо :)

динамический язык в число-дробилках будет практически всегда медленее по причине своей динамики о чём говорят многочисленные бенчмарки включая всем известный https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html. это как в 3D графике, либо быстрая статика, либо дорогая динамика (think of lighting calculation). event loop это хорошо для I/O, но вычисления блокирующие весь event loop это вообще не гут. можно конечно разбить процесс на несколько процессов или воркеров внутри процесса, но это порадит новые проблемы такие как shared state, который придётся реализовывать через какую-то БД, либо IPC что гораздо сложнее и затратнее по производительности. У каждого языка/платформы есть свои сильные и слабые стороны. JavaScript подходит далеко не везде и бэкэнд API для продакшена на нём лучше не писать если есть выбор.

Ну нода вообще была походу вытесненна Go в довольно узкую нишу (Server Side Rendering и сборка фронта).

Ну нода вообще была походу вытесненна Go в довольно узкую нишу (Server Side Rendering и сборка фронта).

да, в SSR нода неизбежна и там она как-раз занимает свою нужную нишу.

динамический язык в число-дробилках будет практически всегда медленее по причине своей динамики о чём говорят многочисленные бенчмарки включая всем известный https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-node.html. это как в 3D графике, либо быстрая статика, либо дорогая динамика (think of lighting calculation). event loop это хорошо для I/O, но вычисления блокирующие весь event loop это вообще не гут. можно конечно разбить процесс на несколько процессов или воркеров внутри процесса, но это порадит новые проблемы такие как shared state, который придётся реализовывать через какую-то БД, либо IPC что гораздо сложнее и затратнее по производительности. У каждого языка/платформы есть свои сильные и слабые стороны. JavaScript подходит далеко не везде и бэкэнд API для продакшена на нём лучше не писать если есть выбор.

V8/luajit vs go?

в системных потоках писать сложнее чем на горутинах, в этом и суть горутин. Никто не спорит что можно написать намного более оптимизированный поточный код аля Nginx на C или даже на worker'ах в JS, но сколько у тебя это займёт по времени и сколько съест нервишек? Go в этом плане почти идеален, он позволит тебе быстро написать асинхронный код в синхронном стиле, выполняя его не-блокирующе и используя все ресурсы системы, включая число-дробилки.

Не сложнее, он просто менее эффективен.

V8/luajit vs go?

хм?

Не сложнее, он просто менее эффективен.

Что не сложнее? concurrency на потоках не сложнее горутин?

Что не сложнее? concurrency на потоках не сложнее горутин?

Синхронный многопоточный код не сложнее асинхронного.

Синхронный многопоточный код не сложнее асинхронного.

сложнее, я там был, код лепил, по потокам текло в буфер не попадало. в асинхронном коде тебе нужно заботиться о том, чтобы не заблокировать event loop, там блокировать ни в коем случае нельзя! async/await значительно облегчает написание асинх кода, но тем не менее это не Go, где писать блокирующий код - норма.

хм?

Есть примеры когда v8/luajit быстрее go.

сложнее, я там был, код лепил, по потокам текло в буфер не попадало. в асинхронном коде тебе нужно заботиться о том, чтобы не заблокировать event loop, там блокировать ни в коем случае нельзя! async/await значительно облегчает написание асинх кода, но тем не менее это не Go, где писать блокирующий код - норма.

Это сложности асинхронного кода.

Есть примеры когда v8/luajit быстрее go.

может быть, но в целом производительноть и эффективность по памяти скорее за статикой чем за динамикой

Есть примеры когда v8/luajit быстрее go.

а какие собственно есть примеры?

ребят подскажите,Вопрос по gorilla, значение ключа session.Values["authenticated"] <nil> : var store = sessions.NewCookieStore(key) глобальная переменная, когда задаем session.Values["authenticated"] = true в методе, который находится в controllers.go В другом методе, который находится в middleware.go где требуется значение session.Values["authenticated"] , выдается <nil>, если название куки прописаны одинаково вывел session из session, err := store.Get(r, "session") в middleware, мэпы пустые не пойму почему не берет значение, если все они в одном пакете

сложнее, я там был, код лепил, по потокам текло в буфер не попадало. в асинхронном коде тебе нужно заботиться о том, чтобы не заблокировать event loop, там блокировать ни в коем случае нельзя! async/await значительно облегчает написание асинх кода, но тем не менее это не Go, где писать блокирующий код - норма.

не сложнее

Это сложности асинхронного кода.

а какие сопоставимые сложности синхронного кода в стиле Go?

не сложнее

сильное заявление.. правда необоснованное, но это же неважно, главное мнение иметь))

не сложнее

ну точнее чуть сложнее тем, что там надо самому пулл потоков делать

а так всё тоже самое

и причина тому меньший порог входа нежели Java, C++ и тому подобным а Go как-раз таки предоставляет для бэка совершенно новую альтернативу - с одной стороны достаточно быстрый, с другой стороны достаточно простой. Поэтому собственно PHP, Python и JS на бэкэнде теряют долю

> сложный язык Я понимаю, когда этим словосочетанием обзывают языки Java/C/C++. Но в других языках то откуда сложность?

просто менее эффективно конечно же

а так всё тоже самое

абсолютно не тоже самое. я всё уже выше описал

абсолютно не тоже самое. я всё уже выше описал

ты про асинхронный код написал

а мы про синхронный многопоточный говорим

> сложный язык Я понимаю, когда этим словосочетанием обзывают языки Java/C/C++. Но в других языках то откуда сложность?

на такой размытый вопрос могу лишь размыто ответить: у каждого языка есть свои сложности.

а какие собственно есть примеры?

Математика. Тот же pypy умеет автовекторизацию в sse, а luajit еже более продвинут в этом плане

а мы про синхронный многопоточный говорим

я говорю про синхронный не-блокирующий код в стиле Gо, а не про синхронный в стиле C/C++, это, товарищ, вещи абсолютно разные

на такой размытый вопрос могу лишь размыто ответить: у каждого языка есть свои сложности.

Тогда, видимо, программисты значительно тупее, чем я думаю.

Математика. Тот же pypy умеет автовекторизацию в sse, а luajit еже более продвинут в этом плане

я-же собственно именно об этом и говорил, что питон подходит для склеивания высокопроизводительных модулей. Где heavy-lifting делают C++ модули а питон лишь организуют между ними связь.

я говорю про синхронный не-блокирующий код в стиле Gо, а не про синхронный в стиле C/C++, это, товарищ, вещи абсолютно разные

Синхронный многопоточный код не сложнее асинхронного. Это в принципе справедливо даже если под асинхронным понимать код Go.

Синхронный многопоточный код не сложнее асинхронного. Это в принципе справедливо даже если под асинхронным понимать код Go.

Go код не асинхронен, код синхронен, а вот его выполнение - не обязательно. В этом то и прелесть написания Go кода.

Go код не асинхронен, код синхронен, а вот его выполнение - не обязательно. В этом то и прелесть написания Go кода.

И чем он проще, чем полностью синхронный код на потоках?

Синхронный многопоточный код не сложнее асинхронного. Это в принципе справедливо даже если под асинхронным понимать код Go.

да и вообще утверждение о том что синх. конкр. код настолько-же "прост" как async в корне неверно если учитывать shared state. mutable shared state это мать всех сложных багов и в многопоточном программирование она доминирует. в async коде нет конкурентности, там в принципе нет такого понятия как concurrency primitives, locks, data races (правда race conditions могут быть)

да и вообще утверждение о том что синх. конкр. код настолько-же "прост" как async в корне неверно если учитывать shared state. mutable shared state это мать всех сложных багов и в многопоточном программирование она доминирует. в async коде нет конкурентности, там в принципе нет такого понятия как concurrency primitives, locks, data races (правда race conditions могут быть)

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

Коллеги, кто использует/натыкался на инсталлер (bash/py), который понимает, какие GOOS and GOARCH на клиентской системе и качает соответсвтующий бинарь из S3/etc?

я писал многопоточный C/C++: - mutable shared state. - thread'ы дорогие, с ними надо аккуратно. + очень гибкая модель и очень производительная, в умелых руках. я писал асинхронный JS: + event loop безопаснее в плане конкурентности, никаких data race'ов, мутексов и т.д. + I/O не блокирует - блокировать нельзя (!) - асинх конструкции кода без async/await это ад - логика однопоточна по умолчанию и сейчас я пишу на Go: - mutable shared state, однако каналы порой спасают + блокировать можно, никакой асинхронщины в коде + неблокирующее многопоточное исполнение по умолчанию + горутины очень дешёвые, любое конкр. задание можно запустить в своём "потоке" и для web'а (и возможно даже application development'а) гошная модель конкурентности подходит лучше всего. Она достаточно мощная и при этом более простая.

кто чем визуализирует zipkin dependencies? встроенного уже не хватает

подскажите?) ANY?

https://stackoverflow.com/questions/20271123/how-to-execute-an-in-lookup-in-sql-using-golang, второй ответ (который с It looks like you may be using the pq driver. начинается)

я-же собственно именно об этом и говорил, что питон подходит для склеивания высокопроизводительных модулей. Где heavy-lifting делают C++ модули а питон лишь организуют между ними связь.

Я про конкретно код на python/lua.

ERROR: S client not available

я писал многопоточный C/C++: - mutable shared state. - thread'ы дорогие, с ними надо аккуратно. + очень гибкая модель и очень производительная, в умелых руках. я писал асинхронный JS: + event loop безопаснее в плане конкурентности, никаких data race'ов, мутексов и т.д. + I/O не блокирует - блокировать нельзя (!) - асинх конструкции кода без async/await это ад - логика однопоточна по умолчанию и сейчас я пишу на Go: - mutable shared state, однако каналы порой спасают + блокировать можно, никакой асинхронщины в коде + неблокирующее многопоточное исполнение по умолчанию + горутины очень дешёвые, любое конкр. задание можно запустить в своём "потоке" и для web'а (и возможно даже application development'а) гошная модель конкурентности подходит лучше всего. Она достаточно мощная и при этом более простая.

В хаскеле получше таки модель.

коллеги, а о чем вы трете?

коллеги, а о чем вы трете?

поясняю людям сильные и слабые стороны Go)

поясняю людям сильные и слабые стороны Go)

ты наш герой?

ты наш герой?

вам решать, не мне))

я писал многопоточный C/C++: - mutable shared state. - thread'ы дорогие, с ними надо аккуратно. + очень гибкая модель и очень производительная, в умелых руках. я писал асинхронный JS: + event loop безопаснее в плане конкурентности, никаких data race'ов, мутексов и т.д. + I/O не блокирует - блокировать нельзя (!) - асинх конструкции кода без async/await это ад - логика однопоточна по умолчанию и сейчас я пишу на Go: - mutable shared state, однако каналы порой спасают + блокировать можно, никакой асинхронщины в коде + неблокирующее многопоточное исполнение по умолчанию + горутины очень дешёвые, любое конкр. задание можно запустить в своём "потоке" и для web'а (и возможно даже application development'а) гошная модель конкурентности подходит лучше всего. Она достаточно мощная и при этом более простая.

mutable shared state и в го можно спокойно организовать асинхронный JS однопоточен, но это скорее исключение из правил, чем правило, ибо есть языки, которые и в async/await могут и в потоки (Python, C#, C++20) Так что на самом деле основная киллерфича Go - это лёгкие горутины и отсутствие необходимости явно работать с тред пуллом.

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

коллеги, а о чем вы трете?

У меня простой поинт: пока в го нет автовекторизации любой язык что её умеет будет быстрее

В хаскеле получше таки модель.

хорошо иметь мнение, но ещё лучше иметь это мнение обосновать)

быстрее в чем?

быстрее в чем?

В математике

возможно

можно взять конкретную задачу, и померять

хорошо иметь мнение, но ещё лучше иметь это мнение обосновать)

Всё то же самое, но STM, вместо мьютексов и каналов.

В многопоточном приложении главное свести взаимодействие между потоками к минимуму, если это сделано, то все равно, на чем построено взаимодействие между ними, на каналах, на мьютексах или на IPC.

mutable shared state и в го можно спокойно организовать асинхронный JS однопоточен, но это скорее исключение из правил, чем правило, ибо есть языки, которые и в async/await могут и в потоки (Python, C#, C++20) Так что на самом деле основная киллерфича Go - это лёгкие горутины и отсутствие необходимости явно работать с тред пуллом.

а я разве утверждал что в Go shared state невозможен? вы читали сообщение?))) потоки в event loop'е не имеют возможности делить память, я уже повторяюсь.

В многопоточном приложении главное свести взаимодействие между потоками к минимуму, если это сделано, то все равно, на чем построено взаимодействие между ними, на каналах, на мьютексах или на IPC.

Вот да. Любое взаимодействие убивает производительность

Такой вопрос, какой идешкой пользуетесь?

Всё то же самое, но STM, вместо мьютексов и каналов.

shared mutable state без мьютексов говорите? что-то я вам не верю, коллега

а я разве утверждал что в Go shared state невозможен? вы читали сообщение?))) потоки в event loop'е не имеют возможности делить память, я уже повторяюсь.

Потоки с event loop вполне имеют возможность делить память. И я сейчас не про JS.

Такой вопрос, какой идешкой пользуетесь?

VSC

я говорю про синхронный не-блокирующий код в стиле Gо, а не про синхронный в стиле C/C++, это, товарищ, вещи абсолютно разные

См libdill

Вот да. Любое взаимодействие убивает производительность

порой оно необходимо

VSC

Там плагин нужен какой-то?

Там плагин нужен какой-то?

https://code.visualstudio.com/docs/languages/go

И вообще я всё веду к тому, что обычный многопоточный код не сильно сложнее кода на Го, он просто гораздо менее эффективный при нагрузках, только и всего.

https://code.visualstudio.com/docs/languages/go

благодарю

И вообще я всё веду к тому, что обычный многопоточный код не сильно сложнее кода на Го, он просто гораздо менее эффективный при нагрузках, только и всего.

Настолько, что лучше его не писать

shared mutable state без мьютексов говорите? что-то я вам не верю, коллега

Вообще есть даже класс lock free алгоритмов.

И вообще я всё веду к тому, что обычный многопоточный код не сильно сложнее кода на Го, он просто гораздо менее эффективный при нагрузках, только и всего.

что?!))) обычный многопоток на C++/Rust/Java может быть гораздо эффективнее Goroutine. Но писать его будет гораздо сложнее)) вы думаете green thread'ы зря чтоль придумали, если на простых потоках и без того легко писать?)))

что?!))) обычный многопоток на C++/Rust/Java может быть гораздо эффективнее Goroutine. Но писать его будет гораздо сложнее)) вы думаете green thread'ы зря чтоль придумали, если на простых потоках и без того легко писать?)))

Ещё раз напоминаю про libdill

что?!))) обычный многопоток на C++/Rust/Java может быть гораздо эффективнее Goroutine. Но писать его будет гораздо сложнее)) вы думаете green thread'ы зря чтоль придумали, если на простых потоках и без того легко писать?)))

Я ещё раз повторяю. Можно спокойно написать многопоточный код, который будет практически совпадать с кодом на Го, просто он будет куда менее эффективным, потому что вместо горутин там будут обычные потоки.