Вы из своего кармана платите за MS SQL?)
Не думаю что PostgreSQL, MySQL и т.д. не позволят вам создать качественное решение. А вот на оставшиеся деньги можно будет купить что-то действительно полезное, хотя бы рабочее время разработчиков или позволить себе разработчиков подороже.
Не понял причем тут модель акторов. Она хоть и имеет общие с ООП корни но различий очень много, хотя бы начиная с того что акторы обмениваются сообщениями(асинхронно) а объекты вызывают методы друг у друга(синхронно). И за счет асинхронности вы вряд ли сможете эффективно объединить несколько сообщений в одну SQL транзакцию в отличии от методов модифицирующих объекты, да и это в принципе не имеет смысла потому что акторы это принципиально более высокий уровень абстракции. А тема о SQL vs ORM.
Вижу в вашем возражении проблему в том что вы все же думаете в рамках ORM.
SQL запрос возвращает вам именно коттедж или их список а не граф. Что собственно имеет нативную поддержку во многих не ООП языках — другими словами тот же список кортежей.
Если вы хотите автоматического сохранения и другой обработки связанного графа сущностей как вам предлагаю некоторые ORM тогда да вам что-то близкое к просто SQL не подойдет. На моей практике данные встроенные возможности либо не эффективно работали и подходили для ограниченного набора задач или требовали написание обвязок на SQL-схожем языке для конкретной ORM, что сложнее обычного SQL запроса, который к тому же элементарно при написании проверить, минуточку тем же запросом в БД и не нужно писать сложные интеграционные тесты с моками (учтите ещё что под каждую ORM нужно изучать особенности её работы и ещё языка запросов).
А можно просто написать ещё ещё один sql запрос или объединить несколько уже существующих в транзакцию.
Есть ещё одно решение по мимо ORM, не использовать ОО языки или просто ОО возможности — тогда оно (ORM) не нужно. Просто работаете со списками, отображениями, векторами.
Собственно ими(списками, отображениями, векторами) и представлены различные структуры в большинстве БД(как в реляционных так и nosql) и протоколы передачи данных(например JSON).
Да можно, только это ответвление. Разработчики Clojure непосредственно уже не поддерживают CLR(на начальной стадии развития языка это было). Со всеми вытекающими.
Java развивается отлично. Просто есть нюанс, обратная совместимость, которая очень важна в долгоживущих проектах.
К тому же в Scala/Clojure это далеко за пределами доп. фич в C#.
Как я и писал у вас нет понимания отличий платформы и языка. Xamarin это .net? Это транслятор для C#.
О встраиваемых устройствах. Первая ссылка на WIndows 10 т.е. на OS. Вторая на что-то любительское и уже мертвое судя по активности.
Из нормального C#, VB.Net, F#, C++. В итоге что-то ощутимо используемое для разработки под .Net это только C#.
P.S. я писал о платформе и в статье обсуждается платформа .Net. Давайте ограничимся этим. Левые ссылки на что-то что просто связано с деятельностью MS, не нужно приводить в доказательство.
По итогу получается что-то на .Net есть, но в меньшем кол-ве чем под JVM и в основном худшего качества, кроме продуктов которые непосредственно поддерживаются MS. Если бы под .Net все было в реальности так хорошо как вы пишите. Я, да и многие кто сейчас использует JVM уже давно бы использовали эту платформу.
Простите но такого уровня поделки можно найти почти под каждый более/менее популярный язык. https://github.com/NETMF репозиторий говорит сам о себе.
К тому же это не серьезная система поддерживаемая на уровне свей платформы а любительская разработка.
Андроид: вычеркните пожалуйста .Net. Или по вашему в VM Android'а поддерживает стандартны .Net?
Встраиваемые устройства, устройства с ограниченными ресурсами: можно ссылку на ресурс MS, где написано что поддерживают данное направление?
библиотеки/Фреймворки почти на любой случай жизни: говорить что в .net все ок и хотя бы близко к тому что есть в мире JVM, это мягко говоря вранье.
Java, Scala, Clojure, Kotlin: что есть для .Net? #F использование которого реально можно найти только под микроскопом.
огромное сообщество: по сравнению с JVM сообщество у .net оно не большое.
отличная кросплатформенность: отлично что MS начало что-то в это направлении, пару лет назад.
P.S.
Мне кажеста что для вашего уровня понимаия платформа и языки под неё это одно целое, т.е. C# и .Net.
Минусануть и написать три слова просто. Написать развернутый внятный ответ, нет. Простите что задел ваши религиозные чувства.
За такие заголовки я бы заставлял их менять…
Про JVM:
Сервер-сайд, мобильные устройства(андроид), встраиваемые устройства и устр. обладающие небольшими ресурсами, библиотеки/фреймворки почти на любой случай жизни, много качественных языков Java, Scala, Clojure, Kotlin, огромное сообщество, отличная кросплатформенность. Что из этого есть у .Net? С аналогичным успехом можно перейти на любую другую платформу. Реальная конкуренция JVM|.Net существует только в устах маркетолога MS и студентов которых научили #C за счет агрессивного продвижения всяких курсов в университетах.
Про .Net:
Если вдруг что-то случиться с JVM что звучит смешно если знать о экосистеме что-то за пределами маркетинговых усилий от MS. То я лично предпочту что-то не связанное с MS, почему? MS, исторически доказано, демонстрирует стратегию -> захват рынка и внедрение максимум проприетарных стандартов, после прекращение всякого развития как следствие следствие, вспомнить хотя бы веб захват рынком IE, офисного софта(сейчас есть альтернативы и это круто). Крупный бизнес: Google, IBM, Amazon, Facebook, Oracle и д.р. никогда не переведет свои продукты на технологии от MS, потому что это означает зависимость от MS который может манипулировать развитием технологии и лицензиями для давления на своих конкурентов, хотя бы на рынке облачных технологий. Есть варианты конечно, это полностью открытое и переданное в руки сообщества развитие .Net, включая соответствующую лицензию. Но возникает вопрос зачем, когда есть JVM которая сейчас отлично развивается, которая реализована не только для сервер сайда но и для мобильных устройств(Android), в экосистему которой входят готовые решения почти на все случаи жизни, тщательно протестированные и проверенные годами.
Не понял о чем статья, может кто-то раскрыть мораль/суть? Больше похоже на художественное произведение с целью передать свои внутренние чувства-переживания чем на техническую статью.
Написать какую то чушь, "продуманная" структура которой развалится и обрастет костылями при первом изменении требований, может каждый криворук, что я собственно часто вижу в проектах. После они заявляют сие как гениальное, но не понятое творение.
А вот написать систему которая будет гибкой, с минимальным количеством богов и легко поддерживаемую могут едиными.
Handlersocket оказался аутсайдером. Он медленнее, чем Redis и Tarantool.
Пояснение:
Зато доступна ACID-модель, если ваш движок в MySQL её поддерживает. Доступна вся инфраструктура от MySQL: репликация, мониторинг, эксплейн, бэкапы. Можно строить сложные отчёты на обычном SQL.
Неплохо так сравнили kev-value хранилище и плагин к MySQL, т.е. то что он медленнее это сильный минус на фоне все его возможностей?)
Объективно Go как раз задумывался как язык с минимальным набором фич, для простоты изучения и понимания, как результат начинающим/в начале все кажется круто, когда вырастаешь все затягивается рутиной и хочется больших возможностей.
По этому вопрос вы почему выбирали Go, если эти цели были сразу очерчены — простой язык со встроенной простой работой моделью многопоточности что бы даже последний простолюдин мог написать работающий и читаемы код.
Для вас открыт весь мин, например jvm — Java, Scala, Clojure. Можете что-то другое поискать.
Не понял если честно когда смеяться.)
Один главный вопрос, сколько можно засирать харб статьями которым место на других ресурсах?) Ещё и теги: Спортивное программирование, Совершенный код, Разработка мобильных приложений, Разработка веб-сайтов
Хочется читать о чем то полезном, на мой субъективный взгляд должна быть тематическая диктатура потому что малыми шагами можно полностью уйти от технически полезных статей.
Не знаком с Elixir, но исходя из возможностей Erlang, думаю не учтены важные особенности которые дает Erlang VM, через модель акторов — fault tolerance и transparent distribution. А так же высокий уровень абстракции кода на Elixir.
p.s.
Не знаю где автор вычитал о производительности Erlang, об отличной утилизации мультипроцессорных система это да. Но не о максимальной производительности и низком потреблении памяти.
Не понял в чем суть приведенного кода как аргумента.
ООП не мешает ФП и можно встретить языки как с ФП+ООП так и в других комбинации. У вас похоже понятия о разных концепциях имеют отличное от, если так можно, выразится академического взгляда.
ФП это о функциях и их композициях — т.е. о поведении.
ООП это о организации — о изоляции и спецификации контрактов взаимодействия между объектами.
К тому же я вам дам одно важное пояснение если код вам не понятен то есть не одна а три причины:
Вы не знакомы с концепциями которые выражает этот код.
Кто-то просто плохо написал код. к
Концепция которая реализована в ЯП либо "плоха" сама по себе для данной задачи либо её реализация в языке.
По этому предлагаю вам:
Подумать какие из вышеописанных причин и в каком объеме влияют на код который вы видите,
Второе — поискать примеры в которых ФП дает бонусы.
Думаю из контекста понятно что фокус на open-source. Oracle есть кому продвигать. Тем более выступают авторы PostgreSQL и tarantool.
Вы из своего кармана платите за MS SQL?)
Не думаю что PostgreSQL, MySQL и т.д. не позволят вам создать качественное решение. А вот на оставшиеся деньги можно будет купить что-то действительно полезное, хотя бы рабочее время разработчиков или позволить себе разработчиков подороже.
Не понял причем тут модель акторов. Она хоть и имеет общие с ООП корни но различий очень много, хотя бы начиная с того что акторы обмениваются сообщениями(асинхронно) а объекты вызывают методы друг у друга(синхронно). И за счет асинхронности вы вряд ли сможете эффективно объединить несколько сообщений в одну SQL транзакцию в отличии от методов модифицирующих объекты, да и это в принципе не имеет смысла потому что акторы это принципиально более высокий уровень абстракции. А тема о SQL vs ORM.
Вижу в вашем возражении проблему в том что вы все же думаете в рамках ORM.
SQL запрос возвращает вам именно коттедж или их список а не граф. Что собственно имеет нативную поддержку во многих не ООП языках — другими словами тот же список кортежей.
Если вы хотите автоматического сохранения и другой обработки связанного графа сущностей как вам предлагаю некоторые ORM тогда да вам что-то близкое к просто SQL не подойдет. На моей практике данные встроенные возможности либо не эффективно работали и подходили для ограниченного набора задач или требовали написание обвязок на SQL-схожем языке для конкретной ORM, что сложнее обычного SQL запроса, который к тому же элементарно при написании проверить, минуточку тем же запросом в БД и не нужно писать сложные интеграционные тесты с моками (учтите ещё что под каждую ORM нужно изучать особенности её работы и ещё языка запросов).
А можно просто написать ещё ещё один sql запрос или объединить несколько уже существующих в транзакцию.
Есть ещё одно решение по мимо ORM, не использовать ОО языки или просто ОО возможности — тогда оно (ORM) не нужно. Просто работаете со списками, отображениями, векторами.
Собственно ими(списками, отображениями, векторами) и представлены различные структуры в большинстве БД(как в реляционных так и nosql) и протоколы передачи данных(например JSON).
Да можно, только это ответвление. Разработчики Clojure непосредственно уже не поддерживают CLR(на начальной стадии развития языка это было). Со всеми вытекающими.
Java развивается отлично. Просто есть нюанс, обратная совместимость, которая очень важна в долгоживущих проектах.
К тому же в Scala/Clojure это далеко за пределами доп. фич в C#.
Ни кто не мешает. Просто тогда вычеркните этот пункт из "все".
Как я и писал у вас нет понимания отличий платформы и языка. Xamarin это .net? Это транслятор для C#.
О встраиваемых устройствах. Первая ссылка на WIndows 10 т.е. на OS. Вторая на что-то любительское и уже мертвое судя по активности.
Из нормального C#, VB.Net, F#, C++. В итоге что-то ощутимо используемое для разработки под .Net это только C#.
P.S. я писал о платформе и в статье обсуждается платформа .Net. Давайте ограничимся этим. Левые ссылки на что-то что просто связано с деятельностью MS, не нужно приводить в доказательство.
По итогу получается что-то на .Net есть, но в меньшем кол-ве чем под JVM и в основном худшего качества, кроме продуктов которые непосредственно поддерживаются MS. Если бы под .Net все было в реальности так хорошо как вы пишите. Я, да и многие кто сейчас использует JVM уже давно бы использовали эту платформу.
Простите но такого уровня поделки можно найти почти под каждый более/менее популярный язык.
https://github.com/NETMF репозиторий говорит сам о себе.
К тому же это не серьезная система поддерживаемая на уровне свей платформы а любительская разработка.
P.S.
Мне кажеста что для вашего уровня понимаия платформа и языки под неё это одно целое, т.е. C# и .Net.
Минусануть и написать три слова просто. Написать развернутый внятный ответ, нет. Простите что задел ваши религиозные чувства.
За такие заголовки я бы заставлял их менять…
Про JVM:
Сервер-сайд, мобильные устройства(андроид), встраиваемые устройства и устр. обладающие небольшими ресурсами, библиотеки/фреймворки почти на любой случай жизни, много качественных языков Java, Scala, Clojure, Kotlin, огромное сообщество, отличная кросплатформенность. Что из этого есть у .Net? С аналогичным успехом можно перейти на любую другую платформу. Реальная конкуренция JVM|.Net существует только в устах маркетолога MS и студентов которых научили #C за счет агрессивного продвижения всяких курсов в университетах.
Про .Net:
Если вдруг что-то случиться с JVM что звучит смешно если знать о экосистеме что-то за пределами маркетинговых усилий от MS. То я лично предпочту что-то не связанное с MS, почему? MS, исторически доказано, демонстрирует стратегию -> захват рынка и внедрение максимум проприетарных стандартов, после прекращение всякого развития как следствие следствие, вспомнить хотя бы веб захват рынком IE, офисного софта(сейчас есть альтернативы и это круто). Крупный бизнес: Google, IBM, Amazon, Facebook, Oracle и д.р. никогда не переведет свои продукты на технологии от MS, потому что это означает зависимость от MS который может манипулировать развитием технологии и лицензиями для давления на своих конкурентов, хотя бы на рынке облачных технологий. Есть варианты конечно, это полностью открытое и переданное в руки сообщества развитие .Net, включая соответствующую лицензию. Но возникает вопрос зачем, когда есть JVM которая сейчас отлично развивается, которая реализована не только для сервер сайда но и для мобильных устройств(Android), в экосистему которой входят готовые решения почти на все случаи жизни, тщательно протестированные и проверенные годами.
Не понял о чем статья, может кто-то раскрыть мораль/суть? Больше похоже на художественное произведение с целью передать свои внутренние чувства-переживания чем на техническую статью.
Написать какую то чушь, "продуманная" структура которой развалится и обрастет костылями при первом изменении требований, может каждый криворук, что я собственно часто вижу в проектах. После они заявляют сие как гениальное, но не понятое творение.
А вот написать систему которая будет гибкой, с минимальным количеством богов и легко поддерживаемую могут едиными.
Вывод:
Пояснение:
Неплохо так сравнили kev-value хранилище и плагин к MySQL, т.е. то что он медленнее это сильный минус на фоне все его возможностей?)
Объективно Go как раз задумывался как язык с минимальным набором фич, для простоты изучения и понимания, как результат начинающим/в начале все кажется круто, когда вырастаешь все затягивается рутиной и хочется больших возможностей.
По этому вопрос вы почему выбирали Go, если эти цели были сразу очерчены — простой язык со встроенной простой работой моделью многопоточности что бы даже последний простолюдин мог написать работающий и читаемы код.
Для вас открыт весь мин, например jvm — Java, Scala, Clojure. Можете что-то другое поискать.
Я на секундочку подумал что вы о СИ.)
Не понял если честно когда смеяться.)
Один главный вопрос, сколько можно засирать харб статьями которым место на других ресурсах?) Ещё и теги: Спортивное программирование, Совершенный код, Разработка мобильных приложений, Разработка веб-сайтов
Хочется читать о чем то полезном, на мой субъективный взгляд должна быть тематическая диктатура потому что малыми шагами можно полностью уйти от технически полезных статей.
Не знаком с Elixir, но исходя из возможностей Erlang, думаю не учтены важные особенности которые дает Erlang VM, через модель акторов — fault tolerance и transparent distribution. А так же высокий уровень абстракции кода на Elixir.
p.s.
Не знаю где автор вычитал о производительности Erlang, об отличной утилизации мультипроцессорных система это да. Но не о максимальной производительности и низком потреблении памяти.
Не понял в чем суть приведенного кода как аргумента.
ООП не мешает ФП и можно встретить языки как с ФП+ООП так и в других комбинации. У вас похоже понятия о разных концепциях имеют отличное от, если так можно, выразится академического взгляда.
ФП это о функциях и их композициях — т.е. о поведении.
ООП это о организации — о изоляции и спецификации контрактов взаимодействия между объектами.
К тому же я вам дам одно важное пояснение если код вам не понятен то есть не одна а три причины:
По этому предлагаю вам: