Всем привет. Я тут решил вкатиться в го с питона и у меня есть вопрос. Например в питоне, если я написал бекенд, затем хочу задеплоить его на сервак, на котором есть 4 ядра. Чтобы задействовать все 4 ядра, я подниму какой-нибудь uwsgi перед nginx. А как быть в GO? Он автоматически распределяет нагрузку или можно ограничить как-то?

привет ребят в mgo, как понял, в collection.update(select, update) все документы найденные через select, полностью перезаписываются на параметры update так, что не остаётся других кей:валуе, кроме тех, что в update. Тогда получается, что если я хочу чтобы в моей выборке менялись только указанные параметры, а остальные не трогались, мне надо получить выборку и вручную сохранять каждый измененный мной документ через collection.UpdateId?

Если нужно обновить часть записи используйте $set, посмотрите доки монги по этому слову

просчитывает большой алгоритм

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

Так это через mgo надо сделать. Типо UpdateId(id, bson.M{$set: ...})

а что это за диаграмма выше? O_o

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

вот я фигею сейчас дорогая редакция откуда взялось это абсурдное мнение, что Го как язык в силу каких-то особенностей хуже для десктопа чем низкоуровневая сишечка, монструозный сипипи и сверхдебилный js?

Еще я видел интересную идею (https://github.com/zserge/webview) но там есть небольшой косяк с биндингом функций

В gui строительстве широко распростронено наследование с виртуальными методами. И в Го его наиболее геморно реализовывать.

вот я фигею сейчас дорогая редакция откуда взялось это абсурдное мнение, что Го как язык в силу каких-то особенностей хуже для десктопа чем низкоуровневая сишечка, монструозный сипипи и сверхдебилный js?

интерфейсы в Го? не, не слышал...

Они не дают наследование с виртуальными методами. Они дают только полиморфизм.

Кроме того, биндитьсяс существующими gui фреймворками тоже геморнее, чем в остальных языках.

внезапно наследование с виртуальными методами - это и есть динамический полиморфизм. если вы думаете, что это критически важно для ui, советую поизучать реакт и tEA

биндится и не надо

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

внезапно наследование с виртуальными методами - это и есть динамический полиморфизм. если вы думаете, что это критически важно для ui, советую поизучать реакт и tEA

кросплатформенный десктоп - это только лишь исключительно Qt, gtk - отстой и только под линупсЫ. Если нужно в Qt, то Го конечно не подойдёт. Но вообще-то на Qt по разным причинам не так много десктопного софта в проц. отношении. Есть сегменты, в которых кросплатформенность на десктопе на фиг не нужна, как и UX, как и дизнайн и прочее гейство.

Как используются кавычки `` в го? Можно ли их просто для строки использовать?

радост в том, что внутри `` можно использоать "

Наследование с виртуальными методами - это динамический полиморфизм ПЛЮС переиспользование кода. И оно хорошо ложится на паттерны рисования контролов и реакции на системные события. Чтобы сделать этот "ПЛЮС" в гошечке внезапно нужно делать статические функции, принимающие на вход интерфейсы. И это тупо не привычно тем, кто уже набил руку на создании и поддержке нативных GUI фреймворков. Для этого нужно менять привычки, и проектировать код по другому.

Каков рынок этого "гейства"? И что общего у этого рынка с рынком Go? И почему игроки этого рынка должны выбросить годами проверенные инструменты, и писать новый фреймворк на ненужном им Go?

Чтобы сделать этот "ПЛЮС" в гошечке внезапно нужно делать статические функции, принимающие на вход интерфейсы. откуда такая инфа и с чего это вдруг функция, принимающая интерфейс, неудобна? Какие-то у вас странные критерии неудобства. И почему обязательно просто функция, а не метод? набил руку на создании и поддержке нативных GUI фреймворков. - нативных GUI фреймворков практичсеки не существует. А те, которые есть - замшелые от старости, с них песок сыпется, и выкинуть их на помойку не жалко от слова совсем. Есть фреймворки под .net, jvm и nodejs, но они не нативные. со всеми вытекающими.

потому что инструменты в C/C++ - они не очень, И языки эти для целей десктопа отвратительны, будем честны. И потому, что разработка в десктоп не сводится к рисованию контролов

потому что инструменты в C/C++ - они не очень, И языки эти для целей десктопа отвратительны, будем честны. И потому, что разработка в десктоп не сводится к рисованию контролов

Qt c++?

Вы говорите про разработку на Go. А для этого она должна иметь тот низкий уровень, которого у нее нет. И, если честно, я не встречал хороших программистов на C++, которые хотели бы перейти на Go. Особенно, если их сфера деятельности не связана с сетевыми сервисами.

хороших вообще очень мало на C++

и они уже давно не пишут десктоп

Вы говорите про разработку на Go. А для этого она должна иметь тот низкий уровень, которого у нее нет. И, если честно, я не встречал хороших программистов на C++, которые хотели бы перейти на Go. Особенно, если их сфера деятельности не связана с сетевыми сервисами.

ну вот у меня как раз связана. хороший десктоп фреймворк на Го - https://github.com/lxn/walk

Напиши, как Go будет выглядеть конструкция "зову виртуальный метод А, одна из его реализаций зовет виртуальный Б, одна из его реализаций зовет виртуальный Ц" В питоне: class X: def a(self): self.b() class Y(X): def b(self): self.c() class Z(Y): def c(self): pass Z()a() Как это будет в Go? Сорри, но .net forms - тонкая прослойка над winapi - не зачет. Java почти всегда все сама рисует - т.е. контролы самой и рисовать приходится - не зачет. nodejs - обертки на существующими фремворками - не зачет.

ничего не понял что это такое и зачем это нужно. Если вы хотите сказать что петон лучше чем Го подходит для целей десктопа, то я не согласен с вами категорически. Разве что для хелувордных задач, которые хоть на баше решай.

в go нет виртуальных вызовов

нельзя

Я лишь хотел сказать, что такая "цепочка" вызовов - абсолютно нормальная вещь в gui фреймворках. И питон тут ни при чем, просто на нем компактнее всего было это записать. Не надо цепляться, если не понял посыла. Я попросил написать цепочку из трех виртуальных вызовов на Go. Хочу посмотреть, как это будет выглядеть. Можешь?

у интерфейса нет метода

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

Ой да ладно. Прости, но это не хинт. В рантайме строится виртуальная таблица для методов. Посмтори реализацию.

нет ни какой вирт. таблицы