К слову я до 8 ТБ обрабатываю на локальном компе и все прелестно

Но разумеется надо правильно работу с файлами построить

характеристики?

В целом structured concurrency как раз про то, что нельзя стартануть фоновую джобу без привязки к какому-то контексту
Тут подробнее
https://github.com/Kotlin/kotlinx.coroutines/issues/410

Обычный девелопер комп.

кому интересно, вот библиотека можете посмотреть что там под капотом на Go
https://github.com/omniscale/imposm3

Мне влом. Но я повторю что сказал в начала. Аргумент про корутины не актуален. Аргумент про память - возможно, но тоже скорее всего нет.  Вопрос на чем удобнее писать и поддерживать

Ну ок, так на чем удобнее? на Go имеется некоторая библиотека, которую можно  форкнуть и переписать под себя некоторую часть
либо написать на Kotlin парсер с нуля, но тут можно + ему дать, если я захочу общие модельки с android использовать

Для OpenStreetMap скорее всего есть на котлине решение

Это вы сами решайте. Антон скажет, что на Го, потому что он там умеет. Я скажу, что на Котлин, потому что я тут умею. Более того, каждый из нас может аргументировать. Но опять же, можете посмотреть на то, что я писал в начале. Го выигрывает в случае, если у вас большой проект и малоквалифицированные разработчики. Потому что он проще. А котлин выигрывает если у вас мало народу, но более квалифицированного. Потому что гибче.

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

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

так их же не просто распарсить нужно, но и менять принцип связей между объектами.

Вот например, мне нужно найти вхождение объекта в другие объекты.
Я даже предположить боюсь сколько это займет время, так как к PostGis постоянно обращаться (PostgreSQL)

Тут язык тогда вообще не при чем.

уф.. PostGIS ещё считает - тогда попадос. можно попытаться выиграть на ио и транзакциях, иногда такое выгорает, суть следующая - ты грузишь данные в бд сразу здоровыми CLOBами, а всю обработку делаешь в процедурах и там же эти CLOBы разбираешь на отдельные записи и там же дёргаешь функции postGIS. т.е. всё происходит внунтри постгри.

вообще лучше сядь и хорошеньку подумай над составом этого комбайна, и заодно сделай приблитилеьные бенчмарки, например обработка батча записей vs сырой clob разбираемый в процедуре. плюсую оратора выше, язык тут уже мало на что влияет. основно бутылочное горлышко будет постгря по идее

да, я уже тоже много видел, что переводят с JVM на Go
Нашел вот такой бенчкарк
https://habr.com/ru/company/mailru/blog/329258/

Там сравниваются сервлеты с nio.

На этом можно ставить точку и дальше не читать. Ну не говоря уже о том, что это если речь о IO-ботлнеке, не завязанном на базу данных

это я так быстро на хабре по ключевым словам искал, текст полностью  не читал, чисто графики увидел и все

Я как бы ни в коем случае не советую судить о чем-то по микро-бенчмаркам, но по веб-серверам можно посмотреть тут: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite. Сразу на всякий случай сделаю вывод - все примерно одинаковое. Вопрос в удобствен написания, а не в перформансе