Ну я же сразу же написал что они делать один пулл 🌚

^

Я не знал, что Default такой жручий. Он просто держит 10 потоков на будущее.

Но то что под дефаут потоки сразу выделяются я не знал

Дефолт == количество ядер. Может ещё какие эвнистики

Да, там не 10, а 8, я неправильно понял код. Ну в целом сходится.

Мне казалось, они раньше лениво создавались, только по надобности

+

Проблема была с функцией, которая получала  androidx.core.util.Pair<MutableList<>, MutableList<>>
Котлин пытался привести ее к котлиновскому пейр, ну и тогда оверрайд не работал.

Если хочется хардкора, есть еще мои две статьи, про архитектуру на расширениях.

Буду признателен. Мне, как новичку, для саморазвития все полезно

https://proandroiddev.com/an-introduction-context-oriented-programming-in-kotlin-2e79d316b0a2. Но я бы все-таки Елизарова читал для начала (все статьи).

There is an english version of my talk here: http://smyachenkov.com/posts/kotlin-static-analysis-tools/, you can check it out 🙂

Thank you

вопрос по взаимодействию котлина и spring data jpa,
в коде можно как то ограничить чтобы в map не передавали функции которые записывают данные в бд?
или где-то в спринге включить чтобы генерировалось исключение если в readOnly происходит запись в бд?
из-за того что она readOnly, все что вызывается в map не комитится без ошибок, код вызывается
но никаких записей в бд не происходит

@Transactional(readOnly = true)
override fun <T> getUser(userQuery: UserQueryDto, map: (user: User) -> T): List<T> {
   return userRepository.findAll(UserSpecs.userIdEqual(userQuery.id)).map { user ->
       map(user)
   }
}

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

Вроде бы под это подходят actors, но у меня к ним возникает тот же самый вопрос что и к MVal в arrow – почему можно только в соответствующем scope, это же... странно? Выполняться будет в контексте, в котором мы вызываем put/send, зачем создавать эту штуку внутри контекста

https://gist.github.com/ivkomarov/eb9e8feae7a7a4eb4bbd7115a898b148

Меня интересует конкретно:

– аналогичный механизм выполнения задач с очередями на фиксированном количестве потоков
– собственно, аналог блокирующей очереди с приоритетами (не нашел схожего ничего в корутинах)

О, в Граале пофиксил корутины

Если точнее, то for в корутинах теперь поддерживается для graalvm native image

И перформанс в jit, на который жаловались