Опубликован выпуск Matrix-сервера Dendrite 0.1.0, который ознаменовал переход разработки на стадию бета-тестирования. Dendrite развивается основной командой разработчиков децентрализованной коммуникационной платформы Matrix и позиционируется как реализация второго поколения серверных компонентов Matrix. В отличие от эталонного сервера Synapse, написанного на языке Python, код Dendrite развивается на языке Go. Обе официальные реализации распространяются под лицензией Apache 2.0. В рамках проекта Ruma отдельно развивается вариант сервера Matrix на языке Rust, который распространяется под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53869
И на сколько Go быстрее Python?
В какой задаче?
В бизнес задаче.
быстрее
Перепиши на Go и узнаешь!
О, минусов накидали. Болит у питонщиков, болит...
Да, глупости обычно болит... Если бесцельно переписывать одно на другое, то может стать только хуже. Есть примеры, когда максимально оптимизированную по скорости разработку переписывали на Go и становилось хуже. Очень часто проблема не в ЯП, а в архитектуре, алгоритмах или внешних компонентах. Поэтому и спросили на сколько Dendrite быстрее Synapse.
Большой проект на python всегда тяжело сопровождать.
Большой проект это не просто, но не всегда тяжело. Это про Go можно сказать что там это точно всегда тяжело по очевидным причинам.
Как по мне наоборот -- это в Python по очевидным причинам и точно всегда (если проект реально большой). А вот про Go не понимаю. Буду благодарен, если поделитесь соображениями :)
Людям обычно не нравится когда им в глаза нагло врут, язык тут не при чём.
То есть, перепишет, но не узнает?
Нельзя сравнивать интерпретируемы и компелируемые языки, это разные инструменты для разных задач.
Это как сравнивать кувалду с молотком. Кувалдой легко ломать стены, но затруднительно забивать гвозди.По той же причине нельзя сравнивать Go и C++..
Разработчик ПО, это ремесло, и нужно уметь выбирать инструменты.
>Нельзя сравнивать интерпретируемы и компелируемые языкиМожно.
>Это как сравнивать кувалду с молотком. Кувалдой легко ломать стены, но затруднительно забивать гвозди.
И сам взял и сравнил.
Сравнивать можно и нужно всё. Сравнение это вообще самый базис интеллекта.
То есть, питонисты - это те, кто использует молоточек для ломания стен.
Для ломания стен питонисты привыкли использовать отбойный молоток C/C++ вместо ручной кувалды.
> Для ломания стен питонисты привыкли использовать отбойный молоток C/C++ вместо ручной кувалды.Неее, не примазывайся. Тот, кто переписал критичный по производительности фрагмент кода на C/C++ - это уже не питонист.
а кто?
"монолитном и полилитном.."
есть такое слово - полилитном?
Это новояз от неосиляторов C.
Кластер не модно.
В сербском языке есть. Означает политический.
Поллитровом -- Без поллитры не разберёшься.
Когда увидел схему - сразу понял, что либо питон, либо раст, либо го.
Переусложнение банальных, в общем-то, вещей у хипстеров - норма жизни.
Да тут комбо!
Переизобрели Fido могли бы просто взять готовое решение уже
Вы не понимаете! Там ациклический граф! Это очень круто! Потому что потому.
Гипертекстовый и векторный?
и что же ты там увидел? давай, по-быстрому, что тебе в этой схеме кажется банальным, но реализовано переусложненно?
Должна быть мешанина в коде, чтобы его невозможно было бы логически разделить на отдельные компоненты. Тогда будет невозможна схема, тогда со стороны всё будет выглядеть проще. Это как sendmail и postfix -- у постфикса куча компоненов, если их нарисовать на схемке, то ой-как-сложнааа выглядит.Это вопрос восприятия -- хомячки не в состоянии представить сложность ПО уже десятилетия как. Когда им пихают блоб и к нему страничку маркетингового буллшита описывающего функциональность, это выглядит просто и они могут спать спокойно не покидая пределов комфортной иллюзии о том, что окружающий мир прост и доступен для понимания. Но если этот блоб имеет структуру, которую возможно изобразить схемкой, то ой-ой, в схемке больше чем 7 плюс-минус два объекта[1], ой-ой, когниции не в состоянии переварить это одним куском, ой-ой, слишком сложно.
Хотя если есть опыт реального растягивания возможностей когниций до предела и за него, с осознанием своей неспособности понять всю сложность одним куском, то наличие такой схемки является скорее свидетельством в пользу того, что там всё гораздо проще, чем могло бы быть. Разработчики пытались применять принцип "разделяй и властвуй", не факт, конечно, что им это удалось, но они хотя бы пытались.
[1] https://ru.wikipedia.org/wiki/%D0%9C%D0%... *
[*] я помечу на всякий случай, что с моей стороны эта ссылка -- неудачная попытка пошутить: магическое число 7+-2 вызывает очень много вопросов сегодня, и, возможно, не более чем обычный психологический буллшит из XX века.
> магическое число 7+-2 вызывает очень много вопросов сегодняУ кого? Любой может провести мысленный эксперимент и обнаружить это ограничение человеческого мозга.
>> магическое число 7+-2 вызывает очень много вопросов сегодня
> У кого? Любой может провести мысленный эксперимент и обнаружить это ограничение человеческого
> мозга.Не "мозга", а "психики" (компилятор C не принимает произвольный unicode в идентификаторах, но мы же не говорим, что это ограничение процессора, так?). Мысленный эксперимент, в лучшем случае, покажет тебе ограничение твоей психики. На деле же, выясняется что это число сильно зависит от задачи, от того какими объектами надо оперировать, от опыта испытуемого решения таких задач и работы с такими объектами, от его настроения и возможно тысячи других факторов.
> На деле же, выясняется что это число сильно зависит от задачичто в свою очередь завязано на особенности соответствующих функциональных областей мозга, так что употребление "ограничения мозга" корректно, более того, с учетом того, что большая часть времени психикой называли вообще несуществующие сущности
>> На деле же, выясняется что это число сильно зависит от задачи
> что в свою очередь завязано на особенности соответствующих функциональных областей мозга,
> так что употребление "ограничения мозга" корректно,Да и нет. "Функциональные области мозга" -- это примерно такая же фикция из XX века. Некоторые задачи можно ассоциировать с определёнными областями мозга, но эта ассоциация неустойчива. Скажем, слепые используют зрительную кору для обработки звуковой информации. Некоторые люди восстанавливаются после инсультов, несмотря на то, что кусок коры у них умер -- происходит замещение, они начинают использовать другие части коры для выполнения тех же задач.
Из самых общих соображений можно сделать вывод, что возможности небезграничны, и если мы 99% нейронов головного мозга убьём, то психика не сможет восстановится до прежнего уровня. Но ограничения мозга и ограничения психики -- это разные вещи. Это вещи существующие на совершенно разных уровнях абстракции. Примерно как ограничения процессора, и ограничения программы, которая на этом процессоре выполняется. Иногда они связаны, иногда они даже одно и то же, но иногда -- нет. То есть в _общем_ случае это разные вещи.
И в _данном_ случае -- это разные вещи: способность читать такие схемы и понимать архитектуру программы -- это способность которая развивается. Эта способность ограничена не возможностями мозга, а знаниями, умениями и навыками, которые свойства психики, а не мозга.
Помнишь школьную термодинамику? В ней чётко разделяли микропараметры системы и макропараметры. Это очень важное разделение, потому что они описывают систему на разных уровнях. Мозг -- это физиология, психика -- это психология, это описания человека на разных уровнях и их _важно_ разделять. Иногда можно не париться, но в _данном_ случае, есть разница, именно поэтому я и указал на неё.
> что большая часть времени психикой называли вообще несуществующие сущности
И сейчас психикой называют несуществующие сущности. Но тут ведь вопрос в том, как ты понимаешь существование. Скажем люди очень любят доказывать, что свобода воли не существует. Если их методы доказательств применить креативно, то можно доказать, что не существует психика, не существует человек, не существует жизнь, не существуют макропараметры давление и температура, и вообще весь мир -- это квантовомеханический кварковый суп. Хотя он тоже не существует, потому что квантовая механика -- это теория, а теория существует только в психике человека, а психика человека не существует, как мы уже показали.
Если об этом интересно подумать, почитай Харари, его историю человечества. Она как история довольно сомнительна, но занятно то, как он эту историю наматывает на способности человека придумывать мифы и делать мифы частью реальности. Если ты вот эту его мысль поймёшь, то дальше ты сможешь направить эту мысль не вверх по уровням абстракции, а вниз, от обыденного понимания реальности к квантовой механике, и увидеть, что биология, химия, физика - это тоже такие же мифы, как и корпорация Пежо. С единственным возможным различием: наша религиозная вера в юриспруденцию делает корпорацию Пежо существующей, если мы прекратим верить в юриспруденцию, то корпорация Пежо прекратит существовать, но если мы прекратим верить в гравитацию, то яблоки не прекратят падать вниз. _Наверное_, не прекратят: в конце-концов, никто не этого проверял.
Кто сказал из говна и палок ? ;)
И вот этот вот конструктивный адешник
"пока рекомендуется использовать в монолитном режиме совместно с СУБД PostgreSQL для создания небольших исходных серверов (homeserver)"Мать-перемать.
Закопать и выкинуть. Или выкинуть, потом закопать.
Как по мне самое оно. Запустить на винде в виртуалбоксе это на хомесервере. А потом снести вместе с виртуалкой и виндой из-под которой запускали всё это.
Не, homeserver там в смысле homeserver системы, а не домашний обогреватель :)
Посыл в том, что в real world это счастье ляжет под своей монструозностью раньше, чем будет закончено.
"Использование SQLite пока не рекомендуется из-за нерешённых проблем с обработкой одновременных операций."Тоесть они всерьёз думают потом его рекомендовать? :))
Остановите планету я выйду.
Почему не рекомендовать sqlite, если у ваш свой небольшой узел (homeserver)? Synapse у меня сейчас на sqlite работает, потому что так проще, и этого вполне достаточно.
Попробуйтена dbase
Кто разбирается, объясните, как этим пользоваться?
Нахер оно тебе нужно ... это аноанизм технологический
> Нахер оно тебе нужно ... это аноанизм технологическийЧтобы по-онанировать технологически
Это ещё и для конченого пользователя предполагается. Ага, пользователь осилит в два клика. Настроит докерок, влепит образок, а после первого глюка полезет в кишки, и пораскинет мозгами... по всем ближайшим стенам
Хок, Докерок, ты не шей мне срок, машинка Торвальдса YAML-чку сломала.
По теме ! Рассово чистый шедоусокс вышел https://github.com/ShadowsocksR-Live/shadowsocksr-native
В чем смысл переизобретать Jabber/XMPP? Такая же федеративная сеть с равными узлами и шлюзами, ну зачем???Хоть бы до почты не добрались, свят, свят...
Если для чатика мне понадобится мейнтейнер кафки, разраб на го и еще кто-нибудь со знанием нутра вот этого вот супового набора - предложивший это отправится в пешее эротическое на гипрзвуковой скорости.
> В чем смысл переизобретать Jabber/XMPP?Ну, например, потому что он - xml-based (то есть блоатварь дырявая бай дизигн) г-но несовместимое даже само с собой?
Проблема не в том что они переизобретают жабер (они вовсе и не его переизобретают), а в том что у них получается вообще полный п-ц (ага, требующий kafka. Блжад.)
Херачь молнией, Г-ди, тут уже ничего не поправить.
А email вообще MIME использует. Говорят, однажды психиаторы видели человека, дочитавшего до конца RFC 2045, 2046, 2047, 4288, 4289 и 2049. Но вёл он себя как-то странно и всё время повторял: your bunny peace death...К счастью, никто другой эти RFC пока до конца не дочитал, чтобы всё переписать на Go и JSON, поэтому до сих пор всё работает.
> А email вообще MIME использует.хочет - использует. Причем остановившись в чтении ровно там где показалось удобно. Не хочет - не использует вовсе, ляпает stone-age plaintext.
Причем вот ведь что интересно - если и в майме не пожабиться на плейнтекстовую копию (а не "у нас в dnk произошла ошибка" (с)Paypal) - то оно будет _полностью_ взаимочитаемо - любителю майма удастся прочитать текстовую писанину, для нелюбителя будет текст "и еще какое-то ненужно вдесятеро большего размера рядом болтается", которое ему ничего не испортит.
о, мнение типичного иксперта опеннета подъехало, оказывает все, чем плох (нет) xmpp - это xml
а вот этот анон прав. в первую очередь xmpp был плох тем что его реализация была на неведомом п..це под названием ерланг, что не позволяло нормально его поковырять, а в процессе переписывания выплыло все подтаенное гно и был он послан массами. А в прочем был шанс.
>xmpp был плох тем что его реализация была на неведомом п..це под названием ерлангОткрой для себя Prosody и Openfire.
>не позволяло нормально его поковырять
Вот оно чо, Михалыч! И как только МС с Аппле зохватили рынок настолок.
Давай, расскажи мне про тысячи альтернатив в 2006м
Как там в прошлом?
jabberd, вроде, на православной сишечке был (или таки на крестах? запамятовал).
> Открой для себя Prosody и Openfire.Лично я был щаслив, перейдя на неведомый п-ц на эрланге - потому что ведомый п-ц на жабке - квакался под копеечной нагрузкой по пяти раз на дню с традиционным вывалом километра жабьих потрохов.
Или молча вис без видимых причин. Как повезет.Зная как устроен протокол - я, в общем-то, и не удивлен.
> плох тем что его реализация была на неведомом п..це под названием ерлангДай-ка угадаю, ты узнал, что ejabberd написан на эрланге, попытался понять, что это такое, обломался и объявил эрланг недостатком на основании того, что он недоступен твоему пониманию.
А он был плюсом?
> А он был плюсом?Да. Был и есть. Ты даже не представляешь, насколько весомым.
Ну хз, он ли был плюсом - но на нем, во всяком случае, написали демон, который даже почти не падал и не терял подключения.А на plain c - не написали, почему-то. Возможно, дело и не в эрланге, а в том, как надо ушибиться, чтобы вообще полезть такое разрабатывать, но контрольный эксперимент проводить не на ком.
Все проблемы от xml/html/tcp/c/c++ - надо срочно всё переписать!
А чем плох пох? Или пох не плох? Или плох не пох?
> xml-based (то есть блоатварь дыряваяКакие же уязвимости нашли в языке разметки?
И в чем недостаток XML-based протокола? Может в его расширяемости? И в каком месте XMPP несовместим сам с собой? Или ты про ядро XMPP и доп возможности коих миллион? Но и что тут плохого? Есть базовый XMPP, есть расширения, и только не надо за скорость обработки XML говорить(кстати ты это любому коммерческому серису скажи который SOAP-only),если в том же Matrix текстовый JSON пересылается поверх HTTP 1.1 карл!
В блоатпарсере.
Даже мерзкий JSON выглядит приличнее.
Более того, ему не сложно дать схему.
JSON со схемой которой как бы нет в принципе одни костыли будет отличаться от XML только кавычками <>, в чем суть?
в некоторых случая xml гораздо удобней, например, для добавления комментариев
Да-да, давай, фигачь в сетевом протоколе комментарии, а то принимающая сторона может чего-то не понять.
Несовместим сам собой XMPP с его бесконечнымы необязательными и местами невразумительными XEP-ами. В результате это самой расширяемости толком работало меньше фич чем даже в изначальном icq.
Та всем уже пофиг. Гугл как всегда справился на твердую пятерку - похоронил окончательно хорошую на то время технологию.
гугл похоронил все свои мессенджеры, в итоге юзеры андроида так и не имеют единого средства обмена сообщениями.
SMS
Это разве гугл придумал 100500 XEP для одного и того же, разве гугл клепал не совместимые друг с другом клиенты? Это всё авторы xmpp делали.
> Несовместим сам собой XMPP с его бесконечнымы необязательными и местами невразумительными XEP-амипримеры несовместимости и невразумительных XEP'ов в студию
> В результате это самой расширяемости толком работало меньше фич чем даже в изначальном icq.примеры таких фич в студию
Обмен файлами. Эти ребята придумали штук пять вариантов обмена файлами, в результате ни один не сделали повсеместным.
В актуальных клиентах устоялся HTTP File Upload, его и в Compliance Suite давно уже включили.
Чисто технически - XMPP - гибкий, настраиваемый, масштабируемый протокол. Платформа для построения систем обмена сообщениями. В теории - всё хорошо.На практике же всё оказалось не так радужно:
1. Идея с расширяемым протоколом и XEP-ами - провалилась. Ситуация, когда даже картинку послать абоненту проблематично (не факт, что его сервер поддерживает этот XEP, не факт, что клиент его поддерживает этот XEP) - это прям печаль. "Кто в лес, кто по дрова". Эту ситуацию можно описать одной фразой: "Этот функционал наверное есть, но это не точно".
2. То же касается истории хранения переписки на сервере, чехорда с приоритетами сессий и отсутствием синхронизаций между ними. Т.е. могла быть ситуация, когда сообщение приходит на мобилку, но на ПК ты его не увидишь.
3. Сложности с работой через мобильные сети - нестабильные каналы связи. Сообщения могли приходить несколько раз. Плюс морока с подтверждением отправки - тоже XEP и потому "оно есть, но это не точно".
4. Комнаты. Разрозненность по серверам. Т.е. есть одна комната на одном сервере, а на другом сервере - пусть и с таким же именем - это совсем другая комната. И если первый сервер ляжет - комната помрёт. Насколько я помню даже в IRC это не так и потому конференции в IRC живы и сейчас, а конференции в XMPP - не прижились.
5. Голосовая связь - про это даже и говорить нет смысла. Может быть у кого-то и работало.
6. Шифрование - так же как и всё остальное - если сильно захотеть, то можно настроить между абонентами, но это надо прям озадачиться.В чём плюсы матрицы:
1. Единая спека на протокол, формируемая FOSS-организацией - matrix.org (если я не путаю конечно)
2. сервера передают состояние, а не сообщения. Т.е. между клиентами всё синхронизируется.
3. Конференции "размазываются" по серверам, формируя "единое пространство". Т.е. состояние комнаты синхронизируется со всеми серверами, пользователи которых участвуют в этой комнате. И если даже самый первый сервер отключится - конференция продолжит работать. Сообщения формируются в виде цепочки-графа, стекаясь с серверов в единое дерево.
4. На мобилках работает нормально. Были эксперименты у разработчиков по улучшению ситуации, чтобы работа системы была возможна на совсем узких каналах (в эксперименте вроде был канал в 100 бод). В том числе с помощью CBOR.
5. Голосовая - 1:1 работает через COTURN (нормально работает, правда в новом клиенте там есть недочёты по ней, но это уровня баги/правятся). В конференциях - через модуль jitsi.
6. Шифрованием они прям озадачились и сделали, на мой взгляд очень хорошо - в том числе p2p шифрование в конференциях, поддержка нескольких устройств, сверка их через кросс-подпись, проверка отпечатков через QR/смайлы.
7. Ну и движение идёт. Спеки расширяются, реализация пилится, движение есть. Внедрения так же - вон правительство Франции на matrix перешло, немецкие военные тоже вроде перешли уже.
Сам протокол XMPP поддерживается всеми, есть опциональные XEP которые могут поддерживаться или нет, на то они и опциональные, если слить воедино ядро XMPP и XEP такой монстр получится которого на практике сложно будет реализовать
"Сам протокол XMPP" это уровень icq тысяча девятьсот девяностомохнатого года, а опциональные XEP породили бардак и бестолковщину. Фича есть, но это неточно.
ICQ годнота была, не гони на топчик
Картинки в XMPP сейчас отправляются абоненту через XEP-0363: HTTP File Upload.
И этот XEP конечно же равнобезглючно поддерживается всеми клиентами и серверами ?
На приём картинок — всеми.
> Картинки в XMPPКартинки в XMPP никак не стандартизованы и как их отправлять решает конкретный клиент.
> HTTP File Upload.
А это вообще финишь, мне что бы обменяться картинкой надо http сервер запустить на телефоне и открыть к нему доступ из интернета.
В каком из XMPP-клиентов не работает XEP-0363: HTTP File Upload?
прекращайте бредить. http открыт на сервере, картинка туда заливется клиентов по http post запросу , собеседнику или в групповой чатик направляется ссылка + миниатюра в MIME.
все живые и используемые клиенты это давно поддерживают
Я могу признать только сложности с синхронизацией, чтобы сообщения одновременно приходили и на телефон и на пк, а не одно из двух. Придумали какое-то расширение, но серверам оно не нравилось по какой-то причине (вроде можно было их задудосить с помощью него, но это не точно), из-за чего буквально любой аналог оказывался удобнее. Такие вещи нужно делать принудительными.
> Я могу признать только сложности с синхронизациейПоэтому jabber и помер.
> Я могу признать только сложности с синхронизациейА с конференциями разве не беда?
За столько буков - однозначно плюс. Странно, что столь мало до сих пор, но это видимо у местного студента пригорает. Ладно, пойду читать чо ты там понапесал.
Окей, прочитал. Да, XMMP -- это XEP если по-русски читать. Но матрикс - то еще говно. Знаешь чем они там озадачены? Модерацией. Да, пля. Мы с пацанами иного мнения. Свобода слова - мастхэв, модерация - мастдай. Мобилка имеет достаточно ресурсов для хранения всех твоих мыслей. Другие девайсы (включая твои собственные) могут это реплицировать. Fail-safety. Протокол общения пока ещё сырой, но мы работаем. Да, я буду держать вас в курсе.
> 2. сервера передают состояние, а не сообщения. Т.е. между клиентами всё синхронизируется.А точно? Звучит несколько избыточно.
Минусы Матрицы же не перечислены. А они начинаются уже с формата адреса и HTTP.
>> 2. сервера передают состояние, а не сообщения. Т.е. между клиентами всё синхронизируется.
> А точно? Звучит несколько избыточно.А что в этом избыточного? Вполне логично иметь на всех клиентах одно состояние.
> Минусы Матрицы же не перечислены. А они начинаются уже с формата адреса
Формат адреса @user:server такой потому что:
1. Это внутренний, "скрытый адрес" пользователя
2. "внешний адрес", т.е. адрес, по которому предполается искать пользователя - это должен быть либо адрес электронной почты, и/или номер сотового (смотря что укажет пользователь при привязке идентификатора к своей учётной записи). Эта привязка хранится на сервере идентификации, который даёт возможность поиска пользователя по всей сети серверов (но пользователь может этого не указывать и оставаться "более анонимным").
3. изначально планировалось "внутренний адрес матрикс-пользователя" не путать его с почтой - потому так он выглядит.
4. Втурненний адрес планировалось (не знаю как сейчас) сделать "отвязанным" от сервера, т.е. чтобы заходить под своей учёткой можно было на любой сервер федерации.> и HTTP.
НТТР выбран для удобства начального этапа. Далее могут быть и веб сокеты и всякое другое.
Вот например любопытное видео, где авторы матрицы пытаются заставить работать систему на каналах со сокостью 100 бит/с:
https://matrix.org/blog/2019/03/12/breaking-the-100bps-barri.../С другой стороны именно HTTP даёт разного рода хитрости, когда можно использовать матрицу как хранилище файлов, осуществляя доступ по прямой ссылке без авторизации:
https://matrix-client.matrix.org/_matrix/media/r0/download/m...Или же сейчас добавляют "пространства" (spaces):
https://youtu.be/TzUfS08lMek?t=1274
И там вопрос стоит так, что матрицу можно будет представить вообще в виде некоего распределённого децентрализованного хранилища, где "директории" будут "пространства", а "файлы" - потоки данных (комнаты).
А в силу того, что на базе матрицы пробуют сделать аналог твиттера:
https://matrix.org/blog/2020/12/18/introducing-ceruleanТо подобный расклад можно даже назвать неким "иерархичным децентрализованным вебом 3.0".
Ничего, доберемся однажды и до почты. Впрочем, мы не хипстеры =)
> код Dendrite развивается на языке Goкогда уже я напишу реализацию на сишечке, больно смотреть на этот адъ
Что за предвзятость? Как-то это не профессионально.
> при помощи внутреннего HTTP APIВнутренний мог бы быть и бинарным, через что-нибудь попроще, чем http.
> и платформы Apache KafkaНу блиииин... Оно ещё и жабамашину с собой тащит...
Может хоть в нём будет нормальное логирование ошибок.
Если сломаться Synapse, он будет молчать о причине поломки как партизан.
"причина поломки: где-то в программе баг"
Так лучше стало?Или может ты прямо собираешься его ЧИНИТЬ? Может еще и кодить умеешь? (хаха, конечно пошутил, иначе ты давно запилил бы себе такой лог ошибок, какой тебе нужен)
некоторые вещи и на фортране быстрее
тут жеж была статья со сравненнием
Увидел ссылку на новость, "Пожалуйста, ками-сама, только бы на Си, или на плюсах!! (>_<)", открываю:
>> эталонного сервера Synapse, написанного на языке Python, код Dendrite развивается на языке Go- FFFFFFFFFFUUUUUuuuuuuu :_(
> Увидел ссылку на новость, "Пожалуйста, ками-сама, только бы на Си, или на
> плюсах!! (>_<)", открываю:
>>> эталонного сервера Synapse, написанного на языке Python, код Dendrite развивается на языке Go
> - FFFFFFFFFFUUUUUuuuuuuu :_(Учитывая, что матрица развивается "вот прямо сейчас", налету обрастая концепциями (см. мой коммент выше: https://www.opennet.me/openforum/vsluhforumID3/122079.html#123 ), то писать реализацию на достаточно затратном по времени разработчика языке - именно в данный момент - нерационально (моё предположение). Логичным видится написание концептуального сервера на более быстрым для разработки/рефакторинге языке, отладки всех концпций, а уж потом, вторым/третьим этапом реализация минималистичных по использованию ресурсов серверов на более "тяжёлых" для разработки языках.
Причём, как я понимаю вторым этапом выбран Go, для реализации задачи второго этапа: "запуск в виде несколих процессов" для балансировки нагрузки на больших высоконагруженных конфигурациях.
А вот третим этапом будут, возможно, буду смотреть на C++ пристальнее, т.к. идут разговоры в том числе о p2p, где один-клиент - один сервер.
> Учитывая, что матрица развивается "вот прямо сейчас", налету обрастая концепциямиПонимаемое, конечно, предположение. Не у всех есть такая команда как у тгм. Ну и я не знаю, насколько сложно/громоздко писать на современных плюсах и тулкитах в сравнении с аналогичным на go/питоне.
>> Учитывая, что матрица развивается "вот прямо сейчас", налету обрастая концепциями
> Понимаемое, конечно, предположение. Не у всех есть такая команда как у тгм.
> Ну и я не знаю, насколько сложно/громоздко писать на современных плюсах
> и тулкитах в сравнении с аналогичным на go/питоне.На Go особо не писал (мелкие патчи не в счёт), а вот сравнивая питон и Си/C++ - питон конечно более быстрый язык разработки с точки зрения времени программиста.