а вот эти вот монады, позволяют поддерживать код в рабочем состоянии

не увеличивая сложность понимания

не надо недооценивать эти "мелочи"

они складываются

"ой, а я докуплю лишнюю ноду" кмк непрофессионально

имхо, наша работа делать так что у бизнеса было хорошее соотношение цены/бизнес велью

а дрочить на байты, это к тем кто пишет драйвера или jvmку

я ничего не имею против монад, тайпклассов и тд (разве что иногда), я за баланс усилия/профит

стдлиба — одно из тех мест, которое очень выигрывает от микрооптимизаций, тк юзается везде, в тч и в запросах к бд

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

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

нет монад — нет оверхеда

ибо тупо добавить елемент в конец списка = переписать всю цепочку указателей

нет монад — нет оверхеда

вам сюда https://golang.org/ ?))

ну боксинг туда-сюда — зло же

там специализация вроде как есть

вам сюда https://golang.org/ ?))

недавно решили в 100% скала кодбазе написать одну штуку на го, я был инициатором

диагноз ясен ))))

у го свои минусы, у скалы свои

ну просто писать хайлоад байтодроч на скале, это какбы, извращение

в итоге, упретесь в gc джавы

а код превратится в непонятно что

да в этом и киллерфича скалы, можно варьировать абстракции от фримонад на шейплесе до подсчета байтиков и полной мутабельности

В Гц? %)

намекаете на отключение gc и покупку 256 гигов оперативки с рестартами раз в день?)

просто gc, это та часть, на перфоманс которой вот уже точно не повлиять, она будет время от времени фризить приложение

как бы у вас еффективно память бы не рассходовалась

эм, нет

Намекаю на то что заявление с потолка.

окей

не, ну если на каждой итерации по 1000000 списку делать аллокации, то офк будет

но можно же нормально писать

Кто нибудь мапил play-json валидации в wix accord?

Намекаю на то что заявление с потолка.

ну память то надо дефрагментировать как-то, мое заявление сделано на основе опыта компании, пишушей hft на джаве, и отключивших gc в итоге по понятным причинам

Я не говорил что это невозможно. Но это далеко не единственная причина. И зависит очень сильно от конкретного кейса.

"в джаве можно упереться в гц, поэтому можно забить на оптимизации" — в корне неверная позиция

моя позиция, что для разных задач есть свой инструмент

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

манипулировать миллионными коллекциями, это в принципе не кейс приложения в основном, для этого есть бд с индексами

но если у вас такие задачи, то я по хорошему завидую, это весело должно быть)

для каждой задачи кеша будешь поднимать редис?

казалось бы, что может быть сложного у обычного лру кеша

менеджить внутренний стейт = повысить сложность масштабирования

то есть да?

hazelcast нужно выкинуть значит

в какой компании такое происходит?

зависит от того сколько мне кеша надо

в какой компании такое происходит?

wix, autoscout

apache ignite тож на джаве писан - гавно, нужно выкидывать

троли подтянулись)

хотя там некоторые террабайты в инмемори хранят

проще взять мейнфрейм

hazelcast нужно выкинуть значит

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

менеджить внутренний стейт = повысить сложность масштабирования

а вынос стейта наружу не решит проблему, всего лишь отложит ее на некоторое время

я думаю редис легче масштабировать и поддерживать чем ваш милый самопис

хотя там некоторые террабайты в инмемори хранят

если экстраполировать (совсем немного), то @Arhelmus считает, что вообще джава выступает сугубо прокладкой между базами и тд

акка позволяет удобно менеджить стейт

ну ладно, что

если экстраполировать (совсем немного), то @Arhelmus считает, что вообще джава выступает сугубо прокладкой между базами и тд

перегонялка json в xml с бизнес рулами и калькуляция промежуточного результата, как хадуп например

да, весело у вас там

акка позволяет удобно менеджить стейт

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

>джава выступает сугубо прокладкой между базами Согласен на 98 процентов.

щас тут начнут вести список формошлепов, пороху не нюхавших)

Это еще у Мартина Одерски так выступление work hard to keep it simple начиналось, что многие приложения - это круд странички, но типа уровень воды поднимается и это будут островки

Да у хорошей CRUD архитектуру порох начинается на таком лоаде, что 90 процентов бизнеса никогда не эволюционирует до него.

люто плюсую, в IT вообще часто любят оверинжинирингом заниматься

споря в какую бд получить свои нещастные 100 гигов данных

говорит любитель фримонадок :)

разговоры какие то, прямо как на собесе у экзанты

ничего не имею против них, но забавно слышать "оверинжиниринг" в таком контексте

фримонадки позволяют писать отлично тестируемый код

и это важно для бизнеса

да почти что угодно позволяет это делать

в этих вот прекрасных компаниях которые я назвал

qa было по одному на команду из 15-20 девелоперов

и было все прекрасно и радужно

на этой чудесной ноте дискуссию можно и прекращать)

моки на каждом шагу, это не хорошое и легкое тестирование

у каждого свое мнение)

qa было по одному на команду из 15-20 девелоперов

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

этого не случится, если писать тесты, а еще лучше по tdd как викс

ибо сломав что-то не той строчкой кода

apache ignite тож на джаве писан - гавно, нужно выкидывать

и кафку выкидывай, она вообще на скале, и там байты перекладываются!

ты на тестах увидишь все

у хорошей команды разработчики в oncall находятся

и поэтому сами пишут тесты :)

и кафку выкидывай, она вообще на скале, и там байты перекладываются!

пошли аргументы в стиле, "А ВОТ НЕТТИ ЖЕ БЫСТРАЯ, А ОНА НА ДЖАВЕ11!!!!"

пошли аргументы в стиле, "А ВОТ НЕТТИ ЖЕ БЫСТРАЯ, А ОНА НА ДЖАВЕ11!!!!"

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

ты на тестах увидишь все

огромный % багов (с тз бизнеса) никак не покрывается тестами и вообще тесты не столько "проверяют" качество кода, сколько не дают наступить на одни грабли дважды

огромный % багов (с тз бизнеса) никак не покрывается тестами и вообще тесты не столько "проверяют" качество кода, сколько не дают наступить на одни грабли дважды

лол, орнул

у вас есть логика приложения и IO

логика приложения кроется тестами на 100%

на IO пишется спека и две реализации, продакшн и для тестов, инмемори

обе реализации тестируются одной и той-же спекой

и в итоге все отлично