Pull to refresh

Comments 16

— И последний вопрос: если бы вы могли изменить в Kotlin одну вещь, что бы это было?

— Думаю, я бы избавился от Unit. Он немного раздражающий. Особенно при взаимодействии с некоторыми другими языками.

Сорри, не понял: что именно Марсину Москале так не нравиться в Unit и его интеграции с другими ЯП? Понимаю, если бы он про companion objects упомянул, но про Unit… И раз Unit плох, то что вместо него в таком случае?
Когда увижу его на Mobius, попрошу развернуть мысль)

Unit плох тем что он не то же самое что void. Это заметно если вы в джаве, например, оверрайдите/имплементите котлинскую функцию, возвращающую Unit.

То есть его нужно на void заменить?

Нет, не нужно, т.к. не джавой единой

Так другим языкам в описанной мной конструкции тоже надо возвращать Unit.VALUE, разве нет?

Но имхо тогда уж void плох тем, что он не Unit.
А то, например, есть интерфейс типа Callable<In, Out> и внезапно выясняется, что void в качестве типа не подставить, начинаются костыли с типами-заглушками (тот же Void).

Возможно, но void на момент создания котлина уже был.

А у Котлина есть своя экосистемы? Можно эффективно разрабатывать и разворачивать те же веб-приложения и сервисы, ничего не зная о Java? Или это как TypeScript: всё что есть "родного" только компилятор и плагины в IDE, даже пакетного менеджера нет и используются пакеты JavaScript, более того пакет на TypeScript публикуется в виде JavaScript пакета, в котором есть много JavaScript кода и немного определения типов TypeScript.

Я не о нативной компиляции, я именно об экосистеме. Вот открыл первый попавшийся пример Kotlin native, а там половина корневой директории gradle-файлами занята. Или вот https://github.com/JetBrains/kotlin-native/blob/master/samples/html5Canvas/src/httpServerMain/kotlin/HttpServer.kt#L21 — импорт из java

Если правильно понимаю, с экосистемой вкратце так: в Android-разработке всё уже цветёт и пахнет (и библиотеки сразу на Kotlin пишут, и в официальной документации примеры по умолчанию на Kotlin, и так далее), а в остальных направлениях пока что сложнее, но работа идёт и в JetBrains совершенно не хотят оставаться «джавовым тайпскриптом».
UFO just landed and posted this here

Ну вот в PHP очень многие библиотеки стандартные лишь обёртки над системными (читай сишными) либами и, думаю, 99,99% PHP программистов в лучшем случае об этом только догадываются, хотя и плюются от неконсистентности API, но никогда сишных исходников не открывали. Так что обёртка обёртке рознь.


Проблема скорее в оценке сроков первого проекта на Kotlin. Грубо говоря, объём документации по Kotlin — это одно число, а если к нему добавить Java — совсем другое.

Рекомендую его доклад "Kotlin Not-to-Do List", много интересных вещей затрагивает. Отличный докладчик в целом.
имхо: не Марсин, а Марчин правильно будет.

Sign up to leave a comment.