через 20 лет и код на котлине превратится в суп))) будут выходить новые версии

Не знаю. Я вот тут недавно запускал программу на Java, написанную лет10 назад. Запустилась с первого раза.

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

А так и есть. Там поезда фортрановского кода были. Формулы, модели которые написали в 80х. И никто не переделывает. Работает и довольны. Там адский код по современным меркам. По 20 входных параметров, все названы как C, NN, Mul и тд. Это наследие ещё долго будет

Ага.

а, в плане запуска, врозможно, я про устаревание синтаксиса

Тут скорее вопрос, на чем писать что-то новое. Можно продолжать старую традицию, а можно пытаться сделать лучше.

Тоже нет, обратная совместимость же. Конечно сейчас "так уже не пишут", но работает и даже читается.

Ещё и интел подливал масло. Фортан у них быстрее си работал. Они его ещё и ускоряли доробатывая компилятор. Вроде просто перекомпилил, а у тебя - 10% по времени расчетов

К вопросу о быстрых компиляторах. Сейчас говорят graal быстрее HotSpot работает. А все что надо было - переписать на человеческом языке.

Ребята, проясните вопрос:
В корутинах часто говорят - мол можно создать хоть 100 тыщ. потоков.
Но как правило когда нужно такое количество потоков - это какой-нибудь блокирующий IO, например вызов REST. Но я так понял корутины тут не помогут и ожидание ответа все равно будет происходить в отдельном нативном потоке.
Но при этом приводят пример когда у вас Backend которые предоставлет REST с нагрузкой 100 запросов в сек, который данные берет из базы, и средний ответ скажем 2 секунды. Но тут у вас происходит деградация производительности базы - ответы отдаются дольше, количество активных потоков обслуживающих запросы на бэк растет и вы падаете с OutOfMemory в какой-то момент при попытке создать еще поток.

Иными словами, если я запущу 100 корутин которые дергают БД
У меня будет 100 потоков которые ожидают ответа от БД?
или это будет 100 корутин которые шарят один нативный поток?

> блокирующий IO, например вызов REST

поэтому есть куча асинхронных неблокирующих клиентов, и тут корутины во всей красе

ну ок, а если в плане БД?

А в плане ДБ идея в том что у тебя будет http слой асинхронным, а для БД (пока, но скоро r2dbc будет) будет пул как обычно. Бенефит в том, что система может правильно дегардировать, т.е. не будет уходить в большую летенси, и плохо обрабатывать все запросы, а просто откидывать сразу то что она очевидно не обработает.

> Иными словами, если я запущу 100 корутин которые дергают БД
У меня будет 100 потоков которые ожидают ответа от БД?
или это будет 100 корутин которые шарят один нативный поток?

Корутины обычно ранаются поверх диспетчера ( ~= пул обычный), сейчас стандартным решением для работы с IO запустить поверх Dispatchers.IO где по дефолту 64 потока. Вот в 64 потока ты сможешь ходить в базу, при этом если пул забьется то корутины начнут выстраиваться в очередь. Чтобы очередь не росла можно прикрутить SLA, типо ожидание не больше 1 секунды (withTimeout), таким образом отстреливать запросы которые база не обсужит скорее всего нормально

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

Можно ли считать что корутины не имеют отношения к потокам, а просто выполняются вперемешку внутри одного потока, когда есть возможность?

Имхо привязка к потокам затрудняет понимание того, как реально устроены корутины

И да и нет :)

Ну ваще сама модель корутины ж дико простая