>Разве что, c взлетом WebAssembly что-то поменяется
Поменяется всё, каждый будет пилить код на чём захочет. Я буду на джаве с openjdk, вы на котлине и все будут счастливы )
>Только не надо говорить про строгую типизацию
Извините, но мы тут в топике про статическую типизацию, GWT и вот это всё, не распиваем смузи с другими бородачами падкие на всё блестящее и модное?
>Ну если непременно хочется альтернатив, то TypeScript
Вы серьёзно предлагаете писать бекенд на TypeScript? Я полагаю вы понимаете, что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
>крайний вариант Котлин
А вы случайно за груви не топили, когда он был в трендах? CoffeeScript может использовали? Нет, делайте свои пет проекты на чём хотите, я не осуждаю.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок, из-за которого нужно заново всё переписывать, а заказчик не корпорация типа Твиттера, готовая оплачивать смузихлебам развлечения с модным ЯП?
>Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
В процессе. Скоро в этих ваших интернетах и на хабре в частности.
>Java — не самый лучший вариант. Помимо того, что она оочень многословна
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
>она еще и далека от JavaScript по синтаксису
Вы следите за развитием ECMAScript и современным фронтендом, чтобы так утверждать? С 2010 года очень многое поменялось на фронтенде, если что.
>накладные расходы на получение JS из Java
Нет этих расходов, по крайне-мере они не меньше и не больше, чем получение JS из TypeScript. Другой вопрос, что GWT не умеет это делать правильно. Но, тогда повторю выше обозначенный вопрос, причём тут Java?
Умрёт, когда нормальный ЯП запилят, сейчас на рынке одни выскочки со смузи, которые тяжелее члена, ничего в руках не держали. Живут в своём выдуманном мирке, не понимая требований «работников на земле». Но в целом, старички с легаси продолжают держать рынок. И джава, даже со своим легаси, на всём этом фоне еще очень приятно смотрится.
>Абсолютно никого не смущает.
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 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.
Поменяется всё, каждый будет пилить код на чём захочет. Я буду на джаве с openjdk, вы на котлине и все будут счастливы )
Вижу с вами не всё потеряно ) Кстати, если уж быть точнее то джава не многословна, а как сказал Гослинг — у нас в джаве плохо сделаны умолчания.
Извините, но мы тут в топике про статическую типизацию, GWT и вот это всё, не распиваем смузи с другими бородачами падкие на всё блестящее и модное?
>Ну если непременно хочется альтернатив, то TypeScript
Вы серьёзно предлагаете писать бекенд на TypeScript? Я полагаю вы понимаете, что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
>крайний вариант Котлин
А вы случайно за груви не топили, когда он был в трендах? CoffeeScript может использовали? Нет, делайте свои пет проекты на чём хотите, я не осуждаю.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок, из-за которого нужно заново всё переписывать, а заказчик не корпорация типа Твиттера, готовая оплачивать смузихлебам развлечения с модным ЯП?
>Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
В процессе. Скоро в этих ваших интернетах и на хабре в частности.
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
>она еще и далека от JavaScript по синтаксису
Вы следите за развитием ECMAScript и современным фронтендом, чтобы так утверждать? С 2010 года очень многое поменялось на фронтенде, если что.
>накладные расходы на получение JS из Java
Нет этих расходов, по крайне-мере они не меньше и не больше, чем получение JS из TypeScript. Другой вопрос, что GWT не умеет это делать правильно. Но, тогда повторю выше обозначенный вопрос, причём тут Java?
Пикселизированная равнина выглядит интересно, а вот тени в подземелье очень резкие. Выглядит не очень.
Вы вот прям всех знаете, чтобы утверждать с таким абсолютизмом?
>что может привести человека к такому в 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. Не быстрее ассемблера, конечно ) Но при грамотном подходе не медленнее Си и гораздо удобнее в разработке и поддержке.
понятно, следующий