пст, ergo

Это байтодрочерство, позволяющее пощупать что-то новое, интересное и жутко оскорбиться на вопрос «почему ты крадешь время у работодателя, делая какую-то ненужную фигню».


У эрланга модель данных и исполнения отражается в тех данных, которые ходят по интерконнекту. Те нода на сишечке получит пид или референс. Что с ними там на том конце делать?

Да ничего, они чужды для всех других платформ.

Кому-то не хватает банально возраста и опыта чтобы вспомнить, что в корбе вся эта херня с remote objects уже была и от корбы с ужасом отказались в пользу http+json в котором это все отсутсвует.

Использование bert/c-node между эрлангом и другими языками не дает никаких плюсов перед json, зато дает массу проблем, которые искуственные и очень заумные. Можно долго водить за нос доверчивого начальника, который не знает, как распознать архитектурного космонавта

Вот выбор между asn1/protobuf/thrift и json - он действительно есть. Он понятный, сложный, не имеет простого ответа, но там реально есть выбор.


Между json vs c-node никакого выбора на практике нет. Ну разве что есть задача спихнуть сложность, геморрой и жор cpu на коллег и изображать из себя дартаньяна

архитектурный космонавт - хороший термин

ок, не буду использовать c-node

@maxlapshin

"Вот выбор между asn1/protobuf/thrift и json - он действительно есть. Он понятный, сложный, не имеет простого ответа, но там реально есть выбор."

а тут можешь кратко рассказать?

Если нужен бинарный энкодинг — protobuf. Бинарный энкодинг в джавой — thrift. Бинарный энкодинг с сетевыми системами — asn1
Иначе — json

Asn1 нереально удобен при обмене между эрлангами. На порядок удобнее протобуфа и даже поддерживается под C

Есть даже опция с генерацией жсона.

Протобаф - современный стандарт. Он чудовищен в плане реализаций, так что мы увидим еще несколько итераций «давайте выкинем и сделаем нормально», но спорить с ним бессмысленно.


Оба они дают тебе гарантию и контракт на границе. В жсон/xml можно быстро подпихнуть что-нибудь еще и закрыть проблему за 5 минут. Статические схемы - это бюрократия на день (согласовать изменение схемы и тп).

Так что если проект должен принести деньги и сдохнуть за полгода, жсон без вариантов.


Если этому коду жить не один год или там сотни девелоперов, то без жесткой бюрократии и строгого схематоза будет больно.

понял. graphql тут не помогает в целом в отрыве от этого конкретного вопроса, возможно? в плане схематоза

Я с ним не имел опыта, но из того, что я читал, он тоже про жесткие контракты.

спасибо

благодарю

А что не так с протобафом под джавой? Н уто есть всякого много, но почему прям по дефорлу thrift если бинари с джавой?

Это формат запросов, а не энкодинга данных
Он вообще про HTTP скорее, и про описание вложенных запросов

Хотя конечно я лично знаю людей, которые бы первым делом сделали массив строк и туда бы пихнули строковое разложение жсона чтобы «нормально удобно гонять данные»

))

Потому что в мире джавы все традиционно используют thrift почему-то
Видимо из-за любви к апаче

Я думаю что протобаф не сложнее json, накладные расходы только на старте

Если у тебя 10 сервисов, которые используют твой сервис, то сложнее, как Максим и сказал, пока все раздуплят, изменят, рожь вот это все