Pull to refresh
1
0
Александр Удалов @udalov

Пользователь

Send message
Спасибо! Про кодогенерацию в Котлине завёл issue: https://youtrack.jetbrains.com/issue/KT-12497
Одна из основных причин была в том, что писать на таком языке было неудобно, а читать его — неприятно. Повсюду вопросительные и восклицательные знаки, которые не очень-то помогают из-за того, что расставляются в основном, чтобы удовлетворить компилятор, а не чтобы корректно обработать случаи, когда выражение вычисляется в null. Особенно больно в случае дженериков: например, Map<String?, String?>?.
Tools -> Kotlin -> Show Kotlin bytecode. Или Ctrl+Shift+A (Cmd+Shift+A) -> "bytecode"
У нас есть интерфейс Sequence, операции на котором имеют ленивую семантику. Преобразовать коллекцию в Sequence можно, вызвав asSequence, а обратно — toList/toSet. На Sequence определены практически все экстеншны, доступные и на обычных коллекциях: map, filter, drop, take и т.д.
Пока что можно на unused классе нажать Alt+Enter -> Edit inspection profile setting -> Configure annotations и добавить туда нужную аннотацию, класс должен перестать быть unused
Когда тип указывается до имени, то двоеточия не нужно, читабельность выше. Ты сразу понимаешь с чем работаешь, а потом уже смотришь на имя.

Но ведь… Разве имя не более точно указывает, с чем работаешь? :)

Синтаксис с типом после имени более удобен тем, что его можно опускать, если в языке есть вывод типов. Опустить тип, который указан перед именем переменной, получается как-то не очень красиво.
Да, будет спецификация языка.

Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
1) Вот, что смог вспомнить, но это далеко не всё:

  • self type, отказались, т.к. вредит Java-интеропу;
  • reified generics, не придумали хорошего решения, и тоже Java-интероп;
  • хотели сделать, чтобы '==' был по конвенции, а не доступен на чём угодно (если есть в скоупе функция equals, возможно экстеншн, то '==' вызывает её), а также интерфейс Hashable с функцией hashCode, но это было давно и сейчас уже звучит несколько забавно;
  • была идея сделать все модификаторы аннотациями, не получилось;
  • хотели сделать полную защиту от NPE и считать всё, что из Java, nullable. Это была долгая и поучительная история
1) Если писать код, эквивалентный аналогичному коду на Java, то производительность почти ровно такая же. На данный момент нам неизвестно никаких существенных проблем с перформансом. Единственное заметное отличие от байткода Java — для выражений и параметров non-null типов у нас генерируется приличное количество проверок на null, но, по нашему опыту, они не особо что-то замедляют (кроме того, они отключаемы).

Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.

С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.

2) Планируется.

Information

Rating
Does not participate
Location
München, Bayern, Германия
Registered
Activity