Похоже я пропустил самый интересный доклад))

ты еще не попади на проблему jsr305 (: в java 8+

оказывается такая существует (:

ну ничего с таким циклом релизов, может java  и начнёт догонят скалку и котлин

хотя Тагир показал, как всё это не просто

ага, думаю это маловероятный сценарий

согласен

Доклад хорош, но невесело после него. Тревожно. А ну как через 3 года завезут

+1 все понятно и по полочкам

Можно в след году на доклад Егора побольше зал 😄

А презентации демо зон будут доступны?

Не могу достоверно ответить на этот вопрос. По-моему, нет

Вот здесь мне, как компиляторщику, становится интересно. Как эти самые GHC join points, которые по факту есть CFG+SSA in disguise (про что сам Пейтон-Джонс честно в статье и пишет), могут повлиять на код, генерируемый JIT-ом, если они являются всего лишь формой компиляторного IR'а (причём ориентированного на ленивые языки, то есть никак не сочетающегося с "обычными" клмпиляторными технологиями)? И это при том, что в JIT'е (под которым, как я понимаю, Oracle HotSpot C2 compiler имеется в виду?) аналогичные штуки есть since day one. И как во всем этом участвует indy, и чем он собственно помогает?

Можешь конкретнее чуток привести примеры, чем неустраивает перечисленные фичи?

Программисты развиваются. Придумываются и обкатываются новые вещи. Если они оказались полезны и удобны, они могут появиться и в языке X.

Если фичи кажутся ненужными или даже неприятными, я бы предположил несколько причин:
1. Они не из той парадигмы, в который ты обычно кодишь. Ну, окей, людям из мира императивщины не так важны switch expressions (к примеру). Как мне кажется, в таком случае несложно фичу игнорировать и всё.
2. В ней видны неудобства для того, что происходит сейчас. Решение - следить за фичами и докладывать о том, что "вот юзкейсы, где ваше решение делает только хуже". Если утверждение хорошее, я могу предположить, что могут задуматься.
3. Не хочется менять привычки. Это исключительно личное мнение, но мне кажется, что это плохо и нужно уметь расти и меняться вместе с хорошими трендами. К примеру, тот, кто редко юзает функциональщину потому что от лукавого, наверное не так хорош, как тот, кто редко юзает функциональщину, так как понимает, что может быть много бойлерплейта (очень условное утверждение и даже может быть неправда, срач про функциональщину поднимать не хочу)

Очевидно, не претендую на абсолютную правду и могу быть неправ в каждом предложении.

Не очень понял, какое отношение join points имеет что к CFG, что к SSA, что к Пейтону Джонсу
Это имплементировано не им. Это промежуточная форма представления вызова конструкторов и паттерн-матчинга, которая превращается в по сути простой джамп, если конструирующий код инлайнится в матчащий.
JIT мог бы делать аналогичную оптимизацию, если бы подозревал о существовании таких вещей как "sealed abstract class/interface", и "match coexpression"
Я ссылаюсь на https://ghc.haskell.org/trac/ghc/wiki/SequentCore

Уровень интеллекта и знание математики несколько разные вещи.  Измеряется ведь ни кто быстрее и сложнее считает.

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

А также не тем, кто как и насколько грамотно умеет писать.

Ну вот одни видят развивающихся программистов, а я прям вангую что после релиза сначала тот же Тагир запилит доклад "причуды паттерн матчинга в джаве 100", а чуть позже он же уже с Барухом придумают пару новых сезонов паззлеров. И если со стримами ещё более менее был ясен профит - ради чего подымался порог вхождения и интродьюсились некорректные инварианты, то с пмом конкретно в джаве не вижу профита. В хаскеле вижу, в скале вижу, а в джаве - нет. Там оно - часть единой парадигмы, здесь - кусок очередной сахарозы чтоб развивающиеся девелоперы поменьше ныли.

Мне кажется, в graal это вполне затаскиваемо