Стартапы крутятся, коды мутятся, разве что денег с этого пока нет 😁 классика )

Но речь пойдет не о доходах, а о нюансах процесса. У любого стартапа с мультиплатформенным продуктом всегда встает дилемма - какие технологии применить, чтобы сократить time-to-market. Мне как инженеру должно быть просто, подумаете вы, и ошибетесь. Инженеру-предпринимателю еще сложнее. Как инженер я не боюсь технической сложности, но как предприниматель боюсь быть втянут в решение технических, а не продуктовых проблем

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

Опытным путем доказано - Kotlin не является кроссплатформенным решением, экономически выгодным для стартапа. Ниже ряд причин:

- Родная среда для Kotlin - JVM и Android. Понадобятся годы, чтобы инструментарий для разработки под другие среды стал годен к использованию из коробки. Всё, что сейчас есть для разработки под iOS и Desktop предельно сыро - на iOS нет интеропа со Swift, а на десктопе тут и там торчат волосатые уши Java Swing. Тут и там нужны какие-то плагины к компилятору, настройка в Gradle - черная магия.

- Compose Multiplatfrom - безбожно тормозит на прокрутки даже простых списков, а Kotlin Multiplatform в быстрорастущих проектах обрастает такой сложностью, что нужна отдельная команда, вникающая в нюансы сборки и платформенной интеграции

- Единственным местом где можно что-то взять и сделать на Kotlin - это бекенд. Тут правят Spring и Quarkus. Вероятно, их использование было бы оправдано в all-in Kotlin стеке. Но как мы поняли концепция провалилась, а значит и корпоративных тяжеловесов из мира Java в стартап тянуть смысла нет.

Kotlin на беке больше Java чем Koltin: корутинами даже не пахнет, тащить в проект родные Kotlin-зависимости резона нет.

Еще один минус - JVM не для экономных. Даже оптимизированный Dockerfile на выходе дает образ минимум в 250-300 МБ. В рантайме инстанс тоже не мал и не блеснет производительностью. Нативные компиляторы типа GraalVM чтобы удешевить владение инфраструктурой -
лишние приседания, вредные для стартапа.

В итоге весь написанный Kotlin-код был заархивирован. Опыт получен. Бекенд был переписан с кучей новых фич Golang за 1,5 недели. Продуктивность стартаперская, docker-образ 9Мб, производительность чудовищная.

Мобильное приложение будет нативное. На Swift. Потому что я в нем эксперт.

Вывод. Берите то, что хорошо знаете или способны адаптировать в кратчайшие сроки. И если это не Kotlin, то он не станет для вас универсальным решением.

#стартап_в_соло@machine_head_ru