Во первых могу поднять окружение с новым языком сам
Могу попросить написать простой алгоритм любую Copilot.
Мне не надо учить синтаксис нового языка - я могу его в крайнем случае загуглить.
Мне нужно знать экосистему и распространенные паттерны программирования. Те самые, которые показывают в твоем коде на Go, пришел ты из мира Java или из PHP.
Ни того ни другого, как я понимаю, тут нету. Вот и напрашивается риторический вопрос: ...?
Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Не надо путать причину и следствие. Наличие обработки исключений и некоторые другие элементы (например ключевое слово return) в большинстве современных языков программирования говорит лишь о том, что они нарушают принципы структурного программирования, а вовсе не о том, что без этих принципов нельзя писать программы. Можно!
Вместо исключений - монады maybe|result как в Расте или просто err как в Го, вместо return - возвращаем последнее значение из функции как в том же Расте. Удобно ли так писать? Вопрос открытый. Но то что так можно делать реальный софт - это факт
Исходя из моего опыта: если вы делаете межсервисное взаимодействие через graphql - вы делаете что-то не то. Более того: если ОБА сервиса - ваши, а не third party.
Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей. И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
А как пробиться в первые, если не из массовки? (Я не знаю как это работает, но почему-то думал что как раз кого-то в массовке замечают и приглашают потом на более и более ведущие роли)
И конечно же в любом языке с hof (я уверен что и в котлине, честно не знаю синтакс) это решается гораздо читабельнее:
data.flatMap(...).first(it.isSuccess)
И 99% примеров где нужен такой return или goto решаются каким-либо подобным очень простым и гораздо более читабельным способом.
И достаточно месяцок поупражняться с high order functions в хаскеле чтобы никогда в жизни в голове уже не возникала идея о необходимости раннего выхода, исключения, goto или чего-либо в таком роде.
Будучи сеньором, я:
Во первых могу поднять окружение с новым языком сам
Могу попросить написать простой алгоритм любую Copilot.
Мне не надо учить синтаксис нового языка - я могу его в крайнем случае загуглить.
Мне нужно знать экосистему и распространенные паттерны программирования. Те самые, которые показывают в твоем коде на Go, пришел ты из мира Java или из PHP.
Ни того ни другого, как я понимаю, тут нету. Вот и напрашивается риторический вопрос: ...?
В общем случае это не так и для Раста
#[derive(Default)]FooBar { foo: 42, ..Default::default() };И добавление поля так же закончится нулем или что еще хуже -
false, потому что строка 2 спокойненько скомпилируетсяИменно. Вопрос не в том сколько ошибок компилятор найдет. Достаточно одной, которую он не найдет...
Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Может я пропустил, но по-моему в статье нету: что не так с Kubeflow?
Это шаблон для генератора карт, генерирующий ее по определенным правилам.
Фактически это аналог просто карты в непошаговой стратегии.
Не надо путать причину и следствие. Наличие обработки исключений и некоторые другие элементы (например ключевое слово
return) в большинстве современных языков программирования говорит лишь о том, что они нарушают принципы структурного программирования, а вовсе не о том, что без этих принципов нельзя писать программы. Можно!Вместо исключений - монады maybe|result как в Расте или просто err как в Го, вместо return - возвращаем последнее значение из функции как в том же Расте. Удобно ли так писать? Вопрос открытый. Но то что так можно делать реальный софт - это факт
Исходя из моего опыта: если вы делаете межсервисное взаимодействие через graphql - вы делаете что-то не то. Более того: если ОБА сервиса - ваши, а не third party.
Еще раз объясняю:
Неделю назад у меня было совещание в 12 утра с Москвой из Израиля. У меня 12 утра и в Москве 12 утра. В выходные у нас поменяли время на зимнее, а в Москве - не поменяли. А теперь скажи, у меня это совещание должно переехать на 11, чтобы в Москве оно осталось в 12, или у меня должно остаться в 12, чтобы в Москве оно теперь начиналось в 13?
Совещание это отличный пример.
Например, я забил совещание с коллегой завтра на 10:00 (у себя)
У меня часы перевели на летнее время, а у него - нет.
В результате ваш хитрый софт покажет наши совещания с часовой разницей.
Но фишка то в том, что если завтра у меня часы переводят на летнее время и я делаю совещание на завтра, то у меня сохраниться ПРАВИЛЬНЫЙ utc с завтрашним летним смещением
У timestampz есть когнитивный оверхед когда начинаешь считать «вчера это было или сегодня» на бэке. Или когда у third party api принимается дата в utc. И эти баги случаются гораздо раньше чем «гипотетический другой клиент» который обычно не появляется никогда
Думаю что большинство читателей этой статьи используют базу для крудошлепства, и в этом плане у нее есть только один клиент - бэк.
Использование timestamp с хранением всех времен в utc полностью беспроблемное решение при таких условиях.
Во вьюшках utc переводится в нужную зону относительно клиента. Внутри бэка нету никаких разночтений и путаницы при операциях с датами и временем.
Можно конечно и заточиться, но если ты стартап с непроверенной гипотезой и сомнительным финансированием - ты хочешь писать быстро в прототипном стиле силами двух с половиной человек, а потом магически отмасштабировать решение на миллионы пользователей.
И это я сейчас про whatsapp + erlang | discord + elixir, подозрительно одинаковые истории успеха. И ВМ там очень помогла.
Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.
Тема RabbitMQ не раскрыта.
Что это значит?
А как пробиться в первые, если не из массовки? (Я не знаю как это работает, но почему-то думал что как раз кого-то в массовке замечают и приглашают потом на более и более ведущие роли)
На курсе будет сравнения RabbitMQ Streams и Kafka?
И конечно же в любом языке с hof (я уверен что и в котлине, честно не знаю синтакс) это решается гораздо читабельнее:
И 99% примеров где нужен такой return или goto решаются каким-либо подобным очень простым и гораздо более читабельным способом.
И достаточно месяцок поупражняться с high order functions в хаскеле чтобы никогда в жизни в голове уже не возникала идея о необходимости раннего выхода, исключения, goto или чего-либо в таком роде.
То есть эти сомневающиеся люди не могли бы посмотреть "НЕ слив, А прохождения тех кто купил в первый час релиза" и не покупать?