нет, байт-код - не дерево, это переработанная программа на более низком уровне, более удобная для исполнения. Из нее сложновато сгенерить исходный текст программы.
99% статей что-то рекламируют. Или свои телеграм-каналы, или продукты компаний, или сами эти компании.
Это всё четко разрешено правилами: можно вставлять рекламную ссылку на свой блог. Хабр специально это разрешил пару лет назад.
Да что там говорить, сам Хабр существует только для того, чтобы получать деньги с рекламодателей и с платных блогов компаний! Без рекламы не будет вообще никаких статей и Хабра тоже.
Но нет, каждый раз находится человек, отрицающий объективную реальность, и пишет "разгромные" статьи про "рак".
1. Нельзя банить токсичных комментаторов. В итоге нормальные люди совсем уходят или не пишут статей, не хотят присутствовать в агрессивной среде. И с их уходом плотность "плохих" становится еще хуже. 2. Накрутка плюсов некоторыми компаниями, что уничтожает весь баланс. В топе хабра всего 20 мест, и минимум половина всегда забита неинтересными статьями, которые были заплюсованы по команде 3. На главной странице по умолчанию показывается всё подряд. Было бы эффективнее показывать топ, немного подмешивая туда новые статьи. Тогда просмотров в целом было бы больше (люди бы не уходили сразу, увидев непонятно что)
Если я правильно понял, то там, где в js модно писать map(..).filter(...).reduce(...), и там под капотом всё магически перетасовывается, то в go ты напишешь простой цикл с одним ифом, и будешь иметь полный контроль и 100% понимание происходящего
2) если данные прилетают из двух источников, то лучше сделать по отдельному каналу. А потом fan in.
3) чем плох sync.Map? Что там везде any? В любом случае, понятность кода может создавать оверхед. Даже, когда линейный код тупо разбивается на функции - это уже нехилый оверхед, далеко не всё инлайнится компилятором
Я имел в виду, что Дейкстра вынес это обсуждение в массы (что там, где много goto, там много ошибок), в результате чего люди стали писать по-другому. Т.е. это толчок к развитию, а не то, что Дейкстара писал про иерархии подпрограмм
Специализированные фичи обычно лучше. Но если уже есть посгрес, добавить к одной из ее таблиц возможность семантического поиска - это проще в поддержке. Зависит от требований, короче
в вашем случае и valid_until и created_at берутся у одной и той же записи. Т.е. логически это действует так: выбираются все строки, где valid_until > created_at, а потом среди них смотится, есть ли повторы юзеров. Т.е. бессмыслица, так как valid_until > created_at это true для всех записей.
Exclude же проверяет, есть ли другие записи, которые пересекаются по диапазону со вставляемой записью
на практике я не раз встречал ситуацию, когда отсутствие unique или foreign key приводили к проблемам. И наоборот: не вижу особой проблемы добавить exclude
В общем, это зависит от конкретики, я бы не обобщал и не делал бы из этого глобального правила
По сути - это вопрос о том, зачем вообще нужны констрейнты бд. Те же Unique, Foreign key и т.д.
Это просто дополнительная защита от случайных ошибок. Например, в одном месте при выдаче купонов учли момент с уникальностью, а в другом (при массовом импорте купонов ) - нет. И тогда будет хаос.
Разумеется, всегда есть неважные места, где можно ничего не проверять на базе. А есть работа с деньгами, где лучше 3 раза перебдеть.
В treesitter как-то решили эту проблему. У них в описании:
"Достаточно надежен , чтобы обеспечивать полезные результаты даже при наличии синтаксических ошибок."
Дв и jetbrains ide умеют строить неполноценное дерево и осуществлять рефакторинг даже в несовсем правильном коде
нет, байт-код - не дерево, это переработанная программа на более низком уровне, более удобная для исполнения. Из нее сложновато сгенерить исходный текст программы.
99% статей что-то рекламируют. Или свои телеграм-каналы, или продукты компаний, или сами эти компании.
Это всё четко разрешено правилами: можно вставлять рекламную ссылку на свой блог. Хабр специально это разрешил пару лет назад.
Да что там говорить, сам Хабр существует только для того, чтобы получать деньги с рекламодателей и с платных блогов компаний! Без рекламы не будет вообще никаких статей и Хабра тоже.
Но нет, каждый раз находится человек, отрицающий объективную реальность, и пишет "разгромные" статьи про "рак".
но прочитал с интересом )
Go для io-bound задач. Пишите лучше на Расте )
просто, не залогинившись, зайдите на habr
когда-то давно там был топ за сутки, сейчас просто всё подряд
У Хабра три большие проблемы:
1. Нельзя банить токсичных комментаторов. В итоге нормальные люди совсем уходят или не пишут статей, не хотят присутствовать в агрессивной среде. И с их уходом плотность "плохих" становится еще хуже.
2. Накрутка плюсов некоторыми компаниями, что уничтожает весь баланс. В топе хабра всего 20 мест, и минимум половина всегда забита неинтересными статьями, которые были заплюсованы по команде
3. На главной странице по умолчанию показывается всё подряд. Было бы эффективнее показывать топ, немного подмешивая туда новые статьи. Тогда просмотров в целом было бы больше (люди бы не уходили сразу, увидев непонятно что)
Если я правильно понял, то там, где в js модно писать map(..).filter(...).reduce(...), и там под капотом всё магически перетасовывается, то в go ты напишешь простой цикл с одним ифом, и будешь иметь полный контроль и 100% понимание происходящего
1) не совсем очевидно, как показывает практика
2) если данные прилетают из двух источников, то лучше сделать по отдельному каналу. А потом fan in.
3) чем плох sync.Map? Что там везде any? В любом случае, понятность кода может создавать оверхед. Даже, когда линейный код тупо разбивается на функции - это уже нехилый оверхед, далеко не всё инлайнится компилятором
Я, кстати, сейчас посмотрел, в статье было про плотность ошибок при использовании goto. Но это, как я понял, было примечание редактора (Вирта).
Я имел в виду, что Дейкстра вынес это обсуждение в массы (что там, где много goto, там много ошибок), в результате чего люди стали писать по-другому. Т.е. это толчок к развитию, а не то, что Дейкстара писал про иерархии подпрограмм
Толя, код справа на Go написан )))
Хотя понимаю, о чем ты
Кашкай гонится за Жуком
Специализированные фичи обычно лучше. Но если уже есть посгрес, добавить к одной из ее таблиц возможность семантического поиска - это проще в поддержке. Зависит от требований, короче
это выражение дает не ложь, а null
спасибо, отметил в статье, что триггер надо дорабатывать
в вашем случае и valid_until и created_at берутся у одной и той же записи. Т.е. логически это действует так: выбираются все строки, где valid_until > created_at, а потом среди них смотится, есть ли повторы юзеров. Т.е. бессмыслица, так как valid_until > created_at это true для всех записей.
Exclude же проверяет, есть ли другие записи, которые пересекаются по диапазону со вставляемой записью
на практике я не раз встречал ситуацию, когда отсутствие unique или foreign key приводили к проблемам. И наоборот: не вижу особой проблемы добавить exclude
В общем, это зависит от конкретики, я бы не обобщал и не делал бы из этого глобального правила
ну ок )
По сути - это вопрос о том, зачем вообще нужны констрейнты бд. Те же Unique, Foreign key и т.д.
Это просто дополнительная защита от случайных ошибок. Например, в одном месте при выдаче купонов учли момент с уникальностью, а в другом (при массовом импорте купонов ) - нет. И тогда будет хаос.
Разумеется, всегда есть неважные места, где можно ничего не проверять на базе. А есть работа с деньгами, где лучше 3 раза перебдеть.