Имплиситы тем хороши что они ситстематичны

Джавы и шарпы в народе хорошо идут, для обычных челов выглядит проще языки. А в скале сложность уменьшает адопт

Есть язык в котором решили от многого отказаться и получился го )) и эти "отказы от многого" воспринимаются как плюсы языка.

Почему ты тогда не пишешь на го?

Я знаю (

Я скалу учу для души так сказать, очень интересно и познавательно. Я мало знаком с ФП парадигмой и учу скалу частично и для того чтобы лучше разобраться в ФП. Почему не взял более чистые ЯП потипу хаскеля - потому что хочется посмотреть на язык с ФП который юзают на проде в более чем одной/двух (я конечно утрируют) компаниях.

Го я не очень люблю тк там, как мне кажется, уж слишком много всего "наубирали". И получился язык аля Си + GC. Да, в нем проще разобраться чем в скале, но абстракции которыми оперирует Го в разы проще чем то что можно создать на скале. Достаточно посмотреть на примеры кода которые тут выкладывают опытные скалисты в 10-20 строчек кода которые по функциональности будут сравнитмы с 30-50 строчками на го.

Для души учить лучше всего

на контекстах из скалы 3 можно сделать больше

это в скалку3 такое завезут?

уже завезли

всем салют

https://scalameta.org/metals/blog/2020/08/19/lithium.html

завезли супорт scala sheets для дотти

Подскажите плз, можно ли как то заоверрайдить HKT метода?
Например есть
def do[F[_]](f: F)
Я хочу заовверрайдить как
override def do[F[_] <: Future](f: Future) = ???

Есть такая возможность?

Только для одного метода?

Ага. Именно

Да, можно, завернуть F[_] в параметр трейта, и в наследнике попросить ограничение сверху

Можно придумать сверху какой нибудь сахар

Дело в том что я не хочу выводить этот параметр в трейт. Там уже есть один и он используется как tagless final. по нему определяется поведение. И введение второго всю параметризацию портит