Я тут Go попробовал на праздниках (основной мой язык - это C# как раз). Давно уже хотел.
Сначала я решил написать простейший калькулятор, как в универе на паскале.
Началось все с того, что после билда консольного приложения, касперский мне выдал что в exe-шнике троян.
Гифка со звуком
Далее у меня начал ломаться аналог Console.ReadLine, там внутри какие-то сайд эффекты, если ввести "абврылг" вместо 4.5. Я спросил чат гпт, что с этим делать и он предложил вариант, где я должен руками написать что-то вроде чтения из потока из stdin/out. Че серьезно?
Потом я решил закодить rest api.
Оказалось, что Microsoft как разработчик языка C# поддерживает и развивает довольно качественные и функциональные фреймворки, чем пожалуй задает некий стандарт наличия таких вещей в экосистеме - asp.net core для rest api, ADO.NET / EF / EF Core для доступа к данным и так далее.
В случае с Go - Google ничего такого не делает. Я там нашел пару фреймворков на гит хабе (gin-goinc и какой-то от Uber). Но создалось ощущение, что это какие-то собранные на коленке штуковины. И только с тем функционалом, который понадобился условном опен-сорусеру или тому же уберу. А все остальное будь добр пили руками сами.
Не, в экосистеме C# тоже есть nuget и сто тыщ питцот миллионов собранных на коленке библиотек различного качества. Но не глобальные же вещи типа rest api и orm?
Идем дальше - ООП в Go по сути нет, есть структуры, интерфейсы (без привязке к структуре), процедурщина в виде конструкторов / методов чуть ли не в глобальной области видимости (package aka namespace помогает чуть-чуть). Это если бы я на C# все писал с использованием extension methods.
DI / IoC тоже нет. В связи с этим я теперь начал угорать с вакансий на Go
Как я теперь это читаю: http api какое-то обрезанное и собранное на коленке, ООП обрезанное, зачем его требовать? SOLID? как вы это сделаете без ООП и DI / IoC в том числе?
Насчет горутин и каналов - это короче аналог Task.Run + Channels в C#. Чат гпт можно попросить написать один и тот же код на Go и на C# и увидеть схожесть и разницу. Каналы я в C# не использовал. Это по сути очередь в памяти и она теряет данные при перезагрузке сервера.
И тут я вспомнил, как мой самый первый начальник на самой первой работе сказал, еще в 2007 году, что C# это очень абстрактный язык. Вот, он был прав.
На C# можно просто писать код, без сайд эффектов внутри. Вот как ты думаешь - так и пишешь. Что ты ждешь от него, то он тебе и выдает. Есть "промышленные" фреймворки, поддерживаемые самой корпорацией, кто изобрел язык. Microsoft и C# короче разбаловали меня.
Go - какое-то недоразумение, понавставлял кучу палок в колеса, и это я еще не пробовал писать ничего сложнее калькулятора. Хорошо что дженерики есть
Я типа сениор, вот как вы в статье написали - тащу проект / продукт, и в день происходит до 12-15 переключений между задачами от архитектурных до поддержки 3-ей линии плюс приходиться пинать нерадивых джунов, идентифицирующие себя мидлами как мимнимум.
По итогу - ничего хорошего. У меня бесконечный поток вопросов и задач, у меня нет времени все это успеть, под нож идут мои программистские задачи, а потом приходят менеджеры и расстраиваются, что я не сделал какую-то одну конкретную задачу, которая внезапно стала более приоритетной.
И еще я начинаю кучу всего пропускать и делать «херак херак и в продакшен». Опять же, ничего хорошего.
В итоге я и есть bottleneck.
И это у нас еще выделенный dev ops есть. То есть облаком я не занимаюсь.
Прочитал эту статью (очередную про ИИ пузырь) и внезапно пришла мысль в голову - что ИТ в целом - это пузырь и/или имеет признаки пузыря.
Началось все с доткомов - когда каждая компания хотела иметь свой сайт. И мамкины (и не очень) инвесторы понесли свои денюжки. Кстати до сих пор есть отголоски - по сути все стартапы на коленках это те же доткомы. Только с новым лицом.
Потом подтянулись компании с тяжелыми бизнес-процессами - финансы, банки, логистика. Больше ожиданий, больше инвестиций, больше потребности в работниках, вузы стали создавать ИТ специальности и наполнять рынок начинающими профессионалами. Это вот уже время, которое я застал - 2000-2020. Ну и все мы теперь видим к чему это привело - софт в целом понаписали достаточно за два десятка лет. И по инерции мышления народных масс мы получили кучу вкатунов после курсов и кризис рынка труда. Столько уже не надо.
Но вместо этого импульс получили технически- и науко-емкие вещи - ML, DS, нейросети на основе математических законов. Людей, которые это реально понимают меньше, чем тех, кто осилил предыдущий этап с тяжелыми бизнес-процессами. Сейчас видим, как специалистов по ИИ переманивают офферами на сотни миллионов баксов.
Помнится у меня налоговая списала платеж по патенту, хотя я его оплатил. Из-за того, что я сменил адрес прописки и уведомил налоговую об этом. Акт был за подписью какого-то там инспектора, который не удосужился посмотреть все поступления.
Это ж если компьютер будет без устали 24 часа в сутки клепать акты и списывать бабло со счетов юр и физ лиц без суда и следствия - будет бесконечный поток актов и по теории вероятности больше законопослушных людей пострадают от несправедливости.
Да это походу всегда так было, такие вакансии были еще лет 10 назад. И тут статьи, была одна от Тим Лида из альфа банка - он там Тим лид, тех лид, пм и продукт овнер одновременно.
Разница между тех лидом и тим лидом очевидная. Первый читает книги по технологиям, а второй по психологии.
Не понятно только откуда рождаются такие описания вакансий - от руководителей или hr. И стоит ли вообще идти в компании, у которых в вакансии написана такая дичь.
Таки не вопрос, пускай сервис после брокера. Пускай поток событий - первичный источник. Вопрос в другом - пришел юзер и спросил "у меня тут состояние в БД не соответствует ожидаемому, почему?" И теперь надо пойти и найти где произошел сбой - это событие вообще не пришло? Или пришло, но брокер его не сохранил? Или сохранил и оно там зависло или попало в dead очередь? Или что-нибудь еще? И вот чтобы найти (или не найти) это одно конкретное сообщение среди миллионов других в брокере - это невозможно сделать без языка запросов, которого в брокерах нет.
По-моему гарантии доставки и первичное сохранение сообщения без потери - это немного разные вещи. Грубо говоря - что если сервер с брокером перезагрузится, потеряются ли входящие сообщения?
Первичное сохранение сообщения - это процесс между продюсером и брокером. Пока мы точно не убедились, что брокер получил сообщение, то ни о каком exactly-once / at-least-once речи быть еще не может. Это как бы вторая часть процесса - между самим брокером и консьюмером.
Следовательно там надо смотреть настройки и возможности конкретного брокера - есть ли write ahead log, бэкапы и все такое, что для реляционных БД являются общепринятыми вещами. Ну и очевидно, что если брокер пишет каждое новое сообщение в ahead log и сразу на диск, чтобы их не потерять - он не будет в разы быстрее БД, потому что механизм и задержки примерно одинаковые.
Я пожалуй никогда толком не понимал event driven. В моем понимании нельзя выложить доступ к брокеру сообщений в открытый доступ. Обязательно должен быть фасад (например тот же самый rest api).
Далее, все эти брокеры мне кажутся во первых менее надежными, потому что в них нет транзакций, да и в целом вопросы к тому, как они хранят данные. Во вторых внутри них нет языка запросов, чтобы что-то найти в случае ошибки или некорректного поведения в рамках бизнес процесса. То есть нельзя просто взять и вывалить все это юзеру на ui, чтобы он там искал свои загруженные или потерянные заказы.
В итоге я прихожу к другим паттернам - заказы мы складываем в БД, юзеру мы показываем на ui из БД со всякими фильтрами (с использованием языка запросов). Далее заказ у нас имеет статусную модель и конечный автомат. И прежде чем что-то отправлять в брокер сообщений - надо отразить это в БД (transaction outbox).
При этом есть статьи от того же Яндекса как они делали очередь на postgresql.
В итоге event driven и брокеры сообщений в частности - это такая штуковина сбоку, которые сами по себе работать не будут. Мало того, в aws cloud есть event bridge - тоже что-то вроде брокера сообщений, но микросервисы он дергает по rest api 🙃
В общем, вывод - оригинальная статья довольно поверхностная и нет оговорок про те моменты, которые подсветил я.
У нас на вакансию сениора (на сайте компании) за 3 дня было 300+ резюме. И там 99% все программисты с опытом и профильным высшим образованием. И 70-80% с требуемым списком скилов.
То есть по идее надо назначить примерно 250 собесов по 15-20 минут - это 1000 часов поговорить со всеми и выяснить насколько они наврали в резюме.
Так то ВСЕ резюме по последним бест практис - скилы, 2-3 страницы, жирным делают акценты, и достижения пишут по STAR. Все одинаковое, как под копирку.
Сдек работает на всю страну, клиенты и пункты выдачи по всей стране в разных часовых поясах. И вы не сталкивались с проблемами часовых поясов? И не знали что сервера и всякие логи должны быть в utc?
И что за синхронный REST? Синхронная авторизация? Что это значит? В Java веб сервера работают в один поток??
Я тут Go попробовал на праздниках (основной мой язык - это C# как раз). Давно уже хотел.
Сначала я решил написать простейший калькулятор, как в универе на паскале.
Началось все с того, что после билда консольного приложения, касперский мне выдал что в exe-шнике троян.
Далее у меня начал ломаться аналог Console.ReadLine, там внутри какие-то сайд эффекты, если ввести "абврылг" вместо 4.5. Я спросил чат гпт, что с этим делать и он предложил вариант, где я должен руками написать что-то вроде чтения из потока из stdin/out. Че серьезно?
Потом я решил закодить rest api.
Оказалось, что Microsoft как разработчик языка C# поддерживает и развивает довольно качественные и функциональные фреймворки, чем пожалуй задает некий стандарт наличия таких вещей в экосистеме - asp.net core для rest api, ADO.NET / EF / EF Core для доступа к данным и так далее.
В случае с Go - Google ничего такого не делает. Я там нашел пару фреймворков на гит хабе (gin-goinc и какой-то от Uber). Но создалось ощущение, что это какие-то собранные на коленке штуковины. И только с тем функционалом, который понадобился условном опен-сорусеру или тому же уберу. А все остальное будь добр пили руками сами.
Не, в экосистеме C# тоже есть nuget и сто тыщ питцот миллионов собранных на коленке библиотек различного качества. Но не глобальные же вещи типа rest api и orm?
Идем дальше - ООП в Go по сути нет, есть структуры, интерфейсы (без привязке к структуре), процедурщина в виде конструкторов / методов чуть ли не в глобальной области видимости (package aka namespace помогает чуть-чуть). Это если бы я на C# все писал с использованием extension methods.
DI / IoC тоже нет. В связи с этим я теперь начал угорать с вакансий на Go
Как я теперь это читаю: http api какое-то обрезанное и собранное на коленке, ООП обрезанное, зачем его требовать? SOLID? как вы это сделаете без ООП и DI / IoC в том числе?
Насчет горутин и каналов - это короче аналог Task.Run + Channels в C#. Чат гпт можно попросить написать один и тот же код на Go и на C# и увидеть схожесть и разницу. Каналы я в C# не использовал. Это по сути очередь в памяти и она теряет данные при перезагрузке сервера.
И тут я вспомнил, как мой самый первый начальник на самой первой работе сказал, еще в 2007 году, что C# это очень абстрактный язык. Вот, он был прав.
На C# можно просто писать код, без сайд эффектов внутри. Вот как ты думаешь - так и пишешь. Что ты ждешь от него, то он тебе и выдает. Есть "промышленные" фреймворки, поддерживаемые самой корпорацией, кто изобрел язык. Microsoft и C# короче разбаловали меня.
Go - какое-то недоразумение, понавставлял кучу палок в колеса, и это я еще не пробовал писать ничего сложнее калькулятора. Хорошо что дженерики есть
Я типа сениор, вот как вы в статье написали - тащу проект / продукт, и в день происходит до 12-15 переключений между задачами от архитектурных до поддержки 3-ей линии плюс приходиться пинать нерадивых джунов, идентифицирующие себя мидлами как мимнимум.
По итогу - ничего хорошего. У меня бесконечный поток вопросов и задач, у меня нет времени все это успеть, под нож идут мои программистские задачи, а потом приходят менеджеры и расстраиваются, что я не сделал какую-то одну конкретную задачу, которая внезапно стала более приоритетной.
И еще я начинаю кучу всего пропускать и делать «херак херак и в продакшен». Опять же, ничего хорошего.
В итоге я и есть bottleneck.
И это у нас еще выделенный dev ops есть. То есть облаком я не занимаюсь.
А у меня такой был
Точно же, было время - у меня была Sound Blaster Audigy и к ней колонки Sven 5.1
Прочитал эту статью (очередную про ИИ пузырь) и внезапно пришла мысль в голову - что ИТ в целом - это пузырь и/или имеет признаки пузыря.
Началось все с доткомов - когда каждая компания хотела иметь свой сайт. И мамкины (и не очень) инвесторы понесли свои денюжки. Кстати до сих пор есть отголоски - по сути все стартапы на коленках это те же доткомы. Только с новым лицом.
Потом подтянулись компании с тяжелыми бизнес-процессами - финансы, банки, логистика. Больше ожиданий, больше инвестиций, больше потребности в работниках, вузы стали создавать ИТ специальности и наполнять рынок начинающими профессионалами. Это вот уже время, которое я застал - 2000-2020. Ну и все мы теперь видим к чему это привело - софт в целом понаписали достаточно за два десятка лет. И по инерции мышления народных масс мы получили кучу вкатунов после курсов и кризис рынка труда. Столько уже не надо.
Но вместо этого импульс получили технически- и науко-емкие вещи - ML, DS, нейросети на основе математических законов. Людей, которые это реально понимают меньше, чем тех, кто осилил предыдущий этап с тяжелыми бизнес-процессами. Сейчас видим, как специалистов по ИИ переманивают офферами на сотни миллионов баксов.
Что дальше?
А знаете, наверное хорошо что они не оценили.
Помнится у меня налоговая списала платеж по патенту, хотя я его оплатил. Из-за того, что я сменил адрес прописки и уведомил налоговую об этом. Акт был за подписью какого-то там инспектора, который не удосужился посмотреть все поступления.
Это ж если компьютер будет без устали 24 часа в сутки клепать акты и списывать бабло со счетов юр и физ лиц без суда и следствия - будет бесконечный поток актов и по теории вероятности больше законопослушных людей пострадают от несправедливости.
Да это походу всегда так было, такие вакансии были еще лет 10 назад. И тут статьи, была одна от Тим Лида из альфа банка - он там Тим лид, тех лид, пм и продукт овнер одновременно.
Разница между тех лидом и тим лидом очевидная. Первый читает книги по технологиям, а второй по психологии.
Не понятно только откуда рождаются такие описания вакансий - от руководителей или hr. И стоит ли вообще идти в компании, у которых в вакансии написана такая дичь.
Эмм, в смысле нет пользователей? Весь софт пишется для тех или иных пользователей.
Серьезно? Вы публикуете ip адрес брокера наружу без прослоек и даете любому внешнему пользователю подключатся к нему напрямую?
Такие, чтобы ответить на вопрос "где и почему сломалось"
Таки не вопрос, пускай сервис после брокера. Пускай поток событий - первичный источник. Вопрос в другом - пришел юзер и спросил "у меня тут состояние в БД не соответствует ожидаемому, почему?" И теперь надо пойти и найти где произошел сбой - это событие вообще не пришло? Или пришло, но брокер его не сохранил? Или сохранил и оно там зависло или попало в dead очередь? Или что-нибудь еще? И вот чтобы найти (или не найти) это одно конкретное сообщение среди миллионов других в брокере - это невозможно сделать без языка запросов, которого в брокерах нет.
По-моему гарантии доставки и первичное сохранение сообщения без потери - это немного разные вещи. Грубо говоря - что если сервер с брокером перезагрузится, потеряются ли входящие сообщения?
Первичное сохранение сообщения - это процесс между продюсером и брокером. Пока мы точно не убедились, что брокер получил сообщение, то ни о каком exactly-once / at-least-once речи быть еще не может. Это как бы вторая часть процесса - между самим брокером и консьюмером.
Следовательно там надо смотреть настройки и возможности конкретного брокера - есть ли write ahead log, бэкапы и все такое, что для реляционных БД являются общепринятыми вещами. Ну и очевидно, что если брокер пишет каждое новое сообщение в ahead log и сразу на диск, чтобы их не потерять - он не будет в разы быстрее БД, потому что механизм и задержки примерно одинаковые.
Ссылка на репо 404.
Я пожалуй никогда толком не понимал event driven. В моем понимании нельзя выложить доступ к брокеру сообщений в открытый доступ. Обязательно должен быть фасад (например тот же самый rest api).
Далее, все эти брокеры мне кажутся во первых менее надежными, потому что в них нет транзакций, да и в целом вопросы к тому, как они хранят данные. Во вторых внутри них нет языка запросов, чтобы что-то найти в случае ошибки или некорректного поведения в рамках бизнес процесса. То есть нельзя просто взять и вывалить все это юзеру на ui, чтобы он там искал свои загруженные или потерянные заказы.
В итоге я прихожу к другим паттернам - заказы мы складываем в БД, юзеру мы показываем на ui из БД со всякими фильтрами (с использованием языка запросов). Далее заказ у нас имеет статусную модель и конечный автомат. И прежде чем что-то отправлять в брокер сообщений - надо отразить это в БД (transaction outbox).
При этом есть статьи от того же Яндекса как они делали очередь на postgresql.
В итоге event driven и брокеры сообщений в частности - это такая штуковина сбоку, которые сами по себе работать не будут. Мало того, в aws cloud есть event bridge - тоже что-то вроде брокера сообщений, но микросервисы он дергает по rest api 🙃
В общем, вывод - оригинальная статья довольно поверхностная и нет оговорок про те моменты, которые подсветил я.
У нас на вакансию сениора (на сайте компании) за 3 дня было 300+ резюме. И там 99% все программисты с опытом и профильным высшим образованием. И 70-80% с требуемым списком скилов.
То есть по идее надо назначить примерно 250 собесов по 15-20 минут - это 1000 часов поговорить со всеми и выяснить насколько они наврали в резюме.
Так то ВСЕ резюме по последним бест практис - скилы, 2-3 страницы, жирным делают акценты, и достижения пишут по STAR. Все одинаковое, как под копирку.
Я не пойму это выдуманные истории?
Сдек работает на всю страну, клиенты и пункты выдачи по всей стране в разных часовых поясах. И вы не сталкивались с проблемами часовых поясов? И не знали что сервера и всякие логи должны быть в utc?
И что за синхронный REST? Синхронная авторизация? Что это значит? В Java веб сервера работают в один поток??
Есть еще master of Orion в виде настолки.
https://hobbygames.ru/master-of-orion
Что хочу и что могу себе позволить
Цены на видюхи так и не упали обратно
Возможно это не кандидаты стали хуже, а зарплата не менялась с 2022 года в соответствие с реальной инфляцией. Чат гпт дал оценку примерно 17%
Вот кто эти люди, кто придумывает такие штуки как
splitmix64, с магической белибердой, а оно потом еще и работаетНу тогда соискатели попросят чат гпт написать скрипт, который будет ходить медленно по html страницам, имитируя действия пользователя-слоупока.
Там видимо вопрос хранения таких данных и защиты от утечек. Но сейчас же есть электронные трудовые, видимо с доступом через госуслуги.
Но есть еще другой момент, например у меня последняя запись в трудовой в 2010 году.