Существует ли опенсорс аналог Spring для С++?

Аналоги, вероятно, есть для всех современных языков. А количество человеколет, посвящённых полировке, тестированию и развитию фреймворка — Spring не имеет равных.

Да, называется boost:)

Это просто библиотека, котрых сотни. Апликуху надо делать самому, склеивая все соплями.

Прочитал я это и задался вопросом

И ничего не нашлось?

https://www.javaspring.net/blog/c-web-framework-like-spring-for-java/

У Drogon больше всего ✅.

Вряд ли на языке без динамического пердолинга или рефлексии можно нормально такое сделать.
Можно в принципе сделать c++ фреймворк, управляемый из скрипта или огромного конфига, но нафига?

Какой именно функциональности этого кошмарища тебе не хватает?

Библиотек вида «сделай сам» на c++ полно, а готового решения уровня накидать пару классов, аннотаций и конфигов - получи web-сервер, rest с авторизацией, валидацией входящих данных, DI, удобной работой с бд и прочими удобствами нет.

Написать пару десятков строк конфигов, написать парочку классов — и получить до обеда работающий проект.

https://userver.tech/ https://habr.com/ru/companies/yandex/articles/474438/ https://habr.com/ru/articles/501330/

Нет и не будет.

Никто в здравом уме не будет писать бекэнд на C++ (есть несколько контрпримеров, но там либо адовое legacy типа как в недрах Amadeus, либо к здравому уму есть вопросы, либо и то, и другое). У бекэнда почти все задачи I/O bound (либо ждём БД, либо ждём другой сервис по API), при этом цена переполнения буффера или обращения по NULL указателю слишком высока (как минимум Denial Of Service, как максимум злоумышленник утащит все секреты и ещё и БД удалит).

Так что либо управляемые языки (Java, C#, да хоть Python с PHP), либо стильномодномолодёжные Go с Rust. Под них есть развитые популярные фреймворки.

У бекэнда почти все задачи I/O bound (либо ждём БД, либо ждём другой сервис по API), при этом цена переполнения буффера или обращения по NULL указателю слишком высока (как минимум Denial Of Service, как максимум злоумышленник утащит все секреты и ещё и БД удалит).

Широкое использование твердотельных накопителей данных вместо шпиндельных дисков разве не изменило время доступа к данным? Если это так, то сейчас ограничение скорости обработки данных должно ограничиваться временем доступа к оперативной памяти и вычислительной мощностью процессора, а не хранилищем данных.

Наличие/отсутствие DI в c++ взорвало мне мозг. Или в плюсах указатели запретили?

1. Ожидания сети куда деть?
2. SSD дороже HDD в 3-8 раз. Учитывая ненасытные аппетиты индустрии, потребность в памяти будет расти, поэтому HDD никогда не устареет.

Можно написать пару десятков строк конфигов, написать парочку классов — и получится работающий проект

С одной стороны, да. А с другой, этот проект будет жрать как не в себя.

Я тут на работе коклинистами сейчас руковожу, есть у нас сервис, который подписывается на 7 кафка-топиков и слушает инфу с них. Так вот - даже если нет никаких данных, эта хрень жрет 600 метров памяти и 20-40 процентов проца. И подумай - на сколько это оправдано.

У меня Firefox жрет примерно столько же. Это же не повод, чтобы его не использовать?

ps Кто такие коклинисты?

ps Кто такие коклинисты?

kotlin, язык такой.

Твой Firefox рендерит страницы, что достаточно дорого.

Яндекс, вроде как, двигается в ту сторону. Насколько я понял, продукт того бизнес-юнита, что Такси и Едой занимается.

https://userver.tech/

Предполагаю, по мере добавления новых возможностей рефлексии, будут расширять и докидывать удобств.

Это в Native они так собрали или в JVM?

Не подскажу, я туда не лезу. Мир джавы не мое. Я просто менеджерю и немного за архитектурой слежу.

Тебе же лучше, что ты туда не лезешь. 600M - это небольшая плата за то, что люди быстро тебе фичи реализуют.

Если бы они с такой скоростью на плюсах писали, тебе бы начальство по жопе било за проблемный сервис, который течёт по памяти, падает, светится на бордах, SLA не выполняет.

Плюсы требуют всё же вдумчивого программирования, чтобы реализовать свои преимущества и не течь, как…

Разве что Rust’лм можно Kotlin заменить, но ты столько Rust-программистов не найдёшь. Да и не факт, что они на Rust не смогут так же плохо написать.

JVM-based языки прощают многие проблемы «х-х и в прод» подхода и «возьмём в техдолг, сделаем быстрое решение» (а что такой подход у тебя есть - ты сам симптом назвал). На C++ у тебя бы за пару лет развития второпях разработка бы в техдолге утонула и вместо бизнес-фичей уходили бы в расчистку техдолга.

Я просто Java-бек и вижу, как те, кто потом быстро на повышение уходит, пишут код. И это не сказать, что плохо: он реально работает и делает, что нужно бизнесу, но вот вся обвязка (журналирование, мониторинг, аудит, трассировка - сразу в техдолг по максимуму). Часто ещё синхронные взаимодействия на 3-5 минут обработки понапилят, потом очень больно и долго переделывать. Причём ребята умные, но сам подход: «сделаем быстро, поправим потом» - вносит свои коррективы.

быстро тебе фичи реализуют

Если бы быстро ))) Ынтерпрайз не любит скорость. Надо добавить один эндпойнт? Ну, это дня 2 системного анализа, дней 5 разработки, дня 3 интеграционное тестирование, потом еще доку обновить.

Иногда прям сильно больно на это смотреть, вспоминая, как в стартапе такая же задача решается за час (само собой, тестируем на пользователях).

Главное, что бизнес принимает правила игры. Так и живём.

Единственная претензия к Spring это его черезмерная сложность. Уже заимел несколько несколько книг, общим объемом > 2k страниц. Мучают смутные сомнения, что не осилю, плюс еще яву надо будет учить, хотя говорят, после плюсов это не так сложно.

С другой стороны, зрелый продукт (23 года в проде), а мавен централ это просто слезы счастья на глазах после пердолинга со сборкой и интеграции либ в плюсах.

Не, я понимаю, сам в банковской разработке.

Но у нас 60-70% процентов времени не на разработку улетает, а на перекладку между контурами и бесконечные thisisunsafe на каждый CORS-домен на тестовом контуре, ибо ДИБилы-безопасники отозвали корневой сертификат для тестовых контуров.

А тестируем всё равно на пользователях, ибо процесс лишь на бумаге хорош, а по факту себе просто все бумажками жопу прикрывают, а реального тестирования нет (практически всё отдано на откуп ручным тестировщикам).

спринг это блоатваре в плюсах такое не приветствуется

спринг это блоатваре в плюсах такое не приветствуется

в плюсы просто забыли подвезти интроспекцию, рефлексию и прокси, как только подвезут, так сразу на свет появится десяток-другой спрингов (сколько сейчас в плюсах реализаций String?)

Никто в здравом уме не будет писать бекэнд на C++

Марк Цукенберг в лёгком недоумении.

чё это не приветсвуется, плюсцы сами по себе одно большое блоатваре

чё это не приветсвуется, плюсцы сами по себе одно большое блоатваре

Некто @zurg немного ранее:

По моему, вы меня всё-таки с кем-то путаете, я на лоре-то редко пишу и ещё реже критикую плюсы.

И где противоречие? Там есть ключевое слово «редко» - раз в пару месяцев можно и покритиковать. Тем более на лоре, тем более плюсцы заслужили, ещё как заслужили

(сколько сейчас в плюсах реализаций String?)

На проекте для текущего клиента сейчас три типа Vector используется (при этом проект стартовал в 2023-ем и сразу на стандарте C++20): std::vector, fbvector из Folly и еще один самодельный в виде надстройки над std::vector/fbvector. Этот зоопарк вызван соображениями эффективности, ну вот как-то один тип вектора не удовлетворяет всем требованиям, поэтому в разных местах разные приходится применять.

Я это к тому, что 25 лет назад можно было гыгыгать что мол в плюсах сколько проектов, столько и классов String. Но сейчас ситация уже немного другая и если проектом занимаются вменяемые люди, то запросто может оказаться несколько классов String (как и несколько классов Vector, так и несколько классов HashTable).

И где противоречие?

В «редко критикую». У вас что не выступление, то бросание говном в C++.

сейчас ситуация уже немного другая и если проектом занимаются вменяемые люди

ну а чего тогда Spring - это bloatware? Там точно также, если проектом занимаются вменяемые люди, то такого:

есть у нас сервис, который подписывается на 7 кафка-топиков и слушает инфу с них. Так вот - даже если нет никаких данных, эта хрень жрет 600 метров памяти и 20-40 процентов проца

никак возникнуть не может

Обычно я сишку критикую, и обычно в ответ на острый приступ какирной духовности «настоящих» сишников. И я б не сказал что это прям «бросание говном», но плюсы и правда язык бойлерплейт, в них же просто нет сколько-нибудь красивых и правильных частей, какие-то многолетние нагромождения фич скреплённых проволкой и изолентой поверх склизкого сишного основания.

Spring это же для тяжёлой бухгалтерии, зачем тут плюсы? Они слишком по сишному дырявые и от этой дырявости невозможно отгородиться, бессмысленно сложные и крайне херово читаемые. Жабо-шарпы, и современные реинкарнации в виде Go и каких-нибудь котлинов свифтов, сильно лучше подходят, а для совсем сложного и критичного расто-хаскели лучше подходят

Может из соображений эффективности это и оправдано. А вот из соображений бизнеса: кто занимается поддержкой этого зоопарка из 5 разных string у заказчика, а может в перспективе оказаться дешевле купить больше ресурсов в облаке и написать менее эффективный, но более унифицированный софт? Ведь стоимость услуг программистов которые могут не запутаться с 5 типами строк растет в условиях ИИ, а стоимость железа (ресурса облаков) падает.

ну а чего тогда Spring - это bloatware?

Мне кажется, что этот вопрос следует задавать тем, кто делает такие утверждения. Я не делал.

Там точно также, если проектом занимаются вменяемые люди

Вменяемые люди и ынтрырпрайз на Java… ;)

Шучу.

ХЗ, не имею отношения к разработке на Java уже лет 25. А когда имел, то Java сама по себе была еще тем тормозом.

в них же просто нет сколько-нибудь красивых и правильных частей

Красота в глазах смотрящего обычно.

Spring это же для тяжёлой бухгалтерии, зачем тут плюсы?

ХЗ. Мне иногда кажется, что людей каким-то боком из ынтырпрайза в C++ случайно заносит и хочется им иметь привычный инструментарий под рукой. И лень задумываться над тем, что C++ совсем другой зверь. И лучше бы снижать его использование (оставлять для совсем уж узких ниш), чем пытаться повторить в C++ какие-то моностроузные фреймворки из Java или .NET-а.

Spring это же для тяжёлой бухгалтерии

С чего такие выводы? Его используют и для АСУТП предприятия для управления оборудованием и роботами в реалтайм техпроцессов.

Может из соображений эффективности это и оправдано.

Применение C++ в современном мире оправдано всего двумя факторами:

• легаси, от которого нельзя отказаться и которое нереально переписать на чем-то модном-молодежном;
• эффективностью получаемого кода.

Если эффективность не важна, то и C++ не нужен.

А зачем тогда в новом стандарте вводят рефлексию и т.д., разве не для создания мощных фрейворков?

А огромное количество библиотек промышленного уровня? Тут конкурентов нет.

не имею отношения к разработке на Java уже лет 25. А когда имел, то Java сама по себе была еще тем тормозом.

25 лет назад книжки по жаве были в духе «а давайте напишем апплет крестики-нолики», оно с тех времен как-то очень далеко ушло в развитии.

Вменяемые люди и ынтрырпрайз на Java… ;)

ну у менеджера-оратора наверняка нет сомнений, что он вменяемый.

25 лет назад книжки по жаве были в духе «а давайте напишем апплет крестики-нолики»

Ну не 25 все же. 25 лет назад – 2001-й. Тогда уже была вполне себе J2EE с JSP, Java Beans и вот этим вот всем, а Java Applets использовались все меньше и меньше.

Крестики-нолики для апплетов – это уже 30 лет назад, 1995-1996-й, когда Java появилась и рекламировалась как средство создания тех самых апплетов.

А зачем тогда в новом стандарте вводят рефлексию и т.д.,

Для упрощения жизни программистов. По крайней мере я на это надеюсь, но, временами, терзают смутные сомнения…

разве не для создания мощных фрейворков?

Мощные фреймворки и так создаются (упомянутые выше userver или Drogon), только востребованность у них, имхо, не идет ни в какое сравнение с фреймворками для Java, .NET или JS.

Насколько понимаю, сперва люди стартуют с чего-то простого и распространенного, например, с Node.js, Django или RoR. Потом упираются в производительность и смотрят на что-то более мощное. Но до необходимости сменить RoR на Drogon доходят только проценты от начатых проектов.

Либо же делают продукт сразу с прицелом на большие нагрузки. Но таких контор, которые запускают условный Yandex.Taxi, не так уж и много.

В общем, ниша у C++ узкая, «востребованность» и «окупаемость» продвинутых фреймворков по типу userver гораздо ниже, чем в Java, .NET, JS, Python, Ruby и прочих технологиях с гораздо низким порогом входа.

Крестики-нолики для апплетов – это уже 30 лет назад, 1995-1996-й, когда Java появилась и рекламировалась как средство создания тех самых апплетов.

никак не могу врать здесь. Вот как сейчас помню: на втором курсе (как раз 2001 год) записались с другом на курс по жаве, типа модно-молодежно, да и в институте требовалось дополнительные курсы проходить. Я специально пошел и купил книжку по жаве, вот там реально были апплеты и крестики-нолики.

году в 2005 подсел на gentoo, в это время время был в линуксах был замес с переходом gcc с версии 2.96 на 3.x, апплеты в браузере ничерта не работали, потому что кому в линуксе нужен стабильный API, где-то неделю жаву собирал по крохам, но-таки собрал :)

Вот как сейчас помню: на втором курсе (как раз 2001 год) записались с другом на курс по жаве, типа модно-молодежно, да и в институте требовалось дополнительные курсы проходить.

Я в 2001-ом как раз работу сменил и пришел в аутсорсинговую компанию кодить на Java. И пришлось мне изучать J2EE и JSP, потому что Java тогда в энтерпрайзе уже была на server-side, а Web-морды делали на HTML+JS, но не на Java Applets (и, как мне объяснили более опытные коллеги, Java Applet-ы не взлетели по ряду причин, что в 2001-ом уже стало в Java-мире очевидно).

А до этого, на предыдущем месте работы году эдак в 1998-ом довелось смотреть в сторону Java Applets. Да и помню рекламные лозунги от Sun-а во времена выхода Java 1.0, когда Java Applets позиционировалась как киллер-фича. Это как раз 1995-й и 1996-ой годы.

То, что в 2001-ом году были книги по Java, которые рассказывали только про J2SE и апплеты – охотно верю, т.к. книги всегда отстают.

«Ну кроме того, что это модно-стильно-молодежно, могу сразу сказать, что как только вы им хоть немного овладеете — вы поймете сколько всякой разной работы вам теперь не приходится делать, и сколько всего берет на себя Spring. Можно написать пару десятков строк конфигов, написать парочку классов — и получится работающий проект. Но как только начинаешь задумываться сколько там всего находится «под капотом», сколько работы выполняется, и сколько пришлось бы писать кода, если делать такой же проект на голых сервлетах или на сокетах и чистой Java — волосы встают дыбом :)»

Делаю в последнее время проекты на чистой Java, волосы дыбом не встают. Spring не нужен. HTTP сервер, конечно, свой писать это перебор, хотя и можно. Но в Spring-е его и нет. Так что сравнение с сокетами идиотское. Сервлеты в принципе тоже дерьмище то ещё, как и всё, что связано с Java EE. А если взять любой HTTP сервер в виде библиотеки, лучше всего конечно тот, который для этого специально сделан - undertow, jetty, helidon, да хоть тот же com.sun.net.httpserver, встроенный в Java. То вполне себе всё пишется.

и, как мне объяснили более опытные коллеги, Java Applet-ы не взлетели по ряду причин, что в 2001-ом уже стало в Java-мире очевидно

позволю усомниться. HTML5 начал свое шествие примерно в то же время когда апплеты начали умирать (к смерти апплетов и Sun и Oracle приложили все возможные усилия за счет того, что игнорировали проблемы ИБ, в итоге их просто выставили на мороз), а где-то в районе 2000 - 2006 апплеты вполне себе имели право на жизнь, ровно как из флеш.

HTML5 начал свое шествие примерно в то же время когда апплеты начали умирать

ЕМНИП, тогда HTML5 еще и не пахло, коллега-фронтэндер пердолился с разными диалектами HTML для IE, Netscape и Safari (или что там было на Apple тогда).

а где-то в районе 2000 - 2006 апплеты вполне себе имели право на жизнь, ровно как из флеш.

ХЗ что они тогда имели. До 2001-го у меня доступа к Интернету практически не было, а когда появился, что-то Java Applet-ы на Web-сайтах встречались крайне редко. В отличии от Flash-а.

Повторюсь, что в книжках про Java в 2001-ом про апплеты могли еще запросто писать, особенно если книжки были из 1990-х. Но вот на практике Java в начале нулевых – это уже энтерпрайзный server-side чуть ли не поголовно.