жиза

Оч бесит да, ещё когда хочешь просто отморматировать, но забываешь и у тебя все импорты превращаются в тыкву

Кирилл ответил то что я имел ввиду, метал и скалафикс знает точнее про скала код потому что использует семантик дб

Но шутка да, нельзя ж не кинуть какашку в самый популярный продукт, обязательно кто то да подгорит

@odomontois здесь ?)

Олег, расскажите пожалуйста, почему котлин это хорошо для скалы ?
(чтоб контекст был)

Можно

Ну можно взять самые частоупоминаемые вещи на тему "что мешает адопшену скалы".
1. Оче сложный язык - на самом деле язык отличается сильно от того, что привыкли использовать юзеры из самой крупной потенциальной зоны адопшена - Java
2. Не нужно - без знакомства с принципами языка не понятно, зачем большая часть фич языка, почему им столько внимания.
3. Некачественные либы - учитывая, что значительная часть - это обёртки над жавой, и они некачественны от того, что опять же разница между java и scalа очень велика, и нужно гораздо больше усилий потратить, чтобы всё обернуть

Как Котлин влияет на эти вещи
1. Котлин по языковым фишкам где-то ровно посередине между Java и Scala. Освоить скалу, уже зная котлин гораздо проще. Поэтому при определённой популярности котлина открывается новый канал адоптеров, которые раньше проигнорировали бы скалу из-за слишком крутой кривой обучения( тот же примерно эффет, что haskalator)
2. Опять же унаследовал многие подходы из scala, понять причины и ценность многих фич будет гораздо удобнее, если оценивать с базы уверенного владения К
3. Больше либ будут писаться для хорошей интеграции с Kotlin, чаще будут выбираться композиционные, комбинаторные подходы (к.н. - reactor), что сделает их гораздо проще в оборачивании. Мало того, если добиться унификации родственных фич scala\kotlin, чтобы data \case классы, extension methods, например, были взаимозаменяемы будет вообще рай.

Частоназываемой угрозой является то, что часть людей уйдёт со скалы, потому что она слишком сложная, что им нужен был меньший набор фич.
В реальности попытка залочить юзеров на каких-то киллер фичах редко сказывается на успешности продукта, наоборот, если часть людей уйдёт, сообщество сосредоточится на нуждах тех, кому нужна именно скала, экосистема продолжит расти в качестве ещё быстрее.
А наличие родственного языка, решающего родственные задачи на том же рантайме ещё и хороший источник для заимствования.
Поэтому в среднем, как мне кажется, котлин должен позитивно влиять на скалу. Его успех сам по себе доказывает, что большое количество идей в скале, которые раньше объявлялись "ненужными" очень даже нужные.
И если удастся достичь коллаборейшена, в особенности общего IR или метаданных для языковых инструментов - это было бы гиперполезным

Из примеров позитивной конкуренции - инлайн функции в дотти в первых редакциях были по фичам примерно тем же самым, что и в уже зарелизенном тогда котлине.
Т.е. это показалось хорошей фичей и сравнительно low hanging fruit, и потом вылилось в лучшую систему метапрограммирования.

спасибо!😊

к примеру, я надеюсь, что в java уже наконец смирятся с тем, что вариантность - это полезно, и эта вакханалия с

from(Publisher<? extends T> source)

using(Callable<? extends D> resourceSupplier,
      Function<? super D,? extends Publisher<? extends T>> sourceSupplier,
      Consumer<? super D> resourceCleanup)

уже прекратится

как вариантность в произвольных функах вообще делается? В шарпе емнип только в декларациях интерфейсов можно её юзать

ну есть твой интерфейс Function вариантен, вот и вариантность

а то есть Callable<? extends D> означает Callable<D> для вариативного Callable?

Callable - это интерфейс, эквивалентный () => D

т.е. в scala эта сигнатура выглядела бы как
using(resource: => D)(source: D => Publisher[T])(cleanup: D => ()): Publisher[T]

ну я так и понял. Спасибо)

Кто знает скалу или этот патерн, можете обьяснить как и что здесь происходит?
Я понимаю какой должен быть результат выполнения но не понимаю как именно его достигли. Для возвращаемого типа eval и expect реализовали метод flatMap?
И еще непонятно что если клиент уже прошел какой-то сценарий, как он при следущем сообщении пропускает пройденные ?

или этот метод строит самого бота а не обрабатывает запросы?