я вроде в FAQ описал что иммут это одна из тех фич которые безболезненно реализовать в Go 1.x - реально, относительно других затей типа error handling и generics

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

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

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

хорошее замечание. С линтерами всё зависит от того как они парсят Go код, если они парсят его через AST тогда всё будет в порядке и продолжит работать безменений.

линтеры работают с выхлопом ast, если как-то это завезут, линтерам пофиг

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

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

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

и какие-нибудь линтеры могут просто не ожидать, что там придет что-то кроме ast.Ident

В рамках противодействия свободному времени и желанию улучшить материал, дайте критику по https://habr.com/post/425025/ , заранее спасибо

Ок спасибо

Тут Алексей Палащенко бывает, у него есть ORM общего пользования. Поговори с ним, кстати

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

расскажи это автоматическим миграциям

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

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

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

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

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

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

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

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

языкосрач?

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

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

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

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

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

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

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

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

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

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

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

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

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

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