сингл мастер - это когда есть конкретный _процесс_ который _для всех_ сущностей является single source of truth

А актор что блядь, не процесс?

нет, блядь, актор это памяти кусок в _каком-то_ процессе где-то на кластере

А что такое "процесс"?

ну которые по ps -ax видно, например

ну или так - процесс это что-то что слушает на порту, к которому ты можешь законнектиться по сети

там кстати еще прикол с определением что такое RT )
там написано что можно сделать заменять экспрешн на вэлью и "поведение программы не изменится" - что в данном случае поведение программы? ) как минимум такты процессора да и байткод будут разными)

Внешние источники энтропии есть всегда. Тайминги дисков, тайминги доступа к памяти, многопоточные гонки.

потому что фп это не ооп

В фп нет инкапсуляции, стейта

Человеческому восприятию более интуитивно думать о композиции объектов, а не композиции функций

Спасибо, что поделились.

Я продираюсь сквозь Агду сейчас, но очень греет знание, что на Идрисе можно написать веб-сервисы. Хочу этому научиться, чтобы делать прототипы экономя время на написании тестов.

Я не люблю асинхронное программирование. Нет, не так - я ненавижу асинхронное программирование.

Ладно, Javascript - там без асинков нельзя by design, но ведь в нормальных языках есть потоки и селекторы. Да, люди плодят поток на каждый чих, не умеют нормально пользоваться event'ами и семафорами, поэтому давайте бить по рукам за все потоки в принципе. Да, оно медленнее в несколько раз - зато рукожопые поделия не жрут память.

У нас были селекторы, которые умели работать с сокетами и файловыми дескрипторами. Нет, давайте сделаем универсальный реактор, который умеет и сокет, и файл и мьютекс и даже time sleep. А чего это он медленее? Странно, очень странно.

Я пользуюсь Tokio в Rust, потому что его пишут нормальные пацаны с руками из плеч. Мне очень нравится tokio, и я пользуюсь им чисто из уважения к прекрасному, закрывая глаза, что код начинает тормозить а borrow-чекер при передаче указателей в фьючер часто сходит с ума. Но в целом async programming - это как ORM. Со всеми вытекающими. Если можете не использовать - не используйте. Если у вас за плечами года опыта - вы справитесь, если вы пришли в async со школьной скамьи - он сломает вам мозг. Это тоже самое как начинать программировать с PHP.

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

Со скалистыми очень просто. Тупые и ленивые менеджеры из говноконтор типа Тинькова или Эволюшена нанимают их, клюнув на сказку, что те малым числом напишут мощный код.
Но скалисты вместо мощного кода меряются пипирками и обсуждают мангу и хентай 86% времени.
Их низкую эффективность доказывает тот факт, что их приходится нанимать ещё и ещё, ведь те, кого наняли ранее - нихера не справляются, вопреки сказке.

После джава 17 вообще непонятно зачем новый проект на скале начинать

Решили использовать mongodb для создания системы ГИС Торги (амазон только для гос организаций https://torgi.gov.ru/new ). Поисследовали, запилили прототип , в тч нагрузочный и все такое. В итоге осталиль довольны выбором. Систему успешно запустили в продуктив с 15.10.2021, пока полет нормальный.

Основные моменты:
+ Документная модель соответствует 1-1 объектной модели в коде приложения, поэтому сохранение данных очень простое и прямолинейное. В частности, в документе можно хранить вложенные документы и массивы, что значительно упрощает моделирование отношений 1-N, например, извещение - массив документов/картинок, извещение - массив лотов, протокол - члены комиссии, протокол - массив допущенных участников, протокол - победители и тд.
(в реляционке получается 100500 мелкиз таблиц, а тут один документ с вложенными документами)+ У нас теперь наша логическая модель которую делают аналитики и физическая модель - это одно и тоже.
+ нет OR-мапперов, как работаем с объектами в программе, так и сохраняем
+ поддердивает полиморфичность данных (можете в коллекции авто хранить легковые автомобили и грузовики - у них много пересечений по атрибутам, но есть и расхождения) и всякие характеристики/атрибуты (например, у нас атрибуты продукта зависяот от категории, атрибуты могут заполняться или нет)
в реляцуионке такое затрахаешься делать, если вообще можно сделать
+ можно делать всяки шардинги (правда это не всем актуально)
+ query language очень простой и понятный, есть mongo university с крутыми бесплатными курсами
+ у нас теперь больше нет DBA - все делают разработчики и это как лиду разработки мне сильно нравится, тк чем больше всяких ролей и специалистов - тем геморнее (ну немножко есть, но сильно мало)
+ в целом монга гораздо проще в работе и администрировании (может потому что сама по себе концепция проще), там просто меньшему числу элементов можно сломаться
+ легче делать катастрофоучтойчивость (нам предстоит), см например, доклад Юлы (ссылка ниже)
- в реялционке вы используете норамльные формы и часто если немножко меняются требования, то в целом БД менять не надо
в noSQL вы проектируете базу в гораздо большей степени затачиватесь под сцнарий использования, если сценарий поменялся то с большей вероятностью нужны будут изменения
например, у нас изначально планы приватизации включали в себя объекты приватизации и решения по объектам как вложенные сущности, тк не было требований с ними работать вне планов приватизаций
потом такие требования вскрылись и нам пришлось решения по планам приватизации выносить в отдельную сущность…
- мв думали что мы сможем использовать mongodb для поиска тоже, в тч для полнотекста, но оказалось что ее вохможности не очень широкий, например, полностектсовый индекс мб только один на коллекцию, фасетный поиск фиговый (нет bitmap индекса) , поэтому мы перешли на elastic

по поводу ACID:
- в монге обычно работаешь с целостной сущностью вклюбчающую в себя все зависимыве обхекты как вложенные - поэтому там все обновления и так атомарные, тх не нужны
- у нас вообще микросервиная архитектура и между микросервисами в принципе ACID - плохая затея, поэтома там это не надо… вз-е устроено через события и eventual consistency
- однако внутри микросервиса ACID очень удобен, тк мутить обновления через события и очереди - прямо звучит геморно
гораздо проще бац поставил @transactional и все работает ))
в принципе в монге теперь это есть и тоже можно пользоваться

по поводу распространенности
- см интересные доклад Юлы https://www.youtube.com/watch?v=ZLOFOxsDJIY&t=1686s
- MongoDB входит в top5 самых распространенных БД и уже используется на рынке более 10 лет для многих критичных систем - https://db-engines.com/en/ranking
- По опросам stackoverflow в 2020 mongoDB является самой востребованной технологией среди разработчиков ПО. https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-databases-wanted4
- на монго реализован https://www.joom.com/
- теперь еще и реализован ГИС Торги )))

и если челики соблюдают семвер