Пётр Портнов - Продвинутые системы типов. Чего еще мне не хватает в Java из Rust

[@egomate]

45:19 Режиссер, спасибо тебе за хорошо читаемый слайд, чтоб ты был здоров!

[@rufus20145]

На 11:35 тоже

[@PROgrm_JARvis]

@@rufus20145 Понимаю боль) Но благо в описании есть ссылочка на презу

[@birzhanamirov8715]

По поводу compile-time Null errors - не пробовали ли вы NullAway?

[@canismajorisvy]

Интересный доклад, классная подача, спасибо!

[@iimuhin]

Класс! Наконец-то, понятно куда sealed засунуть.

[@PROgrm_JARvis]

Рад, что получилось унести что-то полезное из доклада :)

[@antonkuranov]

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

[@PROgrm_JARvis]

На мой взгляд, как раз non-null by default прекрасная (и более естественная) концепция, нежели неявный nullable на всём. Конечно, добавлять non-null к относительно старому языку гораздо сложнее, чем иметь её изначально, но даже в OpenJDK сейчас вполне движутся в эту сторону. Да и у Kt, кажется, всё довольно правиильно и хорошо получилось (в том числе, в плане интеропа). Ну а для меня лично в целом вынос логики в статику почти всегда плюс, потому что гораздо больше неявных контрактов и инвариантов приходится держать в голове (в том числе разные фокусы с sealed мне гораздо чаще помогали в рабочих задачках да и просто в понимании кода).

[@antonkuranov]

@PROgrm_JARvis в общем случае nullability как и вообще любой тип не всегда вычислим в статике. Пример: объект формы с полями enum gender (M, F, Other) и string otherGender, которое nonnull только при gender=Other. Такой контракт статично не выразить. Nullable будет только мешать, когда проверка на gender=Other уже сделана. И таких случаем много, например lazy инициализация для которой пришлось городить lateinit. Поэтому в языке всегда должен быть способ обхода статического контроля при помощи более слабых контрактов для нетривиальных кейсов, как ни nullable, ни nonnull. Система типов должна помогать, а не мешаться.

[@владимирсенцов-р1ю]

@@antonkuranov По моему в Idris можно подобное записать. Как уже и не вспомню давно игрался с функционлкой.

[@PROgrm_JARvis]

​​@@antonkuranov , я как раз обратного мнения: > в общем случае nullability как и вообще любой тип не всегда вычислим в статике По моему опыту, как раз хорошо работает принцип, что всё не-null (с попавкой на от, что в Джаве это не очень ьвыразимо), и лишь тогда, когда явно возникает необходимость (явно, потому что иначе не скомпилится) возникает nullability. > Пример: объект формы с полями enum gender (M, F, Other) и string otherGender, которое nonnull только при gender=Other. Такой контракт статично не выразить. Как раз таки выразить, и код станет проще (не зря же я тип-сумму продвигал): enum Gender { M, F, Other(String), } или Java-эквивалент: sealed interface Gender { enum Default implements Gender { M, F } record Other(String name) implements Gender {} } и по этому (уже) можно отлино паттерн-матчиться, а общие методы, как и всегда, выночить в этот интерфейс. И в этом случае система типов мне именно помогает, потому что мне не приходится разделять проверку на вариант (тег) и получение значения, которое специфично для конкретного варианта. С Lazy, по-моему, такая же история

[@antonkuranov]

@@PROgrm_JARvis Если бы все так просто были! Это хорошо работает, пока вы пишите весь код на чистой Java. Как только начнёте использовать стековые технологии, начинаются танцы с бубном. Jackson-у нужно объяснить про sealed классы, Spring type mapper нужно тоже подкрутить, возможно сделать кастомные JPA type converters. Если нужен экспорт в OpenAPI -- добро пожаловать и дивный мир генераторов и костылей. Словом, экосистема плохо приспособлена для нетривиальных типов и кастомных правил. С non-null by default есть следующий кейс: приходит с веба объект формы. Все поля до валидации nullable по понятным причинам. После валидации required поля гарантированно не null. Для этого придется делать две копии объекта -- одна "сырой" с nullable полями, другой валидный с nonnull. Валидация должна мепить один в другой. С т.з. статичного контракта это правильно, но сильно непрактично. Достаточно, что бин с расставленными JSR-303 аннотациями, полученный в контексте Spring, гарантирует валидность полей, в т.ч. not null.

[@Farnese-vk7ec]

"Чего еще мне не хватает в Java из Rust" Может уже стоит оставить язык (Java) в покое?

[@PROgrm_JARvis]

Для многих недостающих фичей в докладе же приводятся примеры того, что это в том или ином виде сейчас движется в JDK (stats-before-super, non-null types, и прочее), хоть и (супер)медленно так что думаю тут вопрос лучше не мне адресовать (хоть я, очевидно, и разделяю позицию, что эти вещи нужны)

[@stanislavzemlyakov5442]

Смотрите, мужики, джависты котлин придумали!

[@stanislavzemlyakov5442]

Ну ок, если без шуток, то монада Result/Either связана с растом так же, как int связан с джавой. Несмотря на шероховатости доклада, я поддерживаю полностью! Спасибо за труд.

[@ChannelCheesecake]

Скорее скалу

[@PROgrm_JARvis]

Так-то, справедливо :) Спасибо за хорошие слова!

[@iimuhin]

Петр сказал, что есть что-то лучше Protobuf. Какой формат он имел в виду?

[@PROgrm_JARvis]

Универсального ответа, как всегда, нету. Из интересного вокруг можно глянуть на CBOR, Flatbuffers, Cap'n proto, и при этом ни один из них не будет серебряной пулей, каждый из них решает определённый класс проблем ценой введения других. В случае с Protobuf'ом, кстати, формат не так и плох, но много боли доставляет его (единственная) реализация кодогенератора для джавы.

[@maksimbiriukov5483]

rkyv конечно

[@bananasba]

Раст убрать из названия, к этим поделкам он отношения не имеет. Второй раз этот тип толкает с умным видом какую-то ерунду, достаточно уже озона, с нимим все понятно. Джаваке, чиселки, и проч - в курилке разговаривать приемлимо.

[@PROgrm_JARvis]

> с умным видом Та ну нет же > Джаваке Мой совершенно объективный и ни разу не ошибковыживальческий опрос показал, что большинство предпочло произношение джавак :pekaface: Ну а так, Ваше/твоё мнение -- всяко спасибо за обратную связь

[@eq716]

Every language is developed to solve a particular problem. Java can't solve all the existing issues and should not do that. Also it should not implement all existing synthetic sugar.

[@PROgrm_JARvis]

Как и в соседнем комментарии, скажу, что часть вещей, которые упоминаются в докладе, вполне себе запланированы в OpenJDK (с поправкой на то, сколько их реально будут реализовывать), и это при всей консервативности многих разработчиков там. Так что, кмк, вещи признанно нужные Ну а главное, то что не надо добавлять всякую функциональность далеко не значит, что не надо добавлять никакую