на перловом проекте dbix вообще звер не так давно, для двух реквестов переписал один запрос на raw sql причем без причесывания индексов, без вьюх и прочее, просто тупо переписал запрос. и сервер задышал, конкретно эти реквесты в 10раз ускорелись, а за счет их популярности, общая нагрузка упала почти в 4 раза

на перловом проекте dbix вообще звер не так давно, для двух реквестов переписал один запрос на raw sql причем без причесывания индексов, без вьюх и прочее, просто тупо переписал запрос. и сервер задышал, конкретно эти реквесты в 10раз ускорелись, а за счет их популярности, общая нагрузка упала почти в 4 раза

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

а в чем проблема написать автоматическую миграцию на sql? насчет подпорки, не то что бы не согласен, но должен уточнить, что это по факту бизнестребование. кадры без знания скл чаще чем с

кадров со знанием SQL полно, между прочим. Мало тех, кто относится к этому, как к работе со множествами. А на бытовом-то уровне - все SQL знают

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

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

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

с программистом на скриптовых языках знание орм идет, как правило, в комплекте

:)

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

с программистом знание sql, как правило, идёт в комплекте

с программистом на скриптовых языках знание орм идет, как правило, в комплекте

какой ORM ? Их же много

с программистом на скриптовых языках знание орм идет, как правило, в комплекте

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

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

ну это ваше частное мнение, а рынку нужны тысячи программистов на «Django»

вряд ли подеретесь...

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

языкосрач?

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

ORM — это как минимум 1) декларативное описание схемы базы 2) запросы с тайпчеком, а не просто строчки с SQL кодом

Тут ещё может автоматическая генерация документации для схемы

языкосрач?

просто релевантный пример, го еще слишком молод для таких тенденций

ORM — это как минимум 1) декларативное описание схемы базы 2) запросы с тайпчеком, а не просто строчки с SQL кодом

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

и молод, и неудачно скроен для чего-то вроде django

ORM — это как минимум 1) декларативное описание схемы базы 2) запросы с тайпчеком, а не просто строчки с SQL кодом

а мне больше нравятся ормы, которые пляшут от базы, а не генерят ее, например, https://github.com/volatiletech/sqlboiler

2) запросы с тайпчеком, а не просто строчки с SQL кодом эээ, даже пых в 4м своем издание использовал биндинги

просто релевантный пример, го еще слишком молод для таких тенденций

ну старики PHP уже сами запутались какой фреймворк изучать ?

и молод, и неудачно скроен для чего-то вроде django

Да джанга хорошаая, Чего ты ее ругаешь? Это же канал про аниме! Как можно что-то ругать?

и молод, и неудачно скроен для чего-то вроде django

ты просто Django не любишь, десу

та все хорошее, что не хорошее то кобол, в смысле на него всем все равно

2) запросы с тайпчеком, а не просто строчки с SQL кодом эээ, даже пых в 4м своем издание использовал биндинги

PHP - это скрипты, а не нормальный язык программирования

та все хорошее, что не хорошее то кобол, в смысле на него всем все равно

кроме банков в Штатах :)

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

PHP - это скрипты, а не нормальный язык программирования

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

А уже пятница, кстати?

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

блин, еще нет :(

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

в пхп все билдеры - простая конкатенация строк. Нету ничего вменяемого

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

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

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

Дело в том, что в пыхе в принципе нету тайпчека, так что и в орм смысла немного

ну, началося :)

В Телеграме можно присвоить сообщению тэг #началося ?

в пхп все билдеры - простая конкатенация строк. Нету ничего вменяемого

а надо как? сложно конкатенировать?

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

быстрее на гора выдать на yii/rails/django чем на го или расте

А у меня вот неожиданно возникла такая ламерская бНОПНЯ. В Go можно как-то умудриться собрать все строго статиком?

Libc будет динамическая всегда

А уже пятница, кстати?

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

Libc будет динамическая всегда

и трэдс :(

вот о том и речь

А зачем?

ну, чтобы Docker не юзать :)

Libc и threads -.это, считай, часть ядра

угу

А при чем тут докер?

ну, чтобы Docker не юзать :)

ну соберите AppImage

сам не знаю, но, говорят, он ото всего спасает :)

Именно для libc и threads докер не нужен - go сам с ними умеет работать

OK! хотя я уже как-то рассказывал, что уметь-то он умеет, но собирать надо тогда там, где оно работает :(

Херня

А в чем проблема динамического libc?

ну, это просто мой личный опыт

Бывают проблемы, если в альпайне собрать

Ну так не надо в альпайне собирать

Бывают проблемы, если в альпайне собрать

если собрать и юзать в системах с разными реализациями libc - так правильнее. Это работает в обе стороны

Я ни с чем не знаю проблем, тупо копируя бинарник с Ubuntu 16 на оно же 12. А между убунтой и CentOS - один раз были реальные проблемы. Просто надо было там и собирать.

Коллега, это немножко чушь

почему?

Не надо свои - редкие - проблемы генерализировать

как скажешь :(

ERROR: S client not available

что-то все мне сегодня говорят, что я гоню чушь... Хнык :(

Я вот на маке собираю, и ни разу не видал проблем

Это почему?

ну, ты визука, видимо

что-то все мне сегодня говорят, что я гоню чушь... Хнык :(

Не ной, соберись тряпка!

Не ной, соберись тряпка!

а чего они такие злыыыеее???? хнык

а чего они такие злыыыеее???? хнык

На фото ты? Старше меня в 2 раза

Я вот на маке собираю, и ни разу не видал проблем

у меня тут идеологический вопрос есть, если мы по гоу вей должны всегда интерфейсы класть туда где используем эту зависимость, то как это вяжеться с DAO в хендлерах? получается что DAO интерфейс должен быть именно там O_o

да, видимо, юмор у мне я и правда не смешной :)

у меня тут идеологический вопрос есть, если мы по гоу вей должны всегда интерфейсы класть туда где используем эту зависимость, то как это вяжеться с DAO в хендлерах? получается что DAO интерфейс должен быть именно там O_o

а ты не завязывай хэндлер на DAO. завяжи его на DataProvider или на сервис, который будет реализован через DAO

type AddUserHandler struct { service UserService } type UserService interface { AddUser(user User) }

логично?

Почему это так работает? https://play.golang.org/p/RhZh6EwlVQh Я понимаю что int нужно привести к duration, но не понимаю почему если просто ввести число это работает

потому, что нетипизованная константа преобразуется к нужному типу автоматически

https://play.golang.org/p/vOsehho5kK6

ну так она к инту преобразовалась

в чем разница между тем интом к которому привела нетипизированная константа и тем интом который указан?

потому, что нетипизованная константа преобразуется к нужному типу автоматически

нетипизированный литерал, и в правильном контексте. Константа - это другое

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

в чем разница между тем интом к которому привела нетипизированная константа и тем интом который указан?

в том и разница

т.е. на момент использования внутри fmt.Println(time.Second * i) i имеет тип Duration?

time.Duration?

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

ну так она к инту преобразовалась

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

type Duration int64

нетипизированный литерал, и в правильном контексте. Константа - это другое

нетипизованная константа преобразуется к нужному типу автоматически

литерал

ну всё собсвенно, https://github.com/romshark/Go-2-Proposal---Immutability/issues/14 теперь mut -> immut кастится implicit: func M() const [] * const T { return []*T {&T{}, &T{}} // Implicit cast }

коллега, не тупите

хорошо, спасибо, прояснилось

коллега, не тупите

Может, я простьо хочу, чтобы ты был строже, хотя у меня юмор не смешной и ты можешь все не так понять :)

ну всё собсвенно, https://github.com/romshark/Go-2-Proposal---Immutability/issues/14 теперь mut -> immut кастится implicit: func M() const [] * const T { return []*T {&T{}, &T{}} // Implicit cast }

сложно чет