Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
Динамическая типизация (соглашусь, тут можно поспорить, сейчас почти везде есть инференс типов, но всё же), упрощённое ООП (не нужно даже писать геттеры/сеттеры по факту, не говоря уже о разных паттернах), огромное количество готовых/полуготовых решений для чего угодно - генерация файлов от изображений до пдф, аутентификации через сторонние сервисы, работу с геоданными в той же джанге подключить на раз два, достаточно заюзать геоджанго и постгис, легко делать простые дашборды с тем же dash или хотя бы фласком и тд и тп
>Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка. А может, дело как раз в этом?) В случае питона, зачастую, этого достаточно для мидла. А для собеса на джаву пойди выучи всю теорию работы jvm, ооп, разницу между версиями и в какой версии какие фичи можно юзать, а потом ещё будь добр уметь в круды (спринг, работа с бд и минимальный фронт, что на самом деле тоже огромная нагрузка).
Если вы имеете ввиду что брать в дополнение к вашему стеку для узких задач, то ответ классический - it depends. Недостатки будут в любом случае, вопрос в том, с какими из них вы можете позволить себе жить дальше с минимумом проблем. Например, в случае питона можно писать код на cython, который позволит убрать какие-то боттлнеки по скорости. В случае, если вам нужно написать сервис для вашего приложения, обрабатывающий огромное количество сетевых соединений, например чатик на вебсокетах, то, возможно, неплохим решением будет найти разработчика на том же go, если текущий стек имеет проблемы с этим. Всё зависит от задачи, от бюджетов, от штата разработчиков. Какие-то задачи уже вполне решены и оптимизированы на тех же сях или плюсах и имеют высокоуровневые интерфейсы - например, задачи машинного обучения или просто матлибы, которыми куда проще пользоваться из того же питона. Если у вас есть задача сверхбыстрого оптимизированного запроса для бд и штат из разрабов, умеющих в запросы, но не умеющих в бэк на вашем стэке - мб даже будет оптимальным решением решить этот вопрос на стороне бд в условных хранимках, кто знает, тут нет универсальных решений.
Сочетание "низкоуровневое программирование + отсутствие ГЦ + популярный ЯП + бизнес-логика" порождает противоречия и в дело вступают трейдоффы. Тут примерно такая же история, как и в случае CAP-теоремы для бд. Будет не лучшим выбором изначально писать бизнес-логику на плюсах (особенно, когда у нас есть выбор, а он у нас на самом деле есть, я объясню далее), потому что это низкоуровневый язык и мы имеем дело с массой объектов, которые мы всегда должны держать в уме помимо бизнес-логики. Что не так с бизнес-логикой? Условия меняются буквально каждый день и, соответственно, код будет меняться тоже практически каждый день. Например, код на плюсах будет окей для условного ядра новой базы данных, потому что там да - важна скорость и логика будет меняться не так быстро, потому что ядру базы данных плевать на изменения в обществе, плевать на какие-то новые законы, плевать на решения менеджмента, желания разработчиков/пользователей/кота и тд и тп. И вот помимо всего этого вам нужно думать о памяти, о синтаксических/семантических особенностях плюсов, что только увеличивает и время разработки и количество ошибок в коде. Почему же у нас есть выбор писать на других языках и что же мы такого важного забыли? Фреймворк для микросервисов (как постулируется в статье). Ещё раз, микросервисов. Не монолит, микросервисы. Что же нивелирует все профиты плюсов в контексте микросервисов? Правильно, сеть! Суть микросервисов - работа по сети и тут встаёт, соответственно, вопрос - а даст ли фреймворк на плюсах вообще хоть какой-то профит, когда большая часть ожидания уходит на сеть?
Как плюсы могут положительно влиять на поддержку кода, особенно где много бизнес-логики? Как?) Как?) Читаешь исходник через месяц, а там account.#$%&!÷%Delete(#)(,#@==_ dfr<>fromDatabase$#(÷[][(÷)...
>Эффективность по цпу. Ну ок, 3 плюсовика пишут эффективно, остальных бэкендеров перекинули с прекрасных выразительных языков со сборщиком мусора на плюсы и памяти больше нет, ага.
Дальше даже не хочется спорить, мне в принципе без разницы, опенсорс это конечно хорошо, но выглядит так, будто вы мне не как разработчику объяснить пытаетесь, а пытаетесь мне это продать, в принципе то же самое и в статье. Ну или это просто плюсовый стокгольмский синдром, не знаю, время покажет...
Объясните пожалуйста заплюсованность статьи, я не понимаю. В чем профит фреймворка для крудов на плюсах в 2022? Проще реализовать бизнес-логику? Может, быстрее таймтумаркет? Или стала проще поддержка кода? Или на волне хайпа плюсов на рынке много дешевых плюсовиков? Такое ощущение, что в штате яндекса просто скопилось много олимпиадников и менеджмент просто не мог придумать более толковой задачи, ну или я просто чего-то не понимаю.
Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
главное бассейн в яму не забыть
В кашу
Динамическая типизация (соглашусь, тут можно поспорить, сейчас почти везде есть инференс типов, но всё же), упрощённое ООП (не нужно даже писать геттеры/сеттеры по факту, не говоря уже о разных паттернах), огромное количество готовых/полуготовых решений для чего угодно - генерация файлов от изображений до пдф, аутентификации через сторонние сервисы, работу с геоданными в той же джанге подключить на раз два, достаточно заюзать геоджанго и постгис, легко делать простые дашборды с тем же dash или хотя бы фласком и тд и тп
>Вон, для приёма на стажировку по жава надо уметь наколотить вэб-круд на Спринге с бд и фронтэндом. Т.е. это достаточно просто даже для новичка.
А может, дело как раз в этом?) В случае питона, зачастую, этого достаточно для мидла. А для собеса на джаву пойди выучи всю теорию работы jvm, ооп, разницу между версиями и в какой версии какие фичи можно юзать, а потом ещё будь добр уметь в круды (спринг, работа с бд и минимальный фронт, что на самом деле тоже огромная нагрузка).
Если вы имеете ввиду что брать в дополнение к вашему стеку для узких задач, то ответ классический - it depends. Недостатки будут в любом случае, вопрос в том, с какими из них вы можете позволить себе жить дальше с минимумом проблем. Например, в случае питона можно писать код на cython, который позволит убрать какие-то боттлнеки по скорости. В случае, если вам нужно написать сервис для вашего приложения, обрабатывающий огромное количество сетевых соединений, например чатик на вебсокетах, то, возможно, неплохим решением будет найти разработчика на том же go, если текущий стек имеет проблемы с этим. Всё зависит от задачи, от бюджетов, от штата разработчиков. Какие-то задачи уже вполне решены и оптимизированы на тех же сях или плюсах и имеют высокоуровневые интерфейсы - например, задачи машинного обучения или просто матлибы, которыми куда проще пользоваться из того же питона. Если у вас есть задача сверхбыстрого оптимизированного запроса для бд и штат из разрабов, умеющих в запросы, но не умеющих в бэк на вашем стэке - мб даже будет оптимальным решением решить этот вопрос на стороне бд в условных хранимках, кто знает, тут нет универсальных решений.
Сочетание "низкоуровневое программирование + отсутствие ГЦ + популярный ЯП + бизнес-логика" порождает противоречия и в дело вступают трейдоффы. Тут примерно такая же история, как и в случае CAP-теоремы для бд. Будет не лучшим выбором изначально писать бизнес-логику на плюсах (особенно, когда у нас есть выбор, а он у нас на самом деле есть, я объясню далее), потому что это низкоуровневый язык и мы имеем дело с массой объектов, которые мы всегда должны держать в уме помимо бизнес-логики. Что не так с бизнес-логикой? Условия меняются буквально каждый день и, соответственно, код будет меняться тоже практически каждый день. Например, код на плюсах будет окей для условного ядра новой базы данных, потому что там да - важна скорость и логика будет меняться не так быстро, потому что ядру базы данных плевать на изменения в обществе, плевать на какие-то новые законы, плевать на решения менеджмента, желания разработчиков/пользователей/кота и тд и тп. И вот помимо всего этого вам нужно думать о памяти, о синтаксических/семантических особенностях плюсов, что только увеличивает и время разработки и количество ошибок в коде.
Почему же у нас есть выбор писать на других языках и что же мы такого важного забыли? Фреймворк для микросервисов (как постулируется в статье). Ещё раз, микросервисов. Не монолит, микросервисы. Что же нивелирует все профиты плюсов в контексте микросервисов? Правильно, сеть! Суть микросервисов - работа по сети и тут встаёт, соответственно, вопрос - а даст ли фреймворк на плюсах вообще хоть какой-то профит, когда большая часть ожидания уходит на сеть?
Как плюсы могут положительно влиять на поддержку кода, особенно где много бизнес-логики? Как?) Как?) Читаешь исходник через месяц, а там account.#$%&!÷%Delete(#)(,#@==_ dfr<>fromDatabase$#(÷[][(÷)...
>Эффективность по цпу. Ну ок, 3 плюсовика пишут эффективно, остальных бэкендеров перекинули с прекрасных выразительных языков со сборщиком мусора на плюсы и памяти больше нет, ага.
Дальше даже не хочется спорить, мне в принципе без разницы, опенсорс это конечно хорошо, но выглядит так, будто вы мне не как разработчику объяснить пытаетесь, а пытаетесь мне это продать, в принципе то же самое и в статье. Ну или это просто плюсовый стокгольмский синдром, не знаю, время покажет...
Объясните пожалуйста заплюсованность статьи, я не понимаю. В чем профит фреймворка для крудов на плюсах в 2022? Проще реализовать бизнес-логику? Может, быстрее таймтумаркет? Или стала проще поддержка кода? Или на волне хайпа плюсов на рынке много дешевых плюсовиков? Такое ощущение, что в штате яндекса просто скопилось много олимпиадников и менеджмент просто не мог придумать более толковой задачи, ну или я просто чего-то не понимаю.