Умрёт, когда нормальный ЯП запилят, сейчас на рынке одни выскочки со смузи, которые тяжелее члена, ничего в руках не держали. Живут в своём выдуманном мирке, не понимая требований «работников на земле». Но в целом, старички с легаси продолжают держать рынок. И джава, даже со своим легаси, на всём этом фоне еще очень приятно смотрится.
>Абсолютно никого не смущает.
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 2018
Чтение кода в интернете
>тем не менее чтению не мешает
Мешает, я уже начинаю на гитхабе сталкиваться с не читаемым джава кодом, где используют var. Приходиться материться, что мою джаву превращают в очередной джаваскрипт.
Я согласен, что var можно использовать, но в очень ограниченных случаях. К сожалению это не все понимают. Очень много людей до сих пор считают, что важно количество написанных букв, а не скорость чтение написанного кода, пусть и частично избыточного. Прям вот экономят на буквах, как будто они в 70-х. И это очень печально, такой код потом очень тяжело поддерживать.
>Котлин интероперабелен с джавой в обе стороны, так что можно постепенно мигрировать проект,
Для молодежи, которая дальше пет проектов не вылезала. А в нормальном проекте по голове постучат за такие идеи.
>Котлин — все же серьезная заявка на кусок JVM-пирога
Сомнительно. Про груви так же говорили и где он теперь? Для джавы готовят очень много вкусных фич, после которых котлин станет не нужным. Он сейчас не особо нужен, но молодёжь клюёт на рекламу. Еще бы нет, его в IDEA (46% рынка IDE) даже в контекстное меню встроили, причём во многих местах он там отсвечивает.
Какой сейчас самый мощный ARM сервер, сколько ядер? И если есть аппаратные оптимизации, то почему дефолтный TLS из OpenJDK, такой тормозной на Intel по сравнению с openssl? Или на ARMv8 норм?
— упрощается рефакторирнг
— код легче читать и поддерживать
— увеличивается скорость разработки
— уменьшается кол-во ошибок с выделением/освобождением памяти
>Я могу сказать ровно то же самое что вы сейчас сказали, и показать что самое лучшее — malloc / free.
Вы не сможете с помощью этого решения найти в коде выделение памяти для конкретного объекта. Т.е. у вас в методе есть ссылка и IDE не скажет вам где для неё выделялась память и где она освобождается.
Если эта проблема решится хотя бы на уровне IDE, то я только за malloc/free и в тот же день буду с пренебрежением относиться к ЯП с GC.
Более того я периодически думаю насколько возможно сделать подобное решение. Но пока нет времени заняться этим вплотную.
>Вы не ответили на один из моих вопросов. Сколько строк кода нужно в джаве чтобы освободить список файлов?
Если для вас важны строки кода, а не простота чтения и поддержка кода. То мы с вами живём в разных вселенных. Значит вы еще не сталкивались с легаси и объемными кодовыми базами.
>Почему вы считаете логичным, что один ресурс, т.е. память, управляется GC, а остальные — почти вручную (путем .close())?
Потому что это хорошо работает. Если у вас потекли объекты, то хрен с ними, обычно это не критично и приложение может продолжать работу.
Но если у вас потекли ресурсы, хуже того вы по ошибке что-то не то снесли. То пользователь будет не в восторге.
>Где вы тут видите необходимость думать над очисткой? ее тут нет.
Ну здесь нет, а где-то есть. Еще раз GC позволяет делать код проще. Упрощает рефакторинг и долгосрочную поддержку. Иначе GC ЯП не стали бы настолько популярными.
>Но у меня есть деструкторы а у вас нет.
Я вам еще раз скажу — неявное поведение это путь к неявным ошибкам и сложностям в рефакторинге. Сложности в чтении и поддержки кода.
Через #close метод я смогу найти очистку ресурсов в коде с помощью IDE. Очистка через деструктор этого не позволяет, тем самым усложняется понимание кода, что ведёт к ошибкам.
>поднимает 100500 виртуалок в облаке и выставляет что-то вроде тредпула наружу
Вручную пишите выделение и освобождение ресурсов. Запихивать такие вещи в деструкторы это путь к не очевидным ошибкам. Отчасти, начинаю понимать, почему в Java метод finalize начиная с 9-ки стал deprecated.
Чем больше в ЯП неявного поведения, тем сложнее такой код поддерживать.
>Кстати, часто ли вы встречали сложные лафйтаймы объектов, которые нельзя выразить с помощью unique_ptr / shared_ptr?
Вы не понимаете сути проблемы. GC позволяет лишний раз не думать и увеличивает скорость разработки. Делает код проще, что означает возможность рефакторинга и простой доработки кода в будущем.
Ручное управление памятью это прошлый век. Такой подход необходим только в узких местах или в очень нишевых областях. В прикладном ПО можно без опасений использовать современные GC. Затыки по перформансу будут совсем в других местах.
>Например, вышеупомянутый класс CP, если управлять им с помощью сборщика мусора
В джаве другой подход. Например, в JDK есть Process API, который не требует очистки ресурсов пользователем при создании аналога CP в джаве. Т.е. вы просто запускаете нужный вам процесс и не паритесь за его ресурсы.
Если копнёте Process API, то увидите, что всё построено вокруг асинхронных проверок завершения процесса. Буквально в пул тредов добавляется Runnable проверяющий завершение процесса и очищающий его ресурсы. Сохраняя его out до выхода объекта из области видимости GC.
Такой подход отчасти позволяет писать примерно так process.onExit().thenAccept(p -> ...)
У меня к сожалению нет опыта разработки на С++, чтобы показать как схожие проблемы решаются на Java. Но думаю выше приведенный пример отчасти показывает различие в подходах.
>А какие еще есть причины, кроме завершения потока?
Вылет по эксепшену. DI не настолько круты, чтобы контролировать выход объекта из области видимости. При желании, конечно можно сделать троллейбус из буханки, но не для этого задумывались DI.
>То есть предлагается писать собственный jemalloc?
Нет. Основную работу делает GC. Сейчас есть GC с гарантированными 10 ms паузами. Но там, где есть узкие места, можно вручную выделять и освобождать память. Создав узкоспециализированный оптимизированный под данную задачу аллокатор.
>Как такое переносится на джаву?
>для более сложных?
Для более сложных управляете вручную или полагаетесь на IoC (dependency injection). Последнее решение очень популярно в Java. IoC автоматически загружает и выгружает (при завершении треда или по другим причинам) объекты, поэтому может, в том числе, выполнять функции деструктора.
>Т.е. управлять ресурсами предлагается вручную?
Нет. В Java есть AutoCloseable, финализаторы в Java это про другое их давно никто не использует. Динамическая подгрузка это вы наверное про Dynamic Class Loading?
>Насколько я вижу, GC никуда не девается.
Да, она на месте.
>Интересно, как Java с GC и без C++-style шаблонов может работать на уровне плюсов.
Элементарно, я поэтому и написал при «грамотном подходе». Например, один из подходов использовать пул объектов, там где очень часто нужно удалять и создавать новые объекты. Или вручную размещать структуры в массивах, взяв управление по размещению/освобождению данных в свои руки (но это больше про индексы).
Еще можно использовать RingBuffer и т.д. Опять же в последнее время в Java популярна off-heap техника, когда можно управлять памятью вручную вне владений GC.
Такие подходы вполне можно использовать в узких местах при написании браузера. Поэтому не вижу ничего страшного сделать новый браузер на GraalVM с nativeimage.
>встречаю восторженные отзывы об очередном инструменте
А я встречаю восторженные отзывы о go, kotlin, но это ничего не значит. Люди по прежнему программируют на крестах, джаве и питоне. В go же хотят внедрять дженерики (а как пели, что они не нужны!). А с развитием джавы непонятно зачем нужен kotlin. По мне он повторит историю groovy.
То, что видите вы это маркетинг, действующий на неокрепшие умы. Я это всё очень давно мониторю и пока не видел технологии «который чуть ли не сам всё за тебя делает». Всё что есть на рынке отдаёт некомпетентностью и легаси.
Мне это настолько всё надоело, что я сейчас сам начинаю работу в сторону разработки нормальных инструментов для программистов.
>восторженные отзывы об очередном инструменте
Например?
>И сколько предлагаете держать в «буфере» комментариев?
То, что помещается на экран. Плюс держать еще несколько «сверху и снизу». Плюс хранить все загруженные комментарии в виде объектов для подстановки на скроле.
Про поиск как-то не подумал. Для этой ситуации можно держать только TextNode на нужных позициях в DOM. Думаю не должно тормозить даже для десятков мегабайт текста (но это не точно). Один мегабайт точно не тормозит.
Еще это может решаться с помощью UI, на пикабу видел топорное решение для бесконечного скрола, путём нажатия нужной кнопки для очистки DOM.
Задача интересная, тут ресерч нужен, сам такое не делал еще.
>А технический долг в виде перегруженной каскадной таблице стилей никуда не исчезнет.
Можно исправить, я не спорю.
>задача сама по себе не простая
Так в этом и весь сыр бор, что программисты идут легким путём, а не решают проблему на корню.
Пикселизированная равнина выглядит интересно, а вот тени в подземелье очень резкие. Выглядит не очень.
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 2018
Чтение кода в интернете
>тем не менее чтению не мешает
Мешает, я уже начинаю на гитхабе сталкиваться с не читаемым джава кодом, где используют var. Приходиться материться, что мою джаву превращают в очередной джаваскрипт.
Я согласен, что var можно использовать, но в очень ограниченных случаях. К сожалению это не все понимают. Очень много людей до сих пор считают, что важно количество написанных букв, а не скорость чтение написанного кода, пусть и частично избыточного. Прям вот экономят на буквах, как будто они в 70-х. И это очень печально, такой код потом очень тяжело поддерживать.
Для молодежи, которая дальше пет проектов не вылезала. А в нормальном проекте по голове постучат за такие идеи.
Сомнительно. Про груви так же говорили и где он теперь? Для джавы готовят очень много вкусных фич, после которых котлин станет не нужным. Он сейчас не особо нужен, но молодёжь клюёт на рекламу. Еще бы нет, его в IDEA (46% рынка IDE) даже в контекстное меню встроили, причём во многих местах он там отсвечивает.
— упрощается рефакторирнг
— код легче читать и поддерживать
— увеличивается скорость разработки
— уменьшается кол-во ошибок с выделением/освобождением памяти
>Я могу сказать ровно то же самое что вы сейчас сказали, и показать что самое лучшее — malloc / free.
Вы не сможете с помощью этого решения найти в коде выделение памяти для конкретного объекта. Т.е. у вас в методе есть ссылка и IDE не скажет вам где для неё выделялась память и где она освобождается.
Если эта проблема решится хотя бы на уровне IDE, то я только за malloc/free и в тот же день буду с пренебрежением относиться к ЯП с GC.
Более того я периодически думаю насколько возможно сделать подобное решение. Но пока нет времени заняться этим вплотную.
>Вы не ответили на один из моих вопросов. Сколько строк кода нужно в джаве чтобы освободить список файлов?
Если для вас важны строки кода, а не простота чтения и поддержка кода. То мы с вами живём в разных вселенных. Значит вы еще не сталкивались с легаси и объемными кодовыми базами.
>Почему вы считаете логичным, что один ресурс, т.е. память, управляется GC, а остальные — почти вручную (путем .close())?
Потому что это хорошо работает. Если у вас потекли объекты, то хрен с ними, обычно это не критично и приложение может продолжать работу.
Но если у вас потекли ресурсы, хуже того вы по ошибке что-то не то снесли. То пользователь будет не в восторге.
Ну здесь нет, а где-то есть. Еще раз GC позволяет делать код проще. Упрощает рефакторинг и долгосрочную поддержку. Иначе GC ЯП не стали бы настолько популярными.
>Но у меня есть деструкторы а у вас нет.
Я вам еще раз скажу — неявное поведение это путь к неявным ошибкам и сложностям в рефакторинге. Сложности в чтении и поддержки кода.
Через #close метод я смогу найти очистку ресурсов в коде с помощью IDE. Очистка через деструктор этого не позволяет, тем самым усложняется понимание кода, что ведёт к ошибкам.
Вручную пишите выделение и освобождение ресурсов. Запихивать такие вещи в деструкторы это путь к не очевидным ошибкам. Отчасти, начинаю понимать, почему в Java метод finalize начиная с 9-ки стал deprecated.
Чем больше в ЯП неявного поведения, тем сложнее такой код поддерживать.
>Кстати, часто ли вы встречали сложные лафйтаймы объектов, которые нельзя выразить с помощью unique_ptr / shared_ptr?
Вы не понимаете сути проблемы. GC позволяет лишний раз не думать и увеличивает скорость разработки. Делает код проще, что означает возможность рефакторинга и простой доработки кода в будущем.
Ручное управление памятью это прошлый век. Такой подход необходим только в узких местах или в очень нишевых областях. В прикладном ПО можно без опасений использовать современные GC. Затыки по перформансу будут совсем в других местах.
В джаве другой подход. Например, в JDK есть Process API, который не требует очистки ресурсов пользователем при создании аналога CP в джаве. Т.е. вы просто запускаете нужный вам процесс и не паритесь за его ресурсы.
Если копнёте Process API, то увидите, что всё построено вокруг асинхронных проверок завершения процесса. Буквально в пул тредов добавляется Runnable проверяющий завершение процесса и очищающий его ресурсы. Сохраняя его out до выхода объекта из области видимости GC.
Такой подход отчасти позволяет писать примерно так process.onExit().thenAccept(p -> ...)
У меня к сожалению нет опыта разработки на С++, чтобы показать как схожие проблемы решаются на Java. Но думаю выше приведенный пример отчасти показывает различие в подходах.
>А какие еще есть причины, кроме завершения потока?
Вылет по эксепшену. DI не настолько круты, чтобы контролировать выход объекта из области видимости. При желании, конечно можно сделать троллейбус из буханки, но не для этого задумывались DI.
Нет. Основную работу делает GC. Сейчас есть GC с гарантированными 10 ms паузами. Но там, где есть узкие места, можно вручную выделять и освобождать память. Создав узкоспециализированный оптимизированный под данную задачу аллокатор.
>Как такое переносится на джаву?
>для более сложных?
Для более сложных управляете вручную или полагаетесь на IoC (dependency injection). Последнее решение очень популярно в Java. IoC автоматически загружает и выгружает (при завершении треда или по другим причинам) объекты, поэтому может, в том числе, выполнять функции деструктора.
Нет. В Java есть AutoCloseable, финализаторы в Java это про другое их давно никто не использует. Динамическая подгрузка это вы наверное про Dynamic Class Loading?
>Насколько я вижу, GC никуда не девается.
Да, она на месте.
>Интересно, как Java с GC и без C++-style шаблонов может работать на уровне плюсов.
Элементарно, я поэтому и написал при «грамотном подходе». Например, один из подходов использовать пул объектов, там где очень часто нужно удалять и создавать новые объекты. Или вручную размещать структуры в массивах, взяв управление по размещению/освобождению данных в свои руки (но это больше про индексы).
Еще можно использовать RingBuffer и т.д. Опять же в последнее время в Java популярна off-heap техника, когда можно управлять памятью вручную вне владений GC.
Такие подходы вполне можно использовать в узких местах при написании браузера. Поэтому не вижу ничего страшного сделать новый браузер на GraalVM с nativeimage.
Гуглить GraalVM nativeimage. Не быстрее ассемблера, конечно ) Но при грамотном подходе не медленнее Си и гораздо удобнее в разработке и поддержке.
понятно, следующий
А я встречаю восторженные отзывы о go, kotlin, но это ничего не значит. Люди по прежнему программируют на крестах, джаве и питоне. В go же хотят внедрять дженерики (а как пели, что они не нужны!). А с развитием джавы непонятно зачем нужен kotlin. По мне он повторит историю groovy.
То, что видите вы это маркетинг, действующий на неокрепшие умы. Я это всё очень давно мониторю и пока не видел технологии «который чуть ли не сам всё за тебя делает». Всё что есть на рынке отдаёт некомпетентностью и легаси.
Мне это настолько всё надоело, что я сейчас сам начинаю работу в сторону разработки нормальных инструментов для программистов.
>восторженные отзывы об очередном инструменте
Например?
То, что помещается на экран. Плюс держать еще несколько «сверху и снизу». Плюс хранить все загруженные комментарии в виде объектов для подстановки на скроле.
Про поиск как-то не подумал. Для этой ситуации можно держать только TextNode на нужных позициях в DOM. Думаю не должно тормозить даже для десятков мегабайт текста (но это не точно). Один мегабайт точно не тормозит.
Еще это может решаться с помощью UI, на пикабу видел топорное решение для бесконечного скрола, путём нажатия нужной кнопки для очистки DOM.
Задача интересная, тут ресерч нужен, сам такое не делал еще.
>А технический долг в виде перегруженной каскадной таблице стилей никуда не исчезнет.
Можно исправить, я не спорю.
>задача сама по себе не простая
Так в этом и весь сыр бор, что программисты идут легким путём, а не решают проблему на корню.