пока Mutex<MyStruct> для меня когнитивную нагрузку только увеличил

Значение обёрнутое в Mutex даёт тебе знать о том, что данные тут читать/изменять без лока нельзя. Более того, система проконтролирует, чтобы никакой Вася не забыл об этом.

Type Driven Development

какой тут type driven?

система не проконтролирует что Вася забыл отпустить лок

в хаскеле есть STM - но он намного приятнее и там Вася не забудет лок отпустить

по поводу Type Driven Development есть даже книга

но там не про го

Насколько я понииаю, глобальные константы будут в ELF лежать в секции символов .symtab. Хотя да, надо разобраться и повтыкать в ассемблер, каким образом Go в данном слуае работает с глобальной константой из первого варианта

и в чем проблема?

система не проконтролирует что Вася забыл отпустить лок

и что вася не пытается взять один и тот же лок 2 раза

система не проконтролирует что Вася забыл отпустить лок

Без линейных типов конечно тяжело, да

да тут линейных не надо

да тут линейных не надо

Любому нормальному человеку очевидно, что линейные типы нужны везде o/

\o

type SimpleGraph struct { mutex sync.RWMutex adjacencyList map[interface{}]map[interface{}]struct{} v, e int }

красотень

K P A C U B O

это ты где нашел?

и в чем проблема?

Да я вот задумался и уже не уверен. Ассемблерный код смотреть надо, короче. Но, в любом случае, там константа как-то не выглядела так, что она должна быть глобальной

это другое

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

Да я вот задумался и уже не уверен. Ассемблерный код смотреть надо, короче. Но, в любом случае, там константа как-то не выглядела так, что она должна быть глобальной

я о том, что какая разница где оно лежит в ELF?

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

Да, может быть это define, по сути :) Говорю же, не проверл

он и есть

он и есть

если так, то пофиг, где оно определено. defne он и есть define

Ребят, вот ловлю в fasthttp вот такую строанную ошибку: > error when serving connection "/tmp/my.sock"<->"@": write unix /tmp/my.sock->@: write: broken pipe перед прложением стоит nginx как реверс прокси

приложение начинает опять кушать 10 гигов и высирать такие ошибки

1. нужен ли вам там nginx

нужен для ssl

а просто перейти на эллиптические кривые?

еще он для балансинга между инстансами на ноде

RSA в go, действительно, вдвое медленнее, чем в openssl

но с EC, вроде, этих проблем нет

2. 10 гигнов - это надо смотреть, что у вас не освобождается

мы интенсивно юзаем UDS, и у нас нет с ним проблем

аправда, мы не юзаем fasthttp

аправда, мы не юзаем fasthttp

стандартный net? сколько может на ядро req/sec?

2. 10 гигнов - это надо смотреть, что у вас не освобождается

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

стандартный net? сколько может на ядро req/sec?

я не помню уже. упереться именно в него не удавалось

упираемся мы в гошечке обычно в json

упираемся мы в гошечке обычно в json

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

Кстати, а что там по обратной совместимости в Go2?

Ведь после дженериков придётся всю стдлиб переписать

нет никакого go2

я не помню уже. упереться именно в него не удавалось

ну на приложение/сервер сколько держит примерно?

боьше, чем мне было надо

нет никакого go2

есть черновики

Ребят, вот ловлю в fasthttp вот такую строанную ошибку: > error when serving connection "/tmp/my.sock"<->"@": write unix /tmp/my.sock->@: write: broken pipe перед прложением стоит nginx как реверс прокси

А Nginx точно работает с /tmp/my.sock? В lsof это видно?

боьше, чем мне было надо

у сменя сейчас 16 инстансов и на каждом 1-3k req/sec. и когда я делал на net, его не хватало

> Go 1 and Go 2 code must be able to interoperate in programs with ease. Наес. То есть обратную совместимость сломают, но оставят какую-то интероперабельность. Ну чотко.

у сменя сейчас 16 инстансов и на каждом 1-3k req/sec. и когда я делал на net, его не хватало

да ладно.

он и есть

Да, судя по всему, так и есть. По крайней мере, целочисленная константа выглядит как просто define в итоге

Чуваки, вы обсуждение шкуру неутвержденного драфта

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

А еще всегда убирай все лишнее из цикла! var land landscape там точно не нужно, можешь перед циклом объявить, ты в любом случае ему значение присвоишь на каждой итерации https://play.golang.org/p/2cGwo-jy1IK

да ладно.

по крайней мере соотношение req-sec/cpu было явно выше

@onokonem а ткните мну ссылкой по этим вашим эллиптическим кривым плиз

Да, судя по всему, так и есть. По крайней мере, целочисленная константа выглядит как просто define в итоге

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

да

@onokonem а ткните мну ссылкой по этим вашим эллиптическим кривым плиз

Ecdsa в гугл

у меня есть структура с n полями, сериализуемая в json. Мне нужно ее маршалить в json вида {"@type": "myType", ...other fields...} то есть инжектить на стадии маршалинга поле @type с заданным значением. Учитывая что в полях могут быть подобные же структуры, куда тоже надо инжектить тип, надо реализовать кастомным маршалером. Но самый просто вариант - смаршалить структуру, а потом в полученные байты запихнуть еще одно поле - не работает, т.к. кастомный маршалер логично вызывается циклически. Есть какое-то простое решение, которое мне на ум не пришло? (под простым решением я не имею в виду вручную маршалить всю структуру)

@onokonem а ткните мну ссылкой по этим вашим эллиптическим кривым плиз

а что именно нужно? если про то, как это включить в go, так это в гошечке включить - так это в tls.Config. CipherSuites

а если общую теорию - то в вике статья вполне годная

у меня есть структура с n полями, сериализуемая в json. Мне нужно ее маршалить в json вида {"@type": "myType", ...other fields...} то есть инжектить на стадии маршалинга поле @type с заданным значением. Учитывая что в полях могут быть подобные же структуры, куда тоже надо инжектить тип, надо реализовать кастомным маршалером. Но самый просто вариант - смаршалить структуру, а потом в полученные байты запихнуть еще одно поле - не работает, т.к. кастомный маршалер логично вызывается циклически. Есть какое-то простое решение, которое мне на ум не пришло? (под простым решением я не имею в виду вручную маршалить всю структуру)

Возможно так можно обойти, но это слегка колдунство. https://play.golang.org/p/lyz4Aq2GlUb

у меня есть структура с n полями, сериализуемая в json. Мне нужно ее маршалить в json вида {"@type": "myType", ...other fields...} то есть инжектить на стадии маршалинга поле @type с заданным значением. Учитывая что в полях могут быть подобные же структуры, куда тоже надо инжектить тип, надо реализовать кастомным маршалером. Но самый просто вариант - смаршалить структуру, а потом в полученные байты запихнуть еще одно поле - не работает, т.к. кастомный маршалер логично вызывается циклически. Есть какое-то простое решение, которое мне на ум не пришло? (под простым решением я не имею в виду вручную маршалить всю структуру)

а просто включить свою структуру в структу с полем типа?

а просто включить свою структуру в структу с полем типа?

включена. но поле может быть не заполнено клиентом

ERROR: S client not available

в случае если не заполнено, я сам ее заполняю

научить кастомный маршалер заполнять поле

научил) но как теперь эту структуру замаршалить? циклический маршалинг

ну я бы сделал как

а точно там цикл получается?

я давненько в ту сторону не смотрел, но, вроде, этот фокус получался

а точно там цикл получается?

точно

https://stackoverflow.com/questions/43176625/call-json-unmarshal-inside-unmarshaljson-function-without-causing-stack-overflow

супер, работает

спасибо

да, кстати, это то же что чуть выше предложили

Возможно так можно обойти, но это слегка колдунство. https://play.golang.org/p/lyz4Aq2GlUb

тебе тоже спасибо)

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

> Go 1 and Go 2 code must be able to interoperate in programs with ease. Наес. То есть обратную совместимость сломают, но оставят какую-то интероперабельность. Ну чотко.

кто сказал что обратную совместимость сломают?!

кто сказал что обратную совместимость сломают?!

Вроде должны

ну я вот не против, чтобы сломали

и будет, как два питона

они же ясно и понятно объяснили что не хотят подобнодо сценария как Python 2/3, должна сохраниться экосистема Go1 но с фичами Go2 если они сломают обратную совместимость то получать 2 экосистемы и большую такую проблему

ну я вот не против, чтобы сломали

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

А про суслика v.2 ничего не говорили? Может, его тогда уже на барсука, например, поменять?

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

я бы не отказался от нового языка. совсем нового

А про суслика v.2 ничего не говорили? Может, его тогда уже на барсука, например, поменять?

сколько наклеек придется переклеить и футболок перекупить!

угу

я бы не отказался от нового языка. совсем нового

опять всё снова? ну тогда посмотри на Python 2/3, они тоже этого хотели и получили полный пздц

я бы не отказался от нового языка. совсем нового

Я вот тоже

ну, если совместиость ломать, то ломать полностью. Тогда хоть все понятно будет

И обязатально - барсука. Они с сусликами несовместимы по образу жизни

потому-что люди сидели на Python 2, но они придумали Python 3 который якобы лучше, но у людей приложения и библиотеки на Python 2... если у тебя проект зависит от А, Б и В, но в то время как А и Б перешли на Go 2 а В ещё нет и не скоро вообще перейдёт, но без В вообще никак - то ты останешься на Go 1, который оффициально поддерживают ещё долгое время. а потом тебе понадобится написать Г и поскольку у тебя проект ещё на Go 1 ты напишешь Г для Go 1 а тем кому нужен будет Г будут вынуждены вернуться в Go 1 либо написать снова для Go 2 это полный пиздец, не делайте так, не повторяйте ошибки питона..

Нет ну обратная совместимость скорее всего остаётся

В Го вроде как нет ничего фундаментно плохого/неправильного, ради чего ломали бы обратную совместимость

она должна оставаться, ради сохранения прекрасной экосистемы. и этого можно добиться. Генерики, модули и дополнительные механизмы обработки ошибок могут лечь поверх Go1, вроде Russ Cox об этом и говорил что не будет релиза "Go 2.0", будет постепенное добавление новых фич в Go 1