Не знаю, не мне судить. Я адепт быдлокода. Это было скорее про то, кто и насколько привержен трушности парадигмы.
Как по мне это будет очень показательно указывать на то, что ни объектно-ориентированная, ни функциональная парадигмы в чистом виде не жизнеспособны.
P. S. По моему скромному опыту ни разу не встречался с тем, чтобы компилятор оптимизировал хвостовую рекурсию, да и вообще любую рекурсию в цикл и, честно говоря, даже не подозревал о подобных кейсах. Видимо по причине того, что я не часто использую рекурсии и не знаю ASM и машинный код, чтобы увидеть, что же там в итоге получится. Пойду почитаю что ль, спасибо, что подтолкнули.
Не знаком со свифтом, но ежели в нем условный .map() или .filter() не написан через хвостовую рекурсию с возвратом значения, то скорее всего он написан через for, который таки имеет состояние, к тому же мутируемое. Функции-то конечно скорее чистые, чем нет, однако же функциональная парадигма это в первую очередь про отказ от состояния и мутаций.
Хотя судя по тексту автор за разумное использование функционального программирования, так что с этим можно жить.
Это очень странная статья и не менее странные обсуждения в комментариях. У меня нет коммерческого опыта на Go, писал я на нем только для себя, один пэт до сих пор работает на нем, хоть это и бессмысленно, так что что-то написать я на Go смогу, но с большим спектром реальных проблем не сталкивался. Однако, к сожалению, есть опыт коммерческой разработки на Nest, но не стоит думать, что я защищаю инструмент и тем более делаю это из большой любви к нему. Nest отчаянно пытается быть фреймворком и Spring'ом от мира js/ts. Кое-где даже получается.
NestJS давал нам возможность быстро и удобно создавать приложения благодаря своей структуре и широкому набору функционала.
Nest - это не про быстрое создание приложений, в отличие от Spring Boot. Ручная компановка модулей мне нравится, но она создает дополнительные действия и не оставляет прав на ошибку с менеджментом провайдеров, импортов и экспортов. А для широково набора функционала нужны как дополнительные пакеты самого Nest, которые кстати не имеют общего роадмапа версий (простой пример - nest/core и nest/common 11 семейства версий, которые не поддерживаются nest/axios 4 версии), так и сторонние, которые к тому же имеют свойства прекращения поддержки (привет KafkaJS).
Компилируемый Go-код позволяет достичь высокой скорости исполнения приложений, что особенно важно при нашей работе с большими объёмами данных и множеством одновременных соединений.
В случае, если "проблемы" возникают после того, как код получил эти данные, с учетом выполнения большого количества "синхронных" операций, которые к тому же могут быть исполнены параллельно, проще говоря, если проблема точно не в производительности БД. Однако из прочтенного дальше я начинаю в этом сомневаться.
Благодаря строгой типизации и лаконичному синтаксису, код на Go становится проще для поддержки и рефакторинга, что снижает вероятность возникновения ошибок в критических местах приложения.
Лаконичный синтаксис Go это та еще тема для холивара, но как по мне больше дело вкуса, однако я бы не стал утверждать, что синтаксис Go упрощает рефакторинг и поддержку. Лично я считаю, что он слишком лаконичен в некоторых местах, настолько, что это скорее мешает и путает. Строгая типизация есть и в ts, при том сделать её можно настолько строгой, что Вам будет больно. Тут видимо речь была скорее про runtime type check.
Одним из центральных изменений стала смена базы данных – мы отказались от MongoDB в пользу PostgreSQL.
А есть какие-то объективные показатели, как миграция между разными СУБД повлияла на производительность без смены стэка языка программирования? То есть вы поменяли сразу две больших части приложения, почему тогда вы утверждаете, что проблема была именно в Nest, а Go стал той самой золотой пулей?
Это решение мотивировалось следующими причинами:
Проще говоря изначально Mongo не отвечал вашим потребностям и не совсем понятно, как и почему был выбран. Это хорошо, что вы нашли подходящее решение и системная или даже архитектурная ошибка была устранена. Не понятно только, какое отношение это имеет к отказу от Nest в пользу Go. На этом пункте есть ощущение, что команда просто решила поменять стэк по одной из причин: безнадежность, приход нового архитектора проекта, команда захотела научиться чему-то новому, расширить свой стэк и поднять свою ценность на рынке соискателей. Надеюсь, что дело не в последнем, ибо искренне не понимаю, почему за это действо платить должен бизнес.
Благодаря GORM, большинство рутинных операций по взаимодействию с базой данных стало лаконичным и структурированным, что позволило сократить время на разработку и устранение возможных ошибок.
TypeORM не справляется с простейшими рутиннымы взаимодействиями с БД? Я не спорю, что TypeORM достаточно тормознутый и сильно проигрывает работе через драйвер БД и понял бы, если бы именно производительность стала поинтом, но в чем преимущество времени на разработку и поддержку в случае сравнения двух данных ORM я не понимаю.
GORM предоставляет удобные инструменты для управления версиями схемы базы данных, что значительно облегчило процесс перехода и интеграции новых функциональностей.
С каких это пор TypeORM не поддерживает миграции? Это явно не преимущество, это базовый функционал каждого из инструментов. Если вы, конечно, использовали в качестве ORM ранее Prisma, я бы понял, но тут так же были бы вопросы к выбору инстументария изначально.
Использование ORM позволило организовать код по слоям — от доступа к данным до бизнес-логики, сделав архитектуру более прозрачной и удобной для поддержки.
Это вопрос компетенций команды, структуры и организации кода и архитектуры. Всё это вы можете сделать и с помощью TypeORM, так что плюс экосистемы Go.
Касательно приведенных далее плюсов Go я скорее согласен, но хотелось бы не читать их повторно, а увидеть что-то и про минусы языка, которые не понравились команде.
но и переосмыслить архитектуру приложения.
Это можно сделать и без смены стэка.
После перехода на Go с использованием PostgreSQL и GORM и Горутин многие из этих запросов стали выполняться примерно в 10 раз быстрее. В результате, ряд операций начинают завершаться менее чем за миллисекунду, что значительно повышает отзывчивость нашего сервиса.
И всё же, какое влияние на это оказала конкретно PostgreSQL? А точнее, какой припрост отдельно от PostgreSQL и отдельно от Go + GORM?
В общем-то я рад, что ваша команда переписала продукт, попробовала что-то новое, так еще и успешно. Однако же хочется понимать, как вы продали это бизнесу? Единственным возможным вариантом вижу, что вы пообещали прирост производительности в 10 раз и смогли в него попасть, заранее зная, что он будет примерно таким, а значит где-то в команде или компании уже были гоферы, при том достаточно опытные.
Дано: город в Сибири, имеющий "локально" GGC. Я и мой товарищ живем в соседних домах, метров 30 по диагонали, у каждого гигабитка от двух разных красных провайдеров. Имеем: у меня ютуб пока что работает отлично, у товарища не может и 144p прожевать, буфферизация каждые 2 секунды, однако всё остальное летает только так, это я видел лично. Лечится его ситуация проксёй или ВПН, который ему нужен по работе для удаленного доступа к закрытой корпоративной сети. При этом стримы на ютубе у него идут хорошо. Вопрос: уважаемые господа, особенно из РКН и Ростелекома, не кажется ли это немного подозрительно странным и не соответствующим ожидаемому поведению при описанной "проблеме"?
К томе же, если GGC это про кэширование, то не должен ли просмотр роликов с менее 100 просмотрами всегда быть отвратительно плохим, то есть и до "проблем с GGC"? А что ж тогда еще месяц назад оно себя так не вело?
Во-первых, Вы заставили меня зарегистрироваться на данной платформе исключительно ради того, чтобы ответить Вам. С учетом того, что я тут обитаю достаточно долго и желания завязать обсуждение у меня не возникало, Вы можете считать это своим небольшим личным достижением.
Во-вторых, Вы в корне не правы касательно взгляда на процесс труда. Не я ищу помощи, а компания. Я чудесно смогу кодить и без работы в компании (думаю у большинства разработчиков есть pet-project или даже несколько), а на поприще фриланса, по крайней мере в области front-end'а, достаточно работы, чтобы деньги на жизнь были, от простой вёрстки до SPA с возможностью выбора фреймворка. Развиваться я прекрасно могу самостоятельно, мои знания от компании тоже зависят в меньшей степени. Так что мне не нужна компания для постоянно работы. А вот разработчики ей нужны, без разработчиков компания не сможет создавать и поддерживать свои IT-продукты, получать прибыль, расти и развиваться. Открывая вакансию работодатель просит помощи у соискателя, предлагая обменивать время жизни человека на деньги во благо организации, выполняя поставленные задачи. Да компании и работники взаимозаменяемы. Но вот беда, без работников компания умрет, но без компании работник жить сможет. Я не должен вставать на место работодателя, это его дело и его проблемы, я выполняю задачи и получаю за это оплату, интересны компании и мои не пересекутся, и уж точно мои не станут ниже по приоритету. Я откликаюсь на просьбу о помощи, так что это не мне нужен работодатель, это мы его необходимы.
P. S. На данное мнение отвечать не стоит, в эту ветку я в любом случае не зайду и Ваш ответ не увижу. Всего Вам наилучшего и успехов.
Не знаю, не мне судить. Я адепт быдлокода. Это было скорее про то, кто и насколько привержен трушности парадигмы.
Как по мне это будет очень показательно указывать на то, что ни объектно-ориентированная, ни функциональная парадигмы в чистом виде не жизнеспособны.
P. S. По моему скромному опыту ни разу не встречался с тем, чтобы компилятор оптимизировал хвостовую рекурсию, да и вообще любую рекурсию в цикл и, честно говоря, даже не подозревал о подобных кейсах. Видимо по причине того, что я не часто использую рекурсии и не знаю ASM и машинный код, чтобы увидеть, что же там в итоге получится. Пойду почитаю что ль, спасибо, что подтолкнули.
Не знаком со свифтом, но ежели в нем условный .map() или .filter() не написан через хвостовую рекурсию с возвратом значения, то скорее всего он написан через for, который таки имеет состояние, к тому же мутируемое. Функции-то конечно скорее чистые, чем нет, однако же функциональная парадигма это в первую очередь про отказ от состояния и мутаций.
Хотя судя по тексту автор за разумное использование функционального программирования, так что с этим можно жить.
Это очень странная статья и не менее странные обсуждения в комментариях.
У меня нет коммерческого опыта на Go, писал я на нем только для себя, один пэт до сих пор работает на нем, хоть это и бессмысленно, так что что-то написать я на Go смогу, но с большим спектром реальных проблем не сталкивался. Однако, к сожалению, есть опыт коммерческой разработки на Nest, но не стоит думать, что я защищаю инструмент и тем более делаю это из большой любви к нему. Nest отчаянно пытается быть фреймворком и Spring'ом от мира js/ts. Кое-где даже получается.
Nest - это не про быстрое создание приложений, в отличие от Spring Boot. Ручная компановка модулей мне нравится, но она создает дополнительные действия и не оставляет прав на ошибку с менеджментом провайдеров, импортов и экспортов. А для широково набора функционала нужны как дополнительные пакеты самого Nest, которые кстати не имеют общего роадмапа версий (простой пример - nest/core и nest/common 11 семейства версий, которые не поддерживаются nest/axios 4 версии), так и сторонние, которые к тому же имеют свойства прекращения поддержки (привет KafkaJS).
В случае, если "проблемы" возникают после того, как код получил эти данные, с учетом выполнения большого количества "синхронных" операций, которые к тому же могут быть исполнены параллельно, проще говоря, если проблема точно не в производительности БД. Однако из прочтенного дальше я начинаю в этом сомневаться.
Лаконичный синтаксис Go это та еще тема для холивара, но как по мне больше дело вкуса, однако я бы не стал утверждать, что синтаксис Go упрощает рефакторинг и поддержку. Лично я считаю, что он слишком лаконичен в некоторых местах, настолько, что это скорее мешает и путает. Строгая типизация есть и в ts, при том сделать её можно настолько строгой, что Вам будет больно. Тут видимо речь была скорее про runtime type check.
А есть какие-то объективные показатели, как миграция между разными СУБД повлияла на производительность без смены стэка языка программирования? То есть вы поменяли сразу две больших части приложения, почему тогда вы утверждаете, что проблема была именно в Nest, а Go стал той самой золотой пулей?
Проще говоря изначально Mongo не отвечал вашим потребностям и не совсем понятно, как и почему был выбран. Это хорошо, что вы нашли подходящее решение и системная или даже архитектурная ошибка была устранена. Не понятно только, какое отношение это имеет к отказу от Nest в пользу Go. На этом пункте есть ощущение, что команда просто решила поменять стэк по одной из причин: безнадежность, приход нового архитектора проекта, команда захотела научиться чему-то новому, расширить свой стэк и поднять свою ценность на рынке соискателей. Надеюсь, что дело не в последнем, ибо искренне не понимаю, почему за это действо платить должен бизнес.
TypeORM не справляется с простейшими рутиннымы взаимодействиями с БД? Я не спорю, что TypeORM достаточно тормознутый и сильно проигрывает работе через драйвер БД и понял бы, если бы именно производительность стала поинтом, но в чем преимущество времени на разработку и поддержку в случае сравнения двух данных ORM я не понимаю.
С каких это пор TypeORM не поддерживает миграции? Это явно не преимущество, это базовый функционал каждого из инструментов. Если вы, конечно, использовали в качестве ORM ранее Prisma, я бы понял, но тут так же были бы вопросы к выбору инстументария изначально.
Это вопрос компетенций команды, структуры и организации кода и архитектуры. Всё это вы можете сделать и с помощью TypeORM, так что плюс экосистемы Go.
Касательно приведенных далее плюсов Go я скорее согласен, но хотелось бы не читать их повторно, а увидеть что-то и про минусы языка, которые не понравились команде.
Это можно сделать и без смены стэка.
И всё же, какое влияние на это оказала конкретно PostgreSQL? А точнее, какой припрост отдельно от PostgreSQL и отдельно от Go + GORM?
В общем-то я рад, что ваша команда переписала продукт, попробовала что-то новое, так еще и успешно. Однако же хочется понимать, как вы продали это бизнесу? Единственным возможным вариантом вижу, что вы пообещали прирост производительности в 10 раз и смогли в него попасть, заранее зная, что он будет примерно таким, а значит где-то в команде или компании уже были гоферы, при том достаточно опытные.
Дано: город в Сибири, имеющий "локально" GGC. Я и мой товарищ живем в соседних домах, метров 30 по диагонали, у каждого гигабитка от двух разных красных провайдеров. Имеем: у меня ютуб пока что работает отлично, у товарища не может и 144p прожевать, буфферизация каждые 2 секунды, однако всё остальное летает только так, это я видел лично. Лечится его ситуация проксёй или ВПН, который ему нужен по работе для удаленного доступа к закрытой корпоративной сети. При этом стримы на ютубе у него идут хорошо.
Вопрос: уважаемые господа, особенно из РКН и Ростелекома, не кажется ли это немного подозрительно странным и не соответствующим ожидаемому поведению при описанной "проблеме"?
К томе же, если GGC это про кэширование, то не должен ли просмотр роликов с менее 100 просмотрами всегда быть отвратительно плохим, то есть и до "проблем с GGC"? А что ж тогда еще месяц назад оно себя так не вело?
Во-первых, Вы заставили меня зарегистрироваться на данной платформе исключительно ради того, чтобы ответить Вам. С учетом того, что я тут обитаю достаточно долго и желания завязать обсуждение у меня не возникало, Вы можете считать это своим небольшим личным достижением.
Во-вторых, Вы в корне не правы касательно взгляда на процесс труда. Не я ищу помощи, а компания. Я чудесно смогу кодить и без работы в компании (думаю у большинства разработчиков есть pet-project или даже несколько), а на поприще фриланса, по крайней мере в области front-end'а, достаточно работы, чтобы деньги на жизнь были, от простой вёрстки до SPA с возможностью выбора фреймворка. Развиваться я прекрасно могу самостоятельно, мои знания от компании тоже зависят в меньшей степени. Так что мне не нужна компания для постоянно работы. А вот разработчики ей нужны, без разработчиков компания не сможет создавать и поддерживать свои IT-продукты, получать прибыль, расти и развиваться. Открывая вакансию работодатель просит помощи у соискателя, предлагая обменивать время жизни человека на деньги во благо организации, выполняя поставленные задачи. Да компании и работники взаимозаменяемы. Но вот беда, без работников компания умрет, но без компании работник жить сможет. Я не должен вставать на место работодателя, это его дело и его проблемы, я выполняю задачи и получаю за это оплату, интересны компании и мои не пересекутся, и уж точно мои не станут ниже по приоритету. Я откликаюсь на просьбу о помощи, так что это не мне нужен работодатель, это мы его необходимы.
P. S. На данное мнение отвечать не стоит, в эту ветку я в любом случае не зайду и Ваш ответ не увижу. Всего Вам наилучшего и успехов.