Как стать автором
Обновить

Комментарии 81

Ура! Отличный релиз, спасибо разработчикам и всей команде Kotlin!

Аналогично.

Конкретно этот пример работает для версии компилятора 1.0.6 (можно выбрать внизу вместо 1.1). Вероятная причина в том что Kotlin APIs для JavaScript слегка поменялись между 1.0 и 1.1. Примеры с переносимым кодом запускаются как на JVM, так и на JS под любой версией.

Примеры починили, спасибо что сообщили.
Перепроверил. Все окей.

Отдельное спасибо что добавляете фичи для любителей функционального программирования.

Мне не понятно, как вы собираетесь обеспечивать совместимость с Java новых версий, если там будут появляться аналогичные механизмы вашим нововведениям?
Мы очень внимательно следим за планами Java, и на данный момент нам неизвестно о том, чтобы там планировались бы какие-то фичи, которые бы как-то конфликтовали с существующими или новыми фичами котлина. В том, что появляются фичи, которые предоставляют синтаксический сахар, аналогичный существующим фичам Kotlin (например, слово var), проблемы нет никакой вообще — .class-файлы остаются такими же, как были, и мы остаёмся с ними совместимыми так же, как раньше.
НЛО прилетело и опубликовало эту надпись здесь
Вбейте на YouTube канал Devcolibri, у них видел
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
coroutines — ИМХО, намного лучше чем в .Net
Я бы сам так же сделал =)

А можете пояснить этот момент для несведующих? Я из документации не очень понял в чем, по сути, отличие между async\await из .NET

В документации не раскрыта вся суть. А суть в том, что корутины в Kotlin не привязаны ни к конкретным библиотеками, ни к конкретным типам. async/await из примера — это просто библиотечные функции, можно писать свои для различных фреймворков. И ещё — generate/yield — это тоже библиотечные функции, реализованные поверх того же механизма корутин. Подчеркну, что там нет никакой внутренней магии специально для разработчиков stdlib, кто угодно может написать свои реализации generate/yield и async/await.

НЛО прилетело и опубликовало эту надпись здесь

Судя по документации — нельзя вызвать suspendable из не suspendable (что в общем-то вполне очевидно). В своих примерах они вызывают все сначала через runBlocking, а внутри уже все suspendale. Вообще выглядит как абсолютно то же самое с другим синтаксисом — пулы и диспатчеры соответствуют пулам и шедулерам в .net. Deferred< T > -> Task< T >, но как раз из-за синтаксиса разница существенная.


В целом выглядит так что с точки зрения синтаксиса в котлине асинхронщина будет в большинстве случаев удобнее в использовании (чему я как C# разработчик завидую). Плюс в C# есть одна проблема — асинхронные геттеры и сеттеры — ибо они в данный момент попросту невозможны, при этом есть entity framework у которого в lazy-loading активно используется блокирование.


Но и у дотнета есть преимущество — все нужное лежит в базовой библиотеке, ну и разработчики асинхронщины могут изменить базовую библиотеку (т.к. это почти что одни и те же люди) чтобы эта самая асинхронщина нормально поддерживалась. То есть в дотнете есть Task и его используют все — как сами ms, так и разрабы сторонних библиотек. Также в дотнете к базовому классу Stream они приделали — Read/WriteAsync, а как будут менять стандартную библиотеку jetbrains?

НЛО прилетело и опубликовало эту надпись здесь

Похоже вы меня не поняли. Асинхронщина была и в дотнете еще до async/await. И когда в дотнете запилили новый паттерн асинхронности — таски, async/await то базовую библиотеку изменили — добавили методы которые возвращают Task. То есть пользоваться базовой библиотекой стало в кайф.
В яве тоже есть non-blocking io. Но вот получается что новый асинхронный паттерн разрабатывают jetbrains, вследствие чего вопрос — как новый паттерн (suspendable) будет кореллировать с классами стандартной библиотеки?

Как раз одним из главных приоритетов при разработке корутин и была бесшовная интеграция с существующими библиотеками. В отличие от .NET, Kotlin не привязывает реализацию корутин к конкретным классам вроде Task. suspend-функцию можно написать для любой имеющейся библиотеки.

Ну таск не таск, а кастомные Awaitable то же есть: await anything
Когда вы запилите LINQ и уже можно будет мигрировать .Net -> Kotlin не расставаясь с привычными фичами?

Разрешите поинтересоваться, а для чего вы используете LINQ в C# и с каким именно его фичами вы не хотели бы расставаться?


Работа с коллекциями в Kotlin на полную катушку через уже традиционные map/filter, по-моему даже удобнее чем любой SQL. Для доступа к базам данных и статическому формированию SQL-запросов есть пара активных библиотек, например Exposed одна из более экспериментальных.

НЛО прилетело и опубликовало эту надпись здесь
Возможно имелся не просто LINQ, а деревья выражений?
НЛО прилетело и опубликовало эту надпись здесь
Без них как-то грустно :) Хотя с деструктурированием и кортежами в C#7 как-то уже и не сильно чешется на другие ЯП смотреть :D
Уважаемые разработчики Kotlin-а, прошу ответить на следующие вопросы:

Можно ли будет в обозримом будущем получать краткое описание методов прямо в IDEA без гугления.
К примеру описание функций let, apply, also из сорцов не получить, а очень хочется.

Откуда ts2kt сейчас (либо в будущем) будет брать nullability информацию из дескрипторов, которые этой информации лишены? Есть ли какая-то механика, либо будет организована работа только для дескрипторов с оной?

Есть ли публичном доступе roadmap для KotlinJS?
Чего можно ждать в обозримом будущем от KotlinJS?
В частности интересует момент с Mixin-ами.
Будет ли возможность помечать методы интерфейса как уже реализованные?

Библиотека kotlin.js — 1Mb, планируется ли существенно сократить его размер?
Возможен ли будет вариант, когда только нужная функциональность будет реализована напрямую в финальном js-файле? К примеру, чтобы Hello World не тянул за собой метровую зависимость, а все нужное содержал уже внутри.

Спасибо.
Чего можно ждать в обозримом будущем от KotlinJS?

Инкрементальной компиляции, минификации aka dead code elimination (так же известный под названием tree shaking, которое меня немного выбешивает), куча примеров кода, работающего с современными фреймворками (такими, как React) и документации. Это совсем ближайшее время, буквально несколько месяцев. Дальше пока не планировали (или по крайней мере, я не в курсе). Так же надеюсь, что будет время немного улучшить интероп, например, завести правильные external enum. Ещё есть пользователи, которые очень хотят генерацию микромодулей и ES6, мы держим это в голове, и активно обсуждаем, но конкретных сроков у нас сейчас нет.


Ещё в Kotlin есть такой минус, что достаточно неудобно разрабатывать проект, в котором есть общая кодовая база между JS и JVM. Этот момент непосредственно к JS не относится, там больше по части общекомпиляторной работы и всякого тулинга. Я так понимаю, что мы над этим будем работать в ближайшее время, но по срокам пока непонятно, скорее всего, в обозримом будущем удастся выпустить common-модули в экспериментальном режиме.


Будет ли возможность помечать методы интерфейса как уже реализованные?

Не вполне понятно, что вы понимаете под этим. Можете пример из мира JS (и по возможности, пример деклараций в TS)?


Библиотека kotlin.js — 1Mb, планируется ли существенно сократить его размер?

Сократить — нет, подружить вывод компилятора с различными минификаторами или разбить на кусочки поменьше — возможно. Конечно, мы понимаем, что такая здоровенная библиотека — это плохо. Кстати, после uglify она где-то в 2 раза ужимается, а после gzip и того более.


Возможен ли будет вариант, когда только нужная функциональность будет реализована напрямую в финальном js-файле? К примеру, чтобы Hello World не тянул за собой метровую зависимость, а все нужное содержал уже внутри.

Зачем, если для этого есть стандартные инструменты? У нас в JetBrains для внутренних разработок успешно используют Kotlin в связке с webpack, Kotlin компилирует, webpack — пакует. Как-то нелогично тянуть в компилятор линковку. Есть какая-то небольшая вероятность, что мы захотим написать свой бандлер, но в ближайших обозримых планах ничего такого нет.

Не вполне понятно, что вы понимаете под этим. Можете пример из мира JS (и по возможности, пример деклараций в TS)?

TS — https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/yfiles

http://docs.yworks.com/yfileshtml/#/api/yfiles.collections.IEnumerable у которого всего один абстрактый метод, а все остальные реализованы, сейчас его можно только как абстракный класс, иначе с наследованием беда.

И пример с http://docs.yworks.com/yfileshtml/#/api/yfiles.geometry.OrientedRectangle, у которого в дескрипторе всего 2 интерфейса, но оба из них частично реализованы.
НЛО прилетело и опубликовало эту надпись здесь

Да, такие планы есть.


видимо как раз из за того что не хватает информации о типах.

В том-то и беда, что "видимо". GCC достаточно плохо работает на stdlib Kotlin, и пока не вполне очевидно почему. Возможно, дело в типах, возможно, в чём-то другом. Это вопрос требует исследования, и мы планируем потратить на них какое-то время.

НЛО прилетело и опубликовало эту надпись здесь
Можно ли будет в обозримом будущем получать краткое описание методов прямо в IDEA без гугления.
К примеру описание функций let, apply, also из сорцов не получить, а очень хочется.

А в чем пробоема? "Quick Documentation" должен работать.


Откуда ts2kt сейчас (либо в будущем) будет брать nullability информацию из дескрипторов, которые этой информации лишены?

В декларациях на TypeScript такая информация может присутстовать, аля Type | null и конвертор это пользуется.

В декларациях на TypeScript такая информация может присутстовать, аля Type | null и конвертор это пользуется.

Без такой информации в обычном случае получаем по сути неактуальные враперы?
А в чем пробоема? «Quick Documentation» должен работать.

Кроме самой декларации там ничего не наблюдаю
image

Не могли бы Вы создать issue с проектом на котором это повторяется и указанием версий IDEA и плагина.


Спасибо!

KT-16609 — заработало, но с ошибкой

Спасибо

Извиняюсь, возможно оффтоп — в Киеве будет кто-то устраивать релиз-ивент?
*.gradle.kts файлы только с приходом нового gradle будут без проблем отображаться?
На текущий момент плагин 1.1.0-beta-38-IJ2016.3-1 — последний кто kts файлы без проблем отображает.
Все следующие жалуются на функции стандартных типов.
Да, это заработает в Gradle 3.5.

Какие преимущества есть у Kotlin по сравнению с TypeScript, чтобы ради них идти на такие жертвы?

А можете чуть подробнее сказать, под «жертвами» что вы подразумеваете?

Жертвы действительно есть:


  1. Компилятор (пока) работает на JVM, соответственно, чтобы полноценно компилироваться в JS, не хватит только node.js/webpack, нужно ещё ставить JVM. Для JS-разработчика, у которого стоит нода, но не стоит JVM, это может стать препятствием.
  2. У нас (пока) нет лоадера для webpack. Т.е. нужно настраивать gradle для компиляции Kotlin и webpack для всего остального. Это, конечно же, не касается пользователей какого-нибудь google closure compiler.
  3. Система типов Kotlin изначально проектировалась с прицелом на JVM, система типов TypeScript — с прицелом на JS. В итоге, не всегда Kotlin так же хорошо ложится на JS, как TypeScript. Например, в Kotlin поддерживается перегрузка функций по типу параметров, чего нет в JS (и следовательно, в TS). Таким образом, по умолчанию Kotlin при компиляции функций с параметрами дописывает к их названию некий суффикс, полученный страшным алгоритмом. Конечно, есть аннотация @JsName, которая позволяет явно задать имя функции в JS. Другой пример — отсутствие union types в нашей системе типов.
  4. Мы тащим с собой жирный рантайм (1,2 мб), и (пока) не умеем из него вырезать неиспользуемые части.
  5. Мы (пока) не умеем компилироваться инкрементально.

Как видите, часть проблем здесь из разряда "пока не успели сделать" (в основном по тулингу, у нас 1.2 как раз будет на нём фокусироваться), а часть "ничего нельзя поделать". В первом случае надо подождать, во втором — мы пытаемся минимизировать боль от последствий.


Если у кого-то есть что-то ещё добавить к списку — пожалуйста, отписывайтесь к комментам, мы будем рады перечисленные недостатки устранить.

НЛО прилетело и опубликовало эту надпись здесь

Разумеется, так сделать можно, и на первых порах мы возможно так и поступим. И тут придут апологеты TypeScript и начнут сравнивать размеры npm-пакетов. В перспективе, возможно, удастся скомпилировать kotlinc с помощью какого-нибудь AOT-компилятора или полностью вырезать из компилятора все зависимости от Java.

Я так понимаю, возможность писать на одном языке бэкэнд и фронт-энд для Android, iOS (скоро) и веба. TS компилируется только в JS. Конечно, можно TS на ноде гонять, но не всем подходит нода. Опять же, можно TS гонять на Cordova/React Native, но нативное приложение должно шустрее работать. Плюс синтаксические вкусности, которых нет в TS:


  • declaration site/use site variance;
  • нелокальные return-ы (например, можно взять и сделать return из вызывающей функции прямо из лямбды, переданной в функцию map);
  • смарткасты;
  • богатые возможности для построения DSL;
  • навороченные корутины

Ну и не забывайте про тех пользователей, которые уже используют Kotlin на JVM, и хотят на нём же писать и веб-клиент (либо с нуля, либо переписать на нём имеющийся JS-клиент).


В принципе, тот факт, что мы не сможем поспеть за TS в плане лёгкости интеропа и тулинга (да и TS уже банально прочно занял нишу), лично мне понятен. Мой персональный приоритет — это создание именно такого языка, который позволял бы легко бы писать fullstack-приложения. К сожалению, это пока не совсем так, но я надеюсь, мы движемся в правильном направлении и скоро Kotlin станет полноценным языком для fullstack-разработки.


С другой стороны, мы не сможем перегнать TS, но нам есть, куда расти. Задачей к 1.1 было стабилизироваться, т.е. задизайнить минимальный набор необходимых фич, причём так, чтобы потом не ломать совместимость. Ну и конечно, пофиксить баги и реализовать недостающие языковые фичи, доступные в Kotlin JVM. Некоторыми вещами в интеропе пришлось пожертвовать (например, теми же строковыми enum-ами), но никто не мешает их сделать к следующим версиям языка.

Разработчики, разработчики никогда не меняются… GWT, Silverlight… :D

Насчёт Silverlight не знаю, а вот GWT я успешно использовал в production на протяжении трёх лет и очень был доволен. Но у GWT есть фатальный недостаток — он не понимает Kotlin. Хочу пояснить — я хорошо знаю JavaScript и вполне способен писать приложения на каком-нибудь Angular. Проблема в том, что я этого делать не хочу:


  1. Мне JavaScript банально меньше нравится.
  2. Язык — это не только сам язык, но и ещё целая куча технологий вокруг него — библиотеки, системы сборки, IDE, линтеры и т.п. Лично мне неприятно всё время переключать в голове контекст с одного на другое. Да и объём знаний там немаленький, пришлось кучу времени потратить, чтобы переключиться с Java на JavaScript. И собственно язык — это пара дней работы, вся остальная куча времени пришлась на ту самую пресловутую экосистему.
Просто история повторяется :)
JavaScript без своей экосистемы — не очень вкусен. Постоянно поддерживать интеграцию с ней то же мало приятного. Позавчера Grunt, вчера Gulp, сейчас Webpack. Как быть с новыми фичами языка? Это все ограничивающие факторы. Для JS разве что TypeScript, ибо он хитрое надмножество. Но это в любом случае еще один уровень абстракции, за который надо платить.

Я то же не любил JS. Потом смирился :) И с удовольствием использую его на фронте и C# в бэке. Поэтому если мне прижмет использовать redux-observable, я не буду ломать себе голову как мне это и интегрировать с какой-то абстракцией.

Со стороны это похоже на попытку сделать универсальный инструмент для всего и всех. На текущем этапе жизни я уже в такое не верю :)
JavaScript без своей экосистемы — не очень вкусен.

GWT прекрасно живёт в своей экосистеме. Сборка — Maven, хранилище артефактов — тот же maven central или jcenter, линтеры — checkstyle и PMD, библиотеки и фреймворки — специально написанные для GWT или портированные с "большой" Java, либо обёртки вокруг JS-ных библиотек. Минификацию делает сам (причём сильно лучше новомодных webpack-ов), модульность на уровне модулей Maven.


Постоянно поддерживать интеграцию с ней то же мало приятного.

Мне кажется, это утверждение из разряда "у страха глаза велики". Там достаточно много всего, но интегрироваться с этим не так сложно, есть вещи более-менее устоявшиеся. Ну и да, всё "быстро меняется" в восторженных статьях на Хабре, а весь мир по-прежнему сидит на jQuery.


Со стороны это похоже на попытку сделать универсальный инструмент для всего и всех.

Нет, это попытка сделать инструмент для тех, кто хочет fullstack на Kotlin. Кому нормально писать фронтэнд на JS, тот и дальше будет писать на JS.

Я не спорю, что сам в себе GWT хорошо живет для специфических проектов. WebForms в аспнете то же живут у кого-то. Проблема в том, что это изолированная часть веба и не всегда развивается вместе с ним.
Тут все просто — Frontent разработчики используют React/NG2/Vue и тд. Зачем им GWT и подобные абстракции? Все и так отлично. Еще и WebAssembly завезли :D

Вообще все давно изменилось :) И таки да, это геморой еще тот. Сам сталкивался с тайпингами в TS, когда он еще не развился до текущего уровня. И это с учетом, что он все таки близок к JS.

Зачем? Если это будет сколько нибудь сложный UI — ну его в пень такой fullstack ;) Народ запаритесь искать и будете бороться с corner-case'ами.

Тут все просто — Frontent разработчики используют React/NG2/Vue и тд. Зачем им GWT и подобные абстракции? Все и так отлично.

Во-первых, я же уже сказал — ИМХО, компилятор из Kotlin в JavaScript больше нужен Kotlin-разработчикам, которые захотели ещё писать фронтэнд, а не фронтэнд-разработчикам, которые уже счастливы с JS.


Во-вторых, если так мыслить, то вообще никогда ничего нового не будет появляться. В 80-е разработчики прекрасно жили с Cobol. А сейчас люди прекрасно сидят на Java, так что, теперь из этого следует, что Kotlin не нужен? Нет, оказалось, что на это есть какой-то спрос, нашлась ниша. Возможно, найдётся ниша для компилятора в JavaScript. Пока самая очевидная — это та, которую я назвал, но реальность как всегда такова, что выстрелить язык может там, где никто этого не ожидал. Глупо не попытаться использовать шанс, если он есть. Ведь хуже будет, если Scala.js выстрелит, в этом случае Kotlin придётся запрыгивать в уходящий поезд.


Еще и WebAssembly завезли

А это вообще мимо кассы. WebAssembly — это средство для бородатых дяденек, пишущих на C и C++ запускать свои шустрые программы в браузере. Мне кажется, пересечение с "традиционным" фронтэндом и всей его экосистемой — минимальное. Вот это отличный шанс туда запрыгнуть новым многообещающим языкам.

Очень специфичный кейс.

Компиляторы в JS отнюдь не новинка ;) Никто не говорит про то, что не надо развиваться. Вопрос в скоупе и необходимости тратить ресурсы на него. Если у Kotlin что-то получится — будет хорошо. Scala пусть со своим sbt разберется, перед тем как на js взлетать :)

https://github.com/kg/ilwasm :D
Мне кажется, пересечение с "традиционным" фронтэндом и всей его экосистемой — минимальное.

А мне кажется, что очень быстро зайдёт в "традиционный". Хотя бы просто как замена и(или) дополнение к минификаторам.

WebAssembly ещё очень далеко до того, чтобы на нём сделать полноценную реализацию движка JS. Сейчас там нет ни GC (и сложно сделать свой, т.к. нет доступа к стеку), ни вообще какого-либо способа пропатчить код в рантайме или повыставлять защиту страниц памяти.


По поводу эффективности бинарного формата в плане размера. Если интересно, у меня есть свой экспериментальный транслятор байт-кода Java в WebAssembly, вот работающий пример приложения. Так вот, размер JavaScript — 274 кб, размер WebAssembly — 488 кб.

Если серверная часть написана на Java, то GWT вполне себе хороший выбор для клиентской части. Зачем тянуть React или Angular, тем более, что общего между ними почти что ничего?
По моему опыту никаких преимуществ нет. TS генерирует код, мало отличающийся от исходников, из внешних зависимостей — пара функций на 10 строк в сумме. Kotlin же тянет с собой мегабайтную библиотеку и в генерированном коде черт ногу сломит. Кроме того, TS на порядок проще. Так что пока выбор очевиден.
Kotlin же тянет с собой мегабайтную библиотеку

Я же уже писал — мы постепенно решим эту проблему


в генерированном коде черт ногу сломит

А можно про это поподробнее? Что именно непонятно в коде? Кроме очевидных вещей вроде манглирования идентификаторов (что на мой взгляд не сильно страшно) назовите хотя бы несколько пунктов.


Далее, а зачем генерируемый год должен быть читаемым? Вы часто смотрите на машинный код, сгенерированный каким-нибудь gcc?


Кроме того, TS на порядок проще.

И про это можно подробнее? Опять же, хотя бы несколько пунктов.

Далее, а зачем генерируемый год должен быть читаемым?

Для отладки непосредственно в среде исполнения (читай — браузере). Среда бросает исключение, например, и ссылается, как ни странно, на сгенерированный код, разве что source map есть и нормально подключился.

Вот мне кажется, что лучше уметь порождать точный source map, чем стремиться к 100% читаемости сгенерированного кода. А для тех случаев, если всё же пришлось подебажить сам сгенерированный код, мне кажется, Kotlin порождает достаточно читаемый код.

Почему методы Iterable (map/filter/drop/take и пр.) возвращают уже материализованный List? Почему не сделано как в C#? Получается, при написании цепочки действий, скажем map->filter->drop->take будет выделение памяти на каждом этапе?
В kotlin можно на любой коллекции вызвать asSequence и перейти к lazy вычислениям в map->filter и т.п.

Это было сделано из соображений удобства и производительности. Удобство в том что не нужно дополнительно звать коллектор в конце. Производительность проявляется в том что на маленьких коллекциях (до 10`000), которых большинство, локальность операций по памяти важнее чем выделение-освобождение списков.


И как уже упомяналось, в любой момент можно перейти к ленивой семантике с asSequence() или даже к Java8-streams с asStream()

Ну теперь вместо одного коллектора нужно всегда дёргать asSequence+коллектор. 99% вызовов не единичны, а сразу пачка. Да и просто это не логично — Iterable предполагает, что это просто перечисление — и практически все методы у него материализующие. В C# IEnumerable возвращает IEnumerable.
Что такое «локальность операций по памяти»?
Чтобы не было выделения памяти при промежуточных операциях можно/нужно использовать Sequence (однопоточный аналог Stream). Для него есть те же методы, но возвращают они тоже Sequence.
Книгу будете апдейтить?
Пока никаких договорённостей с издательством на этот счёт нет.
Это позволяет разрабатывать веб-приложение целиком на Kotlin

В смысле фронт будет компилироваться в JS, а бэк в JVM? Или можно и бэк скомпилировать для запуска под нодой, чтобы JVM в продакшене не было?

Предполагается, что можно будет и так и так

Планируются ли какие-нибудь обучающие материалы для людей не из java мира? К примеру для тех, кто знает только js. Так сказать, с нуля и сразу Kotlin…
«Новый» тернарный оператор увидит свет в ближайших релизах?
Либо if будет его заменой еще долго?

P.S. Режут глаз места, где тернарник просится, а приходится писать if.
Поясню вопрос.

Летом прошлого года вопрос о тернарном операторе был открыт.
Андрей Бреслав на одной из встреч говорил о том, что в классическом виде (? и :) он в Котлин уже не попадет, а в каком виде он может войти и вообще войдет ли — вопрос открытый.

Собственно хочется знать не закрыт ли этот вопрос окончательно.
Господи, что трудного я не понимаю в разработке дизайна потоков/корутин/фиберов?
Что вы вокруг этой темы все скачете, развели тут бардак XD

Неужели так сложно писать код вида:

$base = new ThreadBase();
$thread = new Thread(function () { ...some_code… });
$base->run(thread, thread2,… threadn);
$base->when(thread, thread2,… threadn)->done(function (req, res) {
// some code
});

Ну то есть вот в такой нотации что не ясно то?

То future() какой-то придумают, чтобы повесить событие и только потом сделать обычный синхронный запрос.
То превратят синхронный в асинхронный, а потом наоборот, запутают всех и сидят типа гении, раз никто не понимает. То какие-то корутины, то еще что-то…

В PHP симуляция потоков все ставит на свои места…
Неужто так сложно относится к процессу многопоточности, как к чтению например данных с сервака?

Кинули запрос, получили ответ, считали ответ, перевели из json-а в данные, работаем с полученными данными.

В PHP не хватает разве что возможности подождать конкретный поток или массив потоков, они там пачкой запускаются ровно столько, сколько нужно, в яваскрипте этой проблемы нет — «деферы» есть.

Согласен, всегда писать на деферах — можно уехать крышей, но сообразить для них обертку и не велосипедить — это мужество нужно.
Как по мне — цирк, блин.
НЛО прилетело и опубликовало эту надпись здесь

ИМХО, я бы предпочёл использовать какой-то фреймворк для существующего языка вместо того, чтобы учить новый язык ради решения очередной частной проблемы.

Здравствуйте, могли бы рассказать как вы сохраняйте интероп с java вводя корутины?
Есть ли возможность вызвать suspend function из java?
Как бы например выглядело использование buildSequence в java?
В какой kotlin код транслирует ts2kt такие ts конструкции (intersection types, union types)?


function extend<T, U>(first: T, second: U): T & U {...}
function padLeft(value: string, padding: string | number) {...}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий