Pull to refresh
-17
0
Антон Нехаев @nehaev

Пользователь

Send message

Интересная статья, спасибо! По ходу чтения возникло несколько вопросов:


Планируем постепенно разделить получившуюся конструкцию на микросервисы, которые будут взаимодействовать через gRPC.

Почему выбор пал именно на gRPC?


В итоге получили скорость в 500–600 миллисекунд, что примерно соответствовало уровню приложения, которое мы переписали.

Был ли тогда смысл переписывать с JS на Java?

Цитата отсюда:


GDPR classifies an IP address as something that potentially counts as 'personal data', which is why we use that term in the Privacy Policy. This is necessary for two features being introduced in the next version of Audacity:
  • Automatic Updates — checking to see if there is a new version available
  • Error Reporting — an opt-in feature for users to send error reports to us

Т.е. они впилили фичи, которые есть наверное в большинстве популярных опенсорс программ с GUI, но видимо как-то неуклюже прописали это privacy policy.

Спасибо за статью! Было бы еще интересно добавить к сравнению logback, как все еще самый популярный фреймворк для логирования. Просто чтобы понимать, насколько порядков там все хуже.

Есть куски, взятые из документации, которые было сложно перефразировать.

А что все-таки имелось ввиду? Что за "множество обязанностей, которыми управляет JSON"? Можете своимим словами объяснить?


По поводу скорости компрессии — вот, думаю этого достаточно?

Так я писал не про скорость компрессии, а про отсутвие самой этой компрессии в protobuf. Да, будучи бинарным форматом, он конечно более компактен, чем текстовый JSON. Но реальный выигрыш будет сильно зависить от содержимого сообщений.

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

Откуда инфа, что protobuf что-то сжимает? Да, там используется "varint encoding", но в случае строк, насколько я знаю, никакого сжатия нет. По моему опыту, как раз таки строки составляют большую часть обмена между сервисами.


GRPC примерно в 7 раз быстрее REST при получении данных и примерно в 10 раз быстрее, чем REST при отправке данных для этой конкретной полезной нагрузки. В основном это связано с плотной упаковкой буферов протокола и использованием HTTP / 2 в gRPC

Можно ссылку на этот бенчмарк? По описанию складывается впечатление, что это сравнение не gRPC vs REST, а HTTP/2 vs HTTP/1.0 причем на специфических кейсах, где у HTTP/2 есть преимущество. Что мешает передавать JSON в стримах по HTTP/2?


Ускоряет передачу данных, удаляя множество обязанностей, которыми управляет JSON, поэтому он может сосредоточиться исключительно на сериализации и десериализации данных.

Сложно что-либо понять из этого предложения. Это точно не перевод?

Обвинение в организации травли.

Разве парень не добился чего хотел? Или его бывшего работодателя не утопили в говне? Вы любую констатацию фактов (в данном случае это было в контексте про позитивный финал для парня) называете обвинениями?


Обвинение в причинении морального вреда.

Вы бы хоть сами прочитали эту цитату до конца:


моральная травма у одного конретного человека от неадекватных угроз CEO

Приведите пожалуйста цитату, где я ставлю автору в вину вообще что-либо.

Какой очаровательный кейс балабольства. Сравнивать жертв насильственных преступлений с чуваком, который, испугавшись вмешательства адвокатов (в котором нет ничего незаконного, не то что насильственного), сам удалил свой трехдневный проект, а потом еще смачно мокнул своих обидчиков на весь интернет.


Если у этой ситуации и будут невинные жертвы, то скорее всего ими окажутся сотрудники Repl, которые пойдут искать другую работу в случае отзыва финансирования, и пользователи, которым придется продолжать испытывать трехдневные поделухи вместо полноценных сервисов. Лично я очень надеюсь, что бурление уляжется, все у всех будет хорошо.

Фраза CEO "у нас теперь куча денег, чтобы нанять топовых адвокатов, если понадобится" действительно выглядит неадекватной угрозой. До этого он вел диалог довольно адекватно.


Забавно выглядит троллинг паренька про техническую непохожесть его проекта, который он почему-то не вставил скриншотом:


image


Практически в каждом пункте "Да, я использовал такую же штуку, как у вас. А что еще по-вашему я должен был использовать?" Что за штуки там замазано, но похоже там речь про что-то более специфичное, чем git, bash, монитор или клавиатура.

Ну парень видимо добился чего хотел: его бывшего работодателя утопили в говне комментаторы на HN. Стоят ли такого бурления исчезновение из паблика трехдневной поделухи и моральная травма у одного конретного человека от неадекватных угроз CEO? Видимо, с точки зрения этого человека стоят. Надеюсь, те технические компании, в которые он пожелает устроиться в дальнейшем, будут разделять его широкие взгляды на этику и опенсорс.

Неициализированные поля, по-моему, в целом проблема дизайна

В целом согласен, но иногда бывает нужно ленивую инициализацию. А если отойти от Optional и просто поговорить о final-полях в джава, то с этим до сих пор довольно много проблем. Тот же хибер, который совсем не экзотика, форсит делать изменяемые поля. Надеюсь, новые record'ы, который immutable by design, улучшат положение дел, но врядли это произойдет быстро.


Для локальных переменных они, как раз, не нужны, потому что там nullability однозначно выводится.

А кем выводится? Я вот за то, чтобы выводилось компилятором. Optional для этого и сделан как раз.


Тут, увы, да, но в пределах API, скорее, nullа будут избегать (снова же, при удачном дизайне).

Возьмем например REST API. Насколько я знаю, при маппинге необязательных полей из Java в JSON и обратно, у вас два варианта — либо nullable, либо Optional. Как можно избежать null, если не использовать Optional?

Я ровно это и написал, с чем вы несогласны?

Ну если цель в том, чтобы минимизировать стектрейс то да, if вне конкуренции. Если цель — уменьшить вероятность NPE при помощи компилятора — я, уж простите, поеду с Optional.

Просто вы так написали, будто готовы уволить любого, кто isPresent() в коде напишет.

Я отвечал на "Optional никак не избавляет от проверок на null", что по факту не так. Использовать или нет — это воспрос стиля, принятого на конкретном проекте.


opt1.ifPresent(x -> opt2.ifPresent(y -> opt3.ifPresent( -> {...})))

Ну такой кейс во всей своей жести и на if'ах будет выглядеть неочень, особенно если есть else-часть.


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

Ну да, ifPresent — это для сайд-эффектов как раз и сделано. И да, есть плюсы и минусы. Но все-таки он вполне избавляет от проверок на null, о чем собственно и был изначальный тезис.

Optional не решает проблему с null. Её лучше решают nullability-аннотации

Непонятно, почему аннотации лучше. С использованием nullable-аннотаций, на мой взгляд, есть несколько проблем. Процитирую свой старый коментарий:


  1. нельзя отличить неинициализированное по ошибке поле от необязательного без значения
  2. аннотации для локальных переменных выглядят сильно хуже, чем Optional
  3. для null нет никаких средств композиции, для Optional есть flatMap

Мы обсуждали Optional в джаве, про котлин я ничего не говорил. Но если вы спрашиваете, как в аналогичном вашему кейсе в джаве обойтись без if(!optional.isPresent()) return, то очень просто:


void myFunc() {
  ...
  optional.ifPresent(x -> ...);
}

Конечно, если в целом окружающий код императивный, то лучше сделать if и return/break. Но если это какие-то преобразования на стримах, например, мой вариант будет более уместен.

Не дай Kotlin пинка, Java так и осталась бы без фич.

Это да. Поговаривают даже, что дженерики в пятую джаву завозил лично Бреслав :)

Что-то среднее между Java и Rust в смысле рантайма — это Go.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity