при том что условно в москве 1С может получать указанную зарплату, а в каком то тьму-тараканове максимум что вы озвучили. И такое потому что местный локальный рынок.
Куда большая проблема — то, что эта вся “простота” пожирает память и ядра процессора, как не в себя.
Предположим, что ваше утверждение верно и наше джава приложение жрет память — вот цена в Орегоне на EC2 инстансы:
t3.nano 0,5 ГиБ 0,0052 USD за час
t3.micro 1 ГиБ 0,0104 USD за час
получаем разницу в 40 долларов в год, это меньше чем час работы среднего джависта в штатах!!!
Вроде все очень просто, но когда начинаешь отвечать на сложные вопросы, вроде
В доке есть ответы на эти вопросы.
так же никто не запрещает взять низкоуровневую кафку и работать с ней. Те джава тем и хороша что вы можете работать в разных парадигмах и выбирать уровень абстракции.
На деле при эксплуатации возникнет просто нереальное количество проблем, которые хорошо, если заметят.
на деле вы в реальном коде добавите ретрай, реагирование на разные известные типы ошибок и на все остальное и нет проблемы. Ну или давайте реальный пример проблемы которую в моем примере будет очень тяжело сделать а в Го легко. Просто я уже не один кусок кода рабочего запостил, а со стороны лагеря Го почему то пустота до сих пор.
так как вы написали вы успешно проглотили ошибку но у вас есть результат а дальше вы пошли работать с результатом. а вот в джаве с ее эксепшенами у вас все успешно упадет и реквест завершится с 500 ошибкой
Тогда концепция java "плохая", потому что позволяет делать пустые обработчики exception.
Не, это не так работает. Пустой обработчик это тоже обработчик. просто вы решили что вам эта ошибка не нужна. Это вполне рабочая ситуация в любом языке, в Го же вы получаете ошибку и результат одновременно
В Расте вы получили Result и с него вы можете достать либо ошибку либо хорошее значение, в джаве вы получаете или хороший результат либо ексепшен, а в го вы получаете всегда результат, есть там ошибка, нет ее там. и сделать по другому вы не можете.
Оно не используется как exception в java.
серьезно? Почитайте про парсер json имплементацию в Го, там оно во всю использовалось.
import io.quarkus.kafka.client.serialization.ObjectMapperDeserializer;
public class FruitDeserializer extends ObjectMapperDeserializer<Fruit> {
public FruitDeserializer(){
super(Fruit.class);
}
}
Incoming и Outgoing откуда-то дожны взяться.
# Configure the Kafka source (we read from it)
mp.messaging.incoming.fruit-in.connector=smallrye-kafka
mp.messaging.incoming.fruit-in.topic=fruit-in
mp.messaging.incoming.fruit-in.value.deserializer=com.acme.fruit.jackson.FruitDeserializer
# Configure the Kafka sink (we write to it)
mp.messaging.outgoing.fruit-out.connector=smallrye-kafka
mp.messaging.outgoing.fruit-out.topic=fruit-out
mp.messaging.outgoing.fruit-out.value.serializer=io.quarkus.kafka.client.serialization.ObjectMapperSerializer
Да, без них это будет страница кода, но это будет страница кода, безупречно отрабатывающая во всех ситуациях без неопределенного поведения и тихого заглатывания ошибок
понимаете на каждом из слоев я ловлю нужные ошибки, и логирование добавляется опять же одной строчкой. А в Го у вас страницы будут повсюду и разглядеть логику будет очень тяжело.
Да ну блин, я вам говорю про концепцию языка, который спокойно позволяет делать такие вещи. А вы считаете что это нормально. Я не знаю такого маразма ни в одном другом языке.
И?
то что в нутрях го это нормальный подход — паник/рекавери и это ни что иное как джава ексепшены.
проблема в том что вы написали лишь логику, а я всю обвязку с кафкой. те мой код реально уже и читает и пишет в кафку. ваш же содержит чистую логику.
Отличный пример, почему обработка ошибок в go вынуждает писать нормальный код. А если сеть на сервере совсем упала? Вместо результата будет тыква.
Это как пример был, что на любую ошибку мы забиваем и вернем значение по умолчанию, если надо обрабатывать конкретные ошибки или сделать предикат для обработки всеех ошибок то это не проблема.
Странно почему для SQS стоит галочка easy installation а для Кафки нет. Ведь можно взять AWS MSK и там все так же будет изи :)
при том что условно в москве 1С может получать указанную зарплату, а в каком то тьму-тараканове максимум что вы озвучили. И такое потому что местный локальный рынок.
кто доктор 1С-нику что он сам выбрал технологию, которая нужна лишь локальному рынку да еще и удаленка обычно не катит.
А как кто мониторит роксДБ в стримах, я так и не нашел способа получить метрики по памяти для нее.
Да, прочитали с топика, сделали бизнес логику по преобразованию сущности и записали ее в другой топик.
Вот что подключено сейчас
вот конфиг с кубера
у меня кваркус с кафкой в нативном моде комфортно работает потребляя 15-20 мб памяти, а в жвм режиме порядка 200Мб
а вам редис все равно нужен или вы подымаете кеш локальный в каждом сервисе, а потом думаете как его синхронизировать между всеми инстансами?
он лежит в редисе и не важно сейчас у вас 2 инстанса или 20
Для редиса я обычно использую
MessagePackпотому что жмет хорошо плюс Редис его понимает и можно вLuaскриптах его использовать.Те разницу по времени в разработке вы успешно пропустили и расходы посчитали только на память???
слышали
You Are Not Googleили во вашему весь мир запускает 10К серверов???Если мне надо микросервис на 10К инстансов и считать каждый мегабайт и цикл цпу то я возьму Раст.
Предположим, что ваше утверждение верно и наше джава приложение жрет память — вот цена в Орегоне на EC2 инстансы:
t3.nano 0,5 ГиБ 0,0052 USD за час
t3.micro 1 ГиБ 0,0104 USD за час
получаем разницу в 40 долларов в год, это меньше чем час работы среднего джависта в штатах!!!
В доке есть ответы на эти вопросы.
так же никто не запрещает взять низкоуровневую кафку и работать с ней. Те джава тем и хороша что вы можете работать в разных парадигмах и выбирать уровень абстракции.
на деле вы в реальном коде добавите ретрай, реагирование на разные известные типы ошибок и на все остальное и нет проблемы. Ну или давайте реальный пример проблемы которую в моем примере будет очень тяжело сделать а в Го легко. Просто я уже не один кусок кода рабочего запостил, а со стороны лагеря Го почему то пустота до сих пор.
так как вы написали вы успешно проглотили ошибку но у вас есть результат а дальше вы пошли работать с результатом. а вот в джаве с ее эксепшенами у вас все успешно упадет и реквест завершится с
500ошибкойну да, лучше на Го потратить неделю и написать
Войну и Мирдля этой простой задачи :)Не, это не так работает. Пустой обработчик это тоже обработчик. просто вы решили что вам эта ошибка не нужна. Это вполне рабочая ситуация в любом языке, в Го же вы получаете ошибку и результат одновременно
В Расте вы получили
Resultи с него вы можете достать либо ошибку либо хорошее значение, в джаве вы получаете или хороший результат либо ексепшен, а в го вы получаете всегда результат, есть там ошибка, нет ее там. и сделать по другому вы не можете.серьезно? Почитайте про парсер json имплементацию в Го, там оно во всю использовалось.
или вот наугал взяв https://github.com/golang/go/issues/30489
отличное поведение паниковать когда не можешь разпарсить жсон :))))
вот сериализатор
вот и все готовое приложение на кваркусе.
теперь ваша очередь.
понимаете на каждом из слоев я ловлю нужные ошибки, и логирование добавляется опять же одной строчкой. А в Го у вас страницы будут повсюду и разглядеть логику будет очень тяжело.
Да ну блин, я вам говорю про концепцию языка, который спокойно позволяет делать такие вещи. А вы считаете что это нормально. Я не знаю такого маразма ни в одном другом языке.
проблема в том что вы написали лишь логику, а я всю обвязку с кафкой. те мой код реально уже и читает и пишет в кафку. ваш же содержит чистую логику.
Это как пример был, что на любую ошибку мы забиваем и вернем значение по умолчанию, если надо обрабатывать конкретные ошибки или сделать предикат для обработки всеех ошибок то это не проблема.
так где же ваш чистый код? и сотни скрывающихся конструкций в Джаве?