Смотрите. Есть xml: <root> <block> <items> <item>1</item> <item>2</item> </items> </block> <block> .... Можно для стандартного декодера сделать структуру, чтобы он пропускал вот этот сраный 'items'?

type Root struct { /// ... Block []string `xml:"Items>item"` } ?

type Root struct { /// ... Block []string `xml:"Items>item"` } ?

Точно. Спасибо. Я тупой. Это прямо вот написано же

https://azul3d.org/doc/faq.html#what-about-the-garbage-collector однако я до сих пор сомневаюсь что рендерить в Go это хорошая идея… скриптинг игры как они это описывают - да, могу себе представить, а вот рендеринг..

Всем привет! Админы, привет! Разрешите мне запостить одну вакансию?

можно, если с вилкой

Напоминаю: вилка — это от и до)

Хорошо) Вилка: 130 000 -180 000 на руки Территориально: #Москва м.Курская В компании есть две команды разработки на Go: одна занимается видео, другая - разработкой бизнес-логики. Вакансия открыта во второй команде. Про возможности: - участие в принятии архитектурных решений платформы - минимум бюрократии (уважаем трудовой кодекс, но сотрудник не должен страдать) - удобный рабочий график (к планеркам можно подключаться по скайпу, приезжать в офис не в часы пик, брать дни на удаленке и т.д) Про задачи: - Разрабатывать новый и поддерживать существующий микросервисный функционал серверной части, - Проектировать и реализовывать API для клиентских устройств и партнерских систем, - Разрабатывать инструменты управления и мониторинга платформы, сбора и анализа статистики, - Анализировать и оптимизировать производительность web-сервисов платформы, - Писать модульные, функциональные и интеграционные тесты. Мы ищем человека с - опытом коммерческой backend-разработки на Go или Python. - пониманиeм принципов конкурентного программирования, - уверенным знанием сетевых протоколов и HTTP транспорта, - пониманием принципов построения высоконагруженных систем. Будет здорово, если у вас уже есть навыки работы на nix-системах и вы легко разбираетесь в чужом коде. Почему пишу про python? Потому что готовы рассматривать Python разработчиков, которые хоть немного потрогали Go и хотят в него уйти.

А почему именно с питона на го? А не с рубинов на рельсах ?

А почему именно с питона на го? А не с рубинов на рельсах ?

Потому что го ближе к python

А почему именно с питона на го? А не с рубинов на рельсах ?

Вот затрудняюсь ответить, но, наверное, правда питон ближе, чем руби

Потому что го ближе к python

Сильное утверждение.

не проверяй.

Сильное утверждение.

что смущает?

руби со своим синтаксисом вообще живет в параллельной реальности

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

руби со своим синтаксисом вообще живет в параллельной реальности

помирающей параллельной реальности*

помирающей параллельной реальности*

Есть мнение, что рор все ещё популярнее го

помирающей параллельной реальности*

язык, главной парадигмой которого было monkey patching всего и вся вообще не должен был существовать в какой либо вселенной

Есть мнение, что рор все ещё популярнее го

Хотя я не очень в это верю

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

абсолютно неверно. У Go и C очень мало общего, а синтаксис он в любом языке хоть чуток да от C наследует

абсолютно неверно. У Go и C очень мало общего, а синтаксис он в любом языке хоть чуток да от C наследует

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

Ближе к c

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

А бмв ближе к фольксвагену или мерседесу?

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

считай: GC vs no-GC Runtime (built-in) vs no-Runtime Goroutines vs Threads OOP vs no-OOP sync vs async programming разницы между Go и C - просто коллосальны.

ок, по каким критериям вы оцениваете, что питон ближе к го, чем си?

Python ближе тем, что он "kinda GC" + runtime + OOP

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

но это такой, очень банальный и поверхностный анализ. Более глубокие анализов на 99.8% уверен в сети придостаточно

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

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

asyncio достаточно производительный, чтобы продолжать использовать питон в том же вебе, особенно там, где много бизнес логики

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

number crunching. вычисления. обработки большого колва одновременных клиентов. рендеринг... что угодно... для всего этого он вообще не годится

а, ну для числодробилок он не очень подходит, если не брать во внимание numpy

для всего остального - вполне

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

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

asyncio достаточно производительный, чтобы продолжать использовать питон в том же вебе, особенно там, где много бизнес логики

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

с Go же у нас большое преимущество в том, что горутины не event loop, заблокировав горутину мы блокируем лишь 1 системный поток вычислением, все остальные продолжают работу.

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

таки, в названии asyncio заложена суть библиотеки, она не для вычислений :)

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

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

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

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

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

однако Python я бы только для таких вещей как ML рассматривал бы когда нужно быстро склеить высокопроизводительные модули написанные на C++ в небольшую, экспрессивную логику. Я бы даже сказал что из-за его экспрессивности он в плане скриптинга лучше Go но он абсолютно не годится для всего остального учитывая его энерго-эффективность. На нём можно писать скрипты, но не алгоритмы и системы, он для этого слишком медленный и прожорливый.

Такое ощущение, что в мире пишут или хайлоад или ML.

таки, в названии asyncio заложена суть библиотеки, она не для вычислений :)

поэтому я и уточняю, что до поры до времени Python/JavaScript могут держать нагрузку, но как только софт растёт и требует чуть большей логики - она сразу начинает перевешивать преимущества event loop'а по I/O и дико тормозить не используя потенциал многоядерного железа

Зачем на ноде бэкенд писать?

с Go же у нас большое преимущество в том, что горутины не event loop, заблокировав горутину мы блокируем лишь 1 системный поток вычислением, все остальные продолжают работу.

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

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

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

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

он неограниченно расширяется?

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

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

мне лично проще для ML завести 20 интрпретаторов петона, которые к одной и тойже базе конектяца и выполняют один и тот же скрипт. Чем манаться с С++/java или с маргинальными биндингами на Go

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

плюс не забывай что Node.js воркеры это таки не потоки. Это воркеры. Разница в том, что они не делят меж собой память, что значительно ограничивает их возможности. Или я не прав про shared mem?

Зачем на ноде бэкенд писать?

чтобы не учить Go? ?

он неограниченно расширяется?

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

плюс не забывай что Node.js воркеры это таки не потоки. Это воркеры. Разница в том, что они не делят меж собой память, что значительно ограничивает их возможности. Или я не прав про shared mem?

я вот не проверял точно, но мне кажется, что память там можно расшарить через специальные объекты

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

где вы тут херню увидели? я задал вполне нормальный вопрос о том как устроен тредпулл в го, потому что такие детали мне незнакомы

задайте этот вопрос гуглу, пожалуйста

вот придётся

мне лично проще для ML завести 20 интрпретаторов петона, которые к одной и тойже базе конектяца и выполняют один и тот же скрипт. Чем манаться с С++/java или с маргинальными биндингами на Go

я собственно об этом и говорил. Это прекрасный скриптовой язык, медленный, прожорливый но экспрессивный, поэтому он не про systems/backend programming

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

у меня с webwire такая херня на винде происходит. Либо винда херня полная в плане TCP/IP, либо Go не очень оптимизирован на windows networking API (что вполне логично и можно бы было понять) https://github.com/qbeon/webwire-go/issues/17

я собственно об этом и говорил. Это прекрасный скриптовой язык, медленный, прожорливый но экспрессивный, поэтому он не про systems/backend programming

Тем не менее, тонна бэкенда на пайтоне пишется. Возможно, всё не так уж и плохо :)

у меня с webwire такая херня на винде происходит. Либо винда херня полная в плане TCP/IP, либо Go не очень оптимизирован на windows networking API (что вполне логично и можно бы было понять) https://github.com/qbeon/webwire-go/issues/17

я думаю, что происходит какая-то другая херня. а чт там на винде в качестве eventpoll? не select же?

я вот не проверял точно, но мне кажется, что память там можно расшарить через специальные объекты

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

товарищи, кто go-pg юзает? как в нём правильно WhereIn использовать со слайсом интов?

я думаю, что происходит какая-то другая херня. а чт там на винде в качестве eventpoll? не select же?

WaitForMultiplyObjects

ERROR: S client not available

то же самое

Тем не менее, тонна бэкенда на пайтоне пишется. Возможно, всё не так уж и плохо :)

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

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

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

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

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

о чём Rob Pike собственно и говорил в 2015 на конференции, что многие ЯП напрасно стремятся к господству во всех сферах деятельности и что Go это нишевой ЯП by-design.

asyncio достаточно производительный, чтобы продолжать использовать питон в том же вебе, особенно там, где много бизнес логики

Nyet. asyncio - вообще большая ошибка

товарищи, кто go-pg юзает? как в нём правильно WhereIn использовать со слайсом интов?

pg.In() использовать, WHERE id IN(?)" , pg.In([]int{1,2})

Nyet. asyncio - вообще большая ошибка

почему?

с Python та-же проблема что и с Node.js JavaScript. Да, нода сама по себе быстрая и с I/O справляется отлично поскольку построена на libuv (C++) event loop'е и V8 JS engine (достаточно мощный движок) Но проблемы возникают тогда, когда нам помимо I/O нужны вычисления. Какой-нибудь поиск по древу или фильтрация массива могут заблокировать event loop и всё нахрен встанет. JavaScript сам по себе не столь быстрый как Go даже с V8, но если ты ещё и блокируешь вычислением event loop то всё, ты проиграл.

libuv написан на Си, плюсов в нем нет

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

коллега, давайте без херни, а? вы не знали, что он расширяемый - ок, теперь знаете. а болтать на тему "что будет, если я все же смогу вызвать одновременно более 10К сисколов, которые заблочат треды" я не хочу и вам не советую

А можно рассказать про расширяемость?

pg.In() использовать, WHERE id IN(?)" , pg.In([]int{1,2})

да вот хрен код: if err = db.DB.Model(&vlansArr).WhereIn(`id IN (?)`, pg.In(vlanIDs)).Select(); err != nil { ошибка: ОШИБКА #22P02 неверное значение для целого числа: "{}" лог pg: FROM vlans AS "vlan" WHERE (id IN ('{}')) переменная точно не пустая: vlanIDS: []int64{0, 0, 0, 20633, 20640, 20603}

libuv написан на Си, плюсов в нем нет

кстати да, ошибочка

А можно рассказать про расширяемость?

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

да вот хрен код: if err = db.DB.Model(&vlansArr).WhereIn(`id IN (?)`, pg.In(vlanIDs)).Select(); err != nil { ошибка: ОШИБКА #22P02 неверное значение для целого числа: "{}" лог pg: FROM vlans AS "vlan" WHERE (id IN ('{}')) переменная точно не пустая: vlanIDS: []int64{0, 0, 0, 20633, 20640, 20603}

https://godoc.org/github.com/go-pg/pg var books []Book err := db.Model(&books).WhereIn("id IN (?)", 1, 2).Select() if err != nil { panic(err) }

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

откуда я об этом знаю? по-моему, из исходного кода рантайма

https://godoc.org/github.com/go-pg/pg var books []Book err := db.Model(&books).WhereIn("id IN (?)", 1, 2).Select() if err != nil { panic(err) }

да, но у меня слайс )

значит не юзай WhereIn, юзай плейсхолдер и то что я писал выше

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

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

нет, конечно

это же не блокировка

тред работает

значит не юзай WhereIn, юзай плейсхолдер и то что я писал выше

пичаль

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

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

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

не думаю. мне это удалось один раз за 4 года

собственно если будет часто вызывать, то это уже будет довольно плохой дробилкой

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

Это всё понятно. Интересные случаи когда бесконечный цикл

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