Тоже дошли до состояния тупящих нод, подумываем про разделение на кластеры, ситуация вроде позволяет.
Кстати, про холодные индексы: пилил их для внутреннего использования, после попробовал предложить эту фичу девелоперам, но они отказались, слишком сложно. У нас на проде прилично экономит хип, но не никак не посмотрю, как сильно ухудшились поиски. Лежит здесь: github.com/m31collision/elasticsearch/tree/unloadable-indices
Вот как генерируют UUID в Elasticsearch (6 байт времени + 6 байт поксоренного мак-адреса и 3 байта счётчик). И эта версия разработчиков не устраивает, поэтому они наколдовали немного по другому и теперь новые UUID будут сортироваться и лучше ужиматься.
Я конечно вижу профит от Optional и использую его. Но всё же и теперь вы не смогли убедить меня.
1. Примеры странные и неубедительные. Складывается ощущение, что от Optional всё стало громоздко.
2. И всё-таки это since java 8
А где примеры? Следующие части тоже «сухим текстом» будут?
По теме: «Объект всегда выдается, но не всегда живой» похоже на паттерн NullObject. В принципе самый оптимальный вариант на все времена. ИМХО, единственное преимущество Optional — в методах map()/filter(), что врядли делали, используя упомянутый паттерн.
Откуда вы взяли про больше/меньше? Получается java/c# совсем не ругают?
По моим ощущениям, ругают одну только джаву (чего только это стоит — как же её не ругать?), и ощущение складывается от того, что эта платформа моя основная сфера деятельности.
релизы php7 (с нормальным ООП и строгим тайпхинтингом)
Тут надо начать с "какое оно, нормальное ООП?", а вообще, чтобы понять, откуда взялось ООП в PHP, нужно ответить на вопрос для чего он создавался и как потом росла сложность проектов. Отсюда такое развитие
Хотя мне не приходилось использовать CharSequence, его метод subSequence можно использовать в качестве view над оригинальным объектом, чтобы не плодить ещё. String так и делает.
JVM привязана больше к инфраструктуре, а не к языку. Были причины, почему Java в своё время не заняла нишу WebAssembly, несмотря на попытки. И воз поныне там же. Подробнее можно здесь.
Да, песенка спета, да и к лучшему что так закончилось. Аплеты выкинут и целый груз с плеч.
А вобще все эти нашпигованные платформы, лезущие в интернет — изобилуют дырами. Как флеш. Может с WebAssembly такого не будет
Разве это не позволяет интерпретирующему использовать всю ту же JIT-компиляцию?
wasm не привязан к конкретному языку (или группе языков, с учётом Scala и Kotlin)
JVM тоже не привязана к Java, она понимает свой байткод, в который могут компилироваться и другие языки (выше озвученные например). Группе языков? Есть интерпретаторы Python/Ruby/etc, но да, всё же это интерпретатор в интерпретаторе.
Или я что-то не понимаю?
JVM достаточно массивна
Java 9 не спасёт ситуацию?
Кстати, гуглятся интерпретаторы WebAssembly под .NET и JVM.
Вы собираетесь ещё раз пригласить Сэма Аарона на какую-либо из ваших конференций, хотя бы ради вечеринки? Программирование музыки в живую очень в тему для такой конференции, нежели кавер группа.
Я лишь говорил о том, что другими средствами это же самое давно делается
Вы снова упускаете модуляризацию платформы из виду. Вы говорите о средствах для приложений, а что предложите для самой платформы?
Если поставить модуляризацию платформы во главу, то тоже самое неизбежно произойдёт и с рантаймом как следствие. Да, возможно это reinvent the wheel, но, имхо, это не должно быть поводом бить на модули только саму платформу (да и как бы это выглядело).
По моему, вполне оправдано решили сделать такую фичу и для джавы. И теперь такую же систему из 100 модулей можно поднять и на девятке. При этом OSGi может жить дальше.
К тому же, целью не было убийство OSGi. Все его юзают и получают профит, а в джаве до сих пор правят монолитный код? Разработчикам тоже хочется упростить себе разработку и поддержку самой платформы.
Кстати, про холодные индексы: пилил их для внутреннего использования, после попробовал предложить эту фичу девелоперам, но они отказались, слишком сложно. У нас на проде прилично экономит хип, но не никак не посмотрю, как сильно ухудшились поиски. Лежит здесь: github.com/m31collision/elasticsearch/tree/unloadable-indices
А вместо этого вынуждены рассматривать жалобы на ложный бан
Вот как генерируют UUID в Elasticsearch (6 байт времени + 6 байт поксоренного мак-адреса и 3 байта счётчик). И эта версия разработчиков не устраивает, поэтому они наколдовали немного по другому и теперь новые UUID будут сортироваться и лучше ужиматься.
1. Примеры странные и неубедительные. Складывается ощущение, что от Optional всё стало громоздко.
2. И всё-таки это since java 8
По теме: «Объект всегда выдается, но не всегда живой» похоже на паттерн NullObject. В принципе самый оптимальный вариант на все времена. ИМХО, единственное преимущество Optional — в методах map()/filter(), что врядли делали, используя упомянутый паттерн.
Думаю, автор имел ввиду 1) кросс-компиляцию и 2) бинарник без зависимостей в рамках одной платформы:
Откуда вы взяли про больше/меньше? Получается java/c# совсем не ругают?
По моим ощущениям, ругают одну только джаву (чего только это стоит — как же её не ругать?), и ощущение складывается от того, что эта платформа моя основная сфера деятельности.
Тут надо начать с "какое оно, нормальное ООП?", а вообще, чтобы понять, откуда взялось ООП в PHP, нужно ответить на вопрос для чего он создавался и как потом росла сложность проектов. Отсюда такое развитие
Как-то даже стыдно, ни разу не сталкивался с подобным. Видимо, всё время везло
Спасибо за ответы.
Да, песенка спета, да и к лучшему что так закончилось. Аплеты выкинут и целый груз с плеч.
А вобще все эти нашпигованные платформы, лезущие в интернет — изобилуют дырами. Как флеш. Может с WebAssembly такого не будет
Не знаком с WebAssembly, и поэтому есть вопросы:
Разве это не позволяет интерпретирующему использовать всю ту же JIT-компиляцию?
JVM тоже не привязана к Java, она понимает свой байткод, в который могут компилироваться и другие языки (выше озвученные например). Группе языков? Есть интерпретаторы Python/Ruby/etc, но да, всё же это интерпретатор в интерпретаторе.
Или я что-то не понимаю?
Java 9 не спасёт ситуацию?
Кстати, гуглятся интерпретаторы WebAssembly под .NET и JVM.
Вы снова упускаете модуляризацию платформы из виду. Вы говорите о средствах для приложений, а что предложите для самой платформы?
Если поставить модуляризацию платформы во главу, то тоже самое неизбежно произойдёт и с рантаймом как следствие. Да, возможно это reinvent the wheel, но, имхо, это не должно быть поводом бить на модули только саму платформу (да и как бы это выглядело).
К тому же, целью не было убийство OSGi. Все его юзают и получают профит, а в джаве до сих пор правят монолитный код? Разработчикам тоже хочется упростить себе разработку и поддержку самой платформы.