Боюсь, это является продолжением последней флеймовой темы. Но сегодня до меня дошло, что может быть далеко не все осознают насколько серьезны будут последствия решения использовать в своем проекте модель акторов. И какое значение имеет выбор того или иного инструмента, предоставляющего поддержку акторов.
Это не выбор библиотеки для парсинга JSON-а или XML. Или AMQP-клиента.
И даже не выбор фреймворка для работы с низкоуровневыми событиями. Хотя, если вы заложились на libevent или libuv, а затем написали на них несколько сотен тысяч строк продакшен кода, то вряд ли вы просто так решитесь перейти на ACE или Asio.
Тут масштаб посерьезнее будет. Что-то близкое к выбору между FLTK, wxWidgets или Qt.
Для тех, кто далек от мира C++, полагаю, вполне корректной аналогией является выбор языка реализации для своего проекта между Erlang, Akka+Scala/Java или Haskell+CloudHaskell.
Сделав выбор в пользу одного конкретного фреймворка, единственный способ перейти на другой фреймворк -- это переписать все. Может быть даже серьезно перепроектировав по ходу дела.
Т.е. обратного пути нет от слова совсем.
Соответственно, если ваша работа с акторами ограничивается мелкими утилитами на выброс, то вам может быть все равно, что взять -- SObjectizer, CAF или just::thread Pro.
Но если инструмент ищется для разработки business-critical софта, которому предстоит жить не один год, в котором итоге накопится не одна сотня тысяч строк, а то и миллионов, и где со временем может не остаться никого из первой команды разработчиков, ситуация несколько иная. Тут, на мой взгляд, к выбору инструмента нужно подходить серьезно и оценивать кандидатов по целому ряду факторов. И далеко не факт, что легко доступный и красиво завернутый в привычную вам упаковку инструмент, сможет решать ваши задачи.
Мне понравились вопросы, которые задавал один товарищ на reddit-е (вот, например). Имхо, очень правильные вопросы. От ответа на которые и должен зависеть выбор инструмента. И если вы не получаете на свои вопросы приемлимых ответов, то какая нафиг разница, хостится ли проект на модном и молодежном сайте или же старые пердуны, вроде меня, периодически выкладывают свежие тарбары исходников на каком-то древнем ресурсе?
Ну и не могу не удержаться от характерного примера. Гораздо более известный, чем SO-5, C++ный фреймворк CAF живет на GitHub-е и имеет свою личную страничку, сверстанную в соответствии с современными дизайнерскими изыками (т.е. минимум полезной информации на максимуме занимаемой площади). Т.е. на первый взгляд все чин-чинарем. Хипстеры должны быть в восторге.
Только вот маленькая закавыка. Не дружит CAF с VisualStudio 2013 в принципе. Т.е. от слова совсем. И это принципиально, т.к. унутрях CAF-а настолько активно эксплуатируются возможности C++11, до которых VS может и в 2015-й версии не дорасти. Поддержка MinGW под Windows, насколько я помню, в CAF относительно недавно появилась. Так что если кто-то должен вести проект под VisualStudio и захотел применить CAF, то... То ему остается утешиться только тем, что CAF живет не на древнем SF, а на GitHub-е.
Тогда как на SObjectizer-е с допотопного SF.net вести разработку под VS можно было с самого начала. Как, впрочем, и под GCC на Linux-е. Чем я и мои коллеги активно пользовались, вполне нормально зарабатывая на хлеб с маслом. Что, как нетрудно догадаться, было бы несколько сложнее, будь наши проекты завязаны на CAF.
PS. За последние дни в рамках разработки версии 5.5.4 была добавлена фича, которая, вполне возможно, окажет сильное влияние на разработку с помощью SObjectizer. Это т.н. приватные диспетчеры, т.е. диспетчеры, которые создаются когда это нужно пользователю и автоматически уничтожаются, когда перестают использоваться. Это штука, которой в SObjectizer не было вообще никогда. В SO-4 диспетчеры создавались только перед стартом. Долгое время в SO-5 ситуация была такой же, и лишь недавно, в версии 5.4.0, появилась возможность добавлять диспетчеры к уже запущенному SObjectizer Environment, но изъять затем их было нельзя. А вот сейчас диспетчеров можно создавать по мере необходимости и убирать при ненадобности. Что делает сборку большого SObjectizer-приложения из независимых маленьких частей намного более простой и удобной.
Собственно, это демонстрация того, куда уходят те силы, которые тратятся на разработку SObjectizer-а. И на что делается акцент. Т.к., если в основу какого-нибудь business-critical приложения будет положен SObjectizer, то вопрос будет не в том, откуда качать его исходники. А в том, что и как можно будет делать с его помощью. В некоторых случаях это буквально граница между будет или не будет сделано.
Комментариев нет:
Отправить комментарий