))
Ветка на форуме есть по ФП?

Предлагаю ТС поискать конкретную задачку под ФП.
Выше уже озвучивали. Я не максималист.

andreykaT
и у меня как то в голове каша получается.

Отсюда задача - выявить ОСОБЕННОСТИ ФП НА ПРИМЕРАХ.

mayton,
Да. Есть такая трудность.
У тебя были топики. Но они скорее про алгоритмы.
А автору подходы / архитектура нужна.
Пусть работает, ищет Akka hello world.
Мы не торопимся.

Это вы вывод сделали на основе того что я не перечислял историю развитие СУБД?
А где же презумпция невиновности? )))
- "не говори что я не знаю, если я об это не говорил" )))

Зашквар - это аргумент. ОК.

тебе вторым постом сказали - не бери из головы. Возьми из сети. У тебя произношение слабое.


переведи. Аутентификация? Авторизация? Юз кейс - "Приём на работу"?

Зачем?
Если ты про аутентификацию, то она отдельно совсем.
Не смешивай ее с БЛ никогда.
Считай что ЗАПИСЬ ЮЗВЕРЯ ЕСТЬ В бд.
Разбери юз кейс реальный.

забыл ник,
Как это ниже мешает ООП?
авторВ этих определениях собраны три основные черты того, что называют Serverless:

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

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

Эффективная стоимость. Если ваше приложение простаивает — вы ничего не платите, т.к. оно в этот момент не использует вычислительных ресурсов. Оплата же происходит только за время, которое ваше приложение реально работает.

Ограниченный жизненный цикл. Ваше приложение запускается в контейнере, и, спустя короткое время, от десятка минут до нескольких часов, сервис автоматически его останавливает. Конечно же, если приложение снова должно быть вызвано — новый контейнер будет запущен.
Стримы в шарп это Linq.
Никакого переворота и революции не сделали. Как пришли так и ушли.
Есть огромный сдерживающий фактор у облаков и собирания программ из кусочков.
Сначала вы грезили что будет тонкий экран клиент у всех. А Ось в облаке.
Потом грезили про ворд в облаке.
Потом грезили про микросервисы.
Потом про докеры.
Это ведь все админов касается. Развертывания. Управления ПО. А не РАЗРАБОТКОЙ ПО.
Почему EJB помер?
>И что там обсуждать?
Сначала выясни, это хрень академическая или революционная вещь?
Если второе то нужна ветка в форуме. Отдельная.

Отдельно от этого топика.
Ее асинхронно не сделать никогда.
Убери ее из топика и перефразируй вопрос свой.
Hello world найди. Пятый раз просят.

andreykaT,
Держи hello world Akka
Раз ты сам вторую страницу никак не родил.
https://medium.com/@ian.shiundu/building-a-fully-functional-rest-service-using-akka-actors-8b5c12978380

Что касается применимости модели акторов в архитектуре.
Это в основном асинхронный код, код на событиях.
Как это решается БЕЗ АКТОРОВ?
Очень просто - в веб короткие транзакции, меньше 0, 1сек
- в веб есть кеши
- в веб есть контейнер который параллелит.
Поэтому пример нужности акторов, это игровые серверы.
Там в модели каждая травинка это Актор.
Поэтому на старой модели все встанет.
Как то так... Имхо.