Это не "описание работы форк-джоин пула", это по сути Рабинович напел — кое-как описана fork-фаза, и ни слова о join-фазе. Порассуждали о дроблении задач, но ни слова о том, что итоговый результат тоже должен быть собран из множества результатов подзадач. Про детали реализации, вроде того же "воровства работы", я молчу.
Эрланг прекрасен, но, к сожалению, пока в индустрии не нашлось никого, кто бы хотел влить в него денег, как, например, в свое время влили в java, а без этого имеем достаточно бедный тулинг вокруг языка, и так до сих пор и не выросло ничего по масштабу сопоставимого, например, с тем же самым Spring'ом. Да, OTP отличная штука, но она все еще очень низкоуровнева, над ней так или иначе приходится делать множество велосипедов, и каждая команда проходит этот путь заново и в одиночку. Очень недооцененный индустрией язык, хочется верить, что это изменится.
в какой-то момент осознали, что не замечать сколько инцидентов у нас возникает из-за Hazelcast, дальше невозможно
Какие инцеденты-то? Вся статья выглядит, как воспевание редиски со ссылками на сторонние ресурсы, которые тоже что-то там себе отранжировали воспользовавшись личной линейкой. Мне, как читателю, хотелось бы хотя бы в общих чертах понять от чего именно вы бежали, какие задачи решали, и почему этого не получилось сделать на хазеле, а вместо этого я читаю какой редис прекрасный и замечательный.
На небольших коллекциях такое распараллеливание только замедляет процесс. В докладах Шипилёва звучала цифра в 10_000 элементов коллекции — после нее распараллеливание стрима может дать положительный эффект. А может и не дать, надо бенчить.
я не могу вспомнить ни одной компании, в которой бюджет был бы неограничен в принципе
А где тут хоть слово про "неограниченный в принципе бюджет"? Речь про несопоставимость бюджетов на удержание, и бюджетов на найм. А если эти бюджеты не сопоставимы, значит стоимость сотрудника внутри компании будет повышаться медленнее, чем если он зайдет "снаружи", и об эту нехитрую истину жизни ломаются все ваши показатели вовлеченности и прочие игрушечные метрики.
Вовлеченность, лояльность, проценты, бла-бла-бла… А повышение зарплаты на действительно ощутимую величину только через смену работы — потому что бюджет на найм есть, а бюджета на удержание нет.
От фреймворка зависит, что он будет делать с потоком, в котором произошел блокирующий вызов — современные фреймворки способны понять, что поток простаивает, и отдать его под соседнюю задачу. Вот-вот зарелизится Project Loom, который это все завозит в джаву из коробки, а в котлине примерно тоже самое делают корутины.
И вы по-прежнему просто прочитали строчку с диска. Вы не валидировали ее, вы не привели ее к нужному виду, вы не доставили ее до места применения, вы не научились ее обновлять на лету, вы ее даже не объединили в группу с другими свойствами того же вида. Вы просто прочитали строчку с диска, да еще завязавшись на конкретный файл свойств.
Ваш вариант просто загрузил свойство. Спринг со всеми его наворотами позволяет валидировать, возвращать дефолты, если свойство не найдено, и еще много чего, вплоть до измененя свойства в рантайме, при чем по сети. Эти "невероятно сложные" (нет) возможности стоят того, что бы их освоить, как мне кажется.
Так, скажите просто - когда python/js/нужное_вписать скрипты можно будет заменить джавой?
Явная типизация уже сама по себе документация, и в отличие от документации — эта всегда актуальна.
Это не "описание работы форк-джоин пула", это по сути Рабинович напел — кое-как описана fork-фаза, и ни слова о join-фазе. Порассуждали о дроблении задач, но ни слова о том, что итоговый результат тоже должен быть собран из множества результатов подзадач. Про детали реализации, вроде того же "воровства работы", я молчу.
Могу порекомендовать вот это видео: https://www.youtube.com/watch?v=t0dGLFtRR9c
Шипилёву тут потребовалось более полутора часов, что бы сказать все, что он хотел о fjp.
А почему нет? Серьезно, почему бы не продать именно то, что популярно? Это позволит продать подороже.
Если это 1к классов, то да. Если это все в одном классе, то нет.
Пока инструментов нет сложно сказать чего не хватает. Вот если инструмент есть, но его отняли — вот тогда все тут же становится понятно!
Эрланг прекрасен, но, к сожалению, пока в индустрии не нашлось никого, кто бы хотел влить в него денег, как, например, в свое время влили в java, а без этого имеем достаточно бедный тулинг вокруг языка, и так до сих пор и не выросло ничего по масштабу сопоставимого, например, с тем же самым Spring'ом. Да, OTP отличная штука, но она все еще очень низкоуровнева, над ней так или иначе приходится делать множество велосипедов, и каждая команда проходит этот путь заново и в одиночку. Очень недооцененный индустрией язык, хочется верить, что это изменится.
Комментарии то работают, то нет — в зависимости от отображения? Да, зрелый продукт, что и говорить.
Какие инцеденты-то? Вся статья выглядит, как воспевание редиски со ссылками на сторонние ресурсы, которые тоже что-то там себе отранжировали воспользовавшись личной линейкой. Мне, как читателю, хотелось бы хотя бы в общих чертах понять от чего именно вы бежали, какие задачи решали, и почему этого не получилось сделать на хазеле, а вместо этого я читаю какой редис прекрасный и замечательный.
Круто, конечно, но не актуально — JB решили, что наши деньги для них не достаточно хороши, и продавать все это великолепие нам отказывается. А жаль =(
На небольших коллекциях такое распараллеливание только замедляет процесс. В докладах Шипилёва звучала цифра в 10_000 элементов коллекции — после нее распараллеливание стрима может дать положительный эффект. А может и не дать, надо бенчить.
А где тут хоть слово про "неограниченный в принципе бюджет"? Речь про несопоставимость бюджетов на удержание, и бюджетов на найм. А если эти бюджеты не сопоставимы, значит стоимость сотрудника внутри компании будет повышаться медленнее, чем если он зайдет "снаружи", и об эту нехитрую истину жизни ломаются все ваши показатели вовлеченности и прочие игрушечные метрики.
Вовлеченность, лояльность, проценты, бла-бла-бла… А повышение зарплаты на действительно ощутимую величину только через смену работы — потому что бюджет на найм есть, а бюджета на удержание нет.
От фреймворка зависит, что он будет делать с потоком, в котором произошел блокирующий вызов — современные фреймворки способны понять, что поток простаивает, и отдать его под соседнюю задачу. Вот-вот зарелизится Project Loom, который это все завозит в джаву из коробки, а в котлине примерно тоже самое делают корутины.
Прекратите уже домонстрировать невежество, даже неловко становится. К тому же
по строчкам короче.
И вы по-прежнему просто прочитали строчку с диска. Вы не валидировали ее, вы не привели ее к нужному виду, вы не доставили ее до места применения, вы не научились ее обновлять на лету, вы ее даже не объединили в группу с другими свойствами того же вида. Вы просто прочитали строчку с диска, да еще завязавшись на конкретный файл свойств.
Ваш вариант просто загрузил свойство. Спринг со всеми его наворотами позволяет валидировать, возвращать дефолты, если свойство не найдено, и еще много чего, вплоть до измененя свойства в рантайме, при чем по сети. Эти "невероятно сложные" (нет) возможности стоят того, что бы их освоить, как мне кажется.
Это еще что! Вот "спурт" вместо общепринятого "спринта" — вот где мякотка-то!
Не получится, если хотим api-first подход.
Более того, в java уже можно потрогать project loom, и с ним код сильно упростится и распрямится.