Если не знаете, что значит "защищённый DNS", значит не используете. Ещё могут видеть весь не зашифрованный трафик (http). Могут определить тип трафика (сайты, торренты и т.п.)
Ну и как там в криокамере? Во всех браузерах уже несколько лет DNS over HTTPS включается по дефолту, если системный DNS не DNS over TLS (ну или браузеру так кажется).
Горутина это вам не тред ОС. Если много тредов - это где-то 10000, то 1000000 горутин это ещё не много. Кроме того, можно же запилить token bucket и не запускать больше n. А вообще, конечно этот вариант гораздо адекватнее всего того, что в статье.
Нет конечно. В Go типизация другая, поэтому ситуаций, когда интерфейс должен быть описан "там, где он реализуется", а не "там, где он потребляется", примерно 3, и все уже есть стандартной библиотеке. Иначе говоря, в go-коде, если возвращаемый тип - интерфейс, то это большой красный флаг (код получится сильно связанным, т.к. развязываемся мы буквально одним способом - интерфейсом на стороне потребителя).
Так в тесте никакой работы не производится. Т.е. измеряется размер всех стеков при stackful подходе и при stackless. Результаты в принципе ожидаемы. Вот только с реальными задачами миллион горутин, выполняющих работу, - обычный кейс даже на обычном серверном железе, а что будет с другими языками, особенно если учитывать ещё расходы на CPU, а не только на память?
Начиналось всё хорошо, а потом сага - паттерн (а не антипаттерн). Если мы вовлекаем 2-3-5-10 микросервисов в одну бизнес-операцию, это значит мы неверно их разделили. Это примерно как держать фамилию клиента в одном постгресе, его отчество в другом, а фамилию в третьем. Разумеется, если человек решит поменять ФИО (всё сразу) нам нужна будет сага. Но в действительности нам лучше бы держать изменяемые вместе данные - вместе, ваш кэп.
Для РФ точно неактуально. Попробуйте просто сходить в банк и спросить "что нужно, чтобы у меня был свой терминал, которым можно списывать деньги с карт + сколько это стоит + как быстро и как легко вы сможете его отобрать и за какие мои прегрешения"? Сразу станет понятно, почему в новостях такое вообще не встречается.
И честно говоря ничего особо специфического в программировании нет. Как минимум если сравнивать с другими инженерными профессиями уж точно.
Да, конечно, в механике и электрике каждый день новые технологии, каждые 5 лет смена основной парадигмы, а каждые 10 лет безнадёжное устаревание 2/3 инструментария (нет).
По ощущениям перфа x86_64 где-то "упятерилась" с 2017. И это мы сравниваем только с самыми "новыми" итаниумами. Т.е. даже какое-то бюджетное железо, помимо гарантированной совместимости будет ещё и заметно быстрее. Трудно понять зачем тратить силы на поддержку.
Как и последние 10 лет: Samsung и WD. Только не самое бюджетное и не самое новое (чтобы "восторженные" отзывы уже были заметны). Топы кстати нужны только для циферок в бенчах. Если вопрос про китайцев, то лучше никакие🤷♂️
Первый принцип понят неверно. Хотя это обычное дело, даже с учётом того, что в книге, чуть дальше, всё расписано. У меня, может, весь микросервис выполняет одну задачу. Что такое задача вообще?
Правильно так: у кода должна быть только одна причина для изменений. Более того, дядя Боб её буквально уточняет: эта причина - пользователь системы (бухгалтер например). Т.е. мы должны зависеть только от бизнес-требований, а не от каких-то API и уж тем более имплементаций чего-то. Это принцип влияет на все остальные принципы, особенно второй. В итоге любые детали реализации (API breakage например) не должны заставлять нас что-то переписывать, только написать новый адаптер.
В приличном месте такое использование any никогда ревью не пройдёт. Посмотрите как надо: https://cs.opensource.google/go/go/+/refs/tags/go1.23.1:src/encoding/json/stream.go;l=289 И да, в вашем примере лапши будет гораздо больше, ведь вам же надо перебирать все возможные типы для всех возможных опций. В Go используя any вы теряете информацию о типе, но не получаете ничего. Если тип переменной известен - никогда не передавайте её как any, это просто не имеет смысла.
Поищите на Наге, там несколько лет назад были удивлённые возгласы фанатов, которые закупали их тысячами, а они тысячами могли приехать с непроклеенными частями (радиаторы кажется) внутри и весело греметь при тряске. Т.е. контроля качества нет вообще. И это на голову выше надёжности Asus? Ни за что не поверю, хоть и терпеть его (Asus) не могу.
Если у вас тормозит net/http - вы делаете что-то не то. Тормозить должна база, ответы других сервисов или БЛ (зависит от задачи), а не протокол передачи данных. Если он правда тормозит, вы что-то неправильно спроектировали (не взяли grpc или nginx там где надо было). А ещё оно иногда падучее (zero allocation не просто даётся). Итого: актуально для школьников-бенчмаркеров, а для бизнеса не оч.
Поддержу, статья про другой принцип SOLID. Принцип открытости-закрытости простыми словами звучит так: "любые изменения в систему должны вноситься за счёт написания нового кода, а не изменения старого". Т.е. мы пишем новый модуль/компонент и заменяем им старый, остальные модули/компоненты не изменяются и работают как раньше. Интерфейс, кстати, действительно в этом помогает: замена одной реализации интерфейса на другую - идеальная демонстрация.
Отличный повод держаться от него подальше 😀
Ну и как там в криокамере? Во всех браузерах уже несколько лет DNS over HTTPS включается по дефолту, если системный DNS не DNS over TLS (ну или браузеру так кажется).
Стрипать надо не через "
-ldflags "-s -w"", а просто утилитой strip, так обычно бинарник меньше выходит (и это официально поддерживается).Горутина это вам не тред ОС. Если много тредов - это где-то 10000, то 1000000 горутин это ещё не много. Кроме того, можно же запилить token bucket и не запускать больше n. А вообще, конечно этот вариант гораздо адекватнее всего того, что в статье.
Они все в той или иной мере совместимы.
вот именно, если у российский разработчиков есть счета за пределами РФ, их, видимо, не касается, что делает заголовок даже не кликбейтным, а лживым
Нет конечно. В Go типизация другая, поэтому ситуаций, когда интерфейс должен быть описан "там, где он реализуется", а не "там, где он потребляется", примерно 3, и все уже есть стандартной библиотеке. Иначе говоря, в go-коде, если возвращаемый тип - интерфейс, то это большой красный флаг (код получится сильно связанным, т.к. развязываемся мы буквально одним способом - интерфейсом на стороне потребителя).
Так в тесте никакой работы не производится. Т.е. измеряется размер всех стеков при stackful подходе и при stackless. Результаты в принципе ожидаемы. Вот только с реальными задачами миллион горутин, выполняющих работу, - обычный кейс даже на обычном серверном железе, а что будет с другими языками, особенно если учитывать ещё расходы на CPU, а не только на память?
Скорее всего выложат, у BHV прям свой магазин есть с приятными ценами.
Начиналось всё хорошо, а потом сага - паттерн (а не антипаттерн). Если мы вовлекаем 2-3-5-10 микросервисов в одну бизнес-операцию, это значит мы неверно их разделили. Это примерно как держать фамилию клиента в одном постгресе, его отчество в другом, а фамилию в третьем. Разумеется, если человек решит поменять ФИО (всё сразу) нам нужна будет сага. Но в действительности нам лучше бы держать изменяемые вместе данные - вместе, ваш кэп.
Для РФ точно неактуально. Попробуйте просто сходить в банк и спросить "что нужно, чтобы у меня был свой терминал, которым можно списывать деньги с карт + сколько это стоит + как быстро и как легко вы сможете его отобрать и за какие мои прегрешения"? Сразу станет понятно, почему в новостях такое вообще не встречается.
Да, конечно, в механике и электрике каждый день новые технологии, каждые 5 лет смена основной парадигмы, а каждые 10 лет безнадёжное устаревание 2/3 инструментария (нет).
По ощущениям перфа x86_64 где-то "упятерилась" с 2017. И это мы сравниваем только с самыми "новыми" итаниумами. Т.е. даже какое-то бюджетное железо, помимо гарантированной совместимости будет ещё и заметно быстрее. Трудно понять зачем тратить силы на поддержку.
Как и последние 10 лет: Samsung и WD. Только не самое бюджетное и не самое новое (чтобы "восторженные" отзывы уже были заметны). Топы кстати нужны только для циферок в бенчах. Если вопрос про китайцев, то лучше никакие🤷♂️
Первый принцип понят неверно. Хотя это обычное дело, даже с учётом того, что в книге, чуть дальше, всё расписано. У меня, может, весь микросервис выполняет одну задачу. Что такое задача вообще?
Правильно так: у кода должна быть только одна причина для изменений. Более того, дядя Боб её буквально уточняет: эта причина - пользователь системы (бухгалтер например). Т.е. мы должны зависеть только от бизнес-требований, а не от каких-то API и уж тем более имплементаций чего-то. Это принцип влияет на все остальные принципы, особенно второй. В итоге любые детали реализации (API breakage например) не должны заставлять нас что-то переписывать, только написать новый адаптер.
В приличном месте такое использование any никогда ревью не пройдёт. Посмотрите как надо: https://cs.opensource.google/go/go/+/refs/tags/go1.23.1:src/encoding/json/stream.go;l=289
И да, в вашем примере лапши будет гораздо больше, ведь вам же надо перебирать все возможные типы для всех возможных опций. В Go используя any вы теряете информацию о типе, но не получаете ничего. Если тип переменной известен - никогда не передавайте её как any, это просто не имеет смысла.
Поищите на Наге, там несколько лет назад были удивлённые возгласы фанатов, которые закупали их тысячами, а они тысячами могли приехать с непроклеенными частями (радиаторы кажется) внутри и весело греметь при тряске. Т.е. контроля качества нет вообще. И это на голову выше надёжности Asus? Ни за что не поверю, хоть и терпеть его (Asus) не могу.
Если у вас тормозит net/http - вы делаете что-то не то. Тормозить должна база, ответы других сервисов или БЛ (зависит от задачи), а не протокол передачи данных. Если он правда тормозит, вы что-то неправильно спроектировали (не взяли grpc или nginx там где надо было). А ещё оно иногда падучее (zero allocation не просто даётся).
Итого: актуально для школьников-бенчмаркеров, а для бизнеса не оч.
Поддержу, статья про другой принцип SOLID. Принцип открытости-закрытости простыми словами звучит так: "любые изменения в систему должны вноситься за счёт написания нового кода, а не изменения старого". Т.е. мы пишем новый модуль/компонент и заменяем им старый, остальные модули/компоненты не изменяются и работают как раньше. Интерфейс, кстати, действительно в этом помогает: замена одной реализации интерфейса на другую - идеальная демонстрация.
Прострелил то прострелил, но ружьё то не у них совсем, они просто миньоны, которым буквально приказывают)