Одна из основных причин была в том, что писать на таком языке было неудобно, а читать его — неприятно. Повсюду вопросительные и восклицательные знаки, которые не очень-то помогают из-за того, что расставляются в основном, чтобы удовлетворить компилятор, а не чтобы корректно обработать случаи, когда выражение вычисляется в null. Особенно больно в случае дженериков: например, Map<String?, String?>?.
У нас есть интерфейс Sequence, операции на котором имеют ленивую семантику. Преобразовать коллекцию в Sequence можно, вызвав asSequence, а обратно — toList/toSet. На Sequence определены практически все экстеншны, доступные и на обычных коллекциях: map, filter, drop, take и т.д.
Пока что можно на unused классе нажать Alt+Enter -> Edit inspection profile setting -> Configure annotations и добавить туда нужную аннотацию, класс должен перестать быть unused
Когда тип указывается до имени, то двоеточия не нужно, читабельность выше. Ты сразу понимаешь с чем работаешь, а потом уже смотришь на имя.
Но ведь… Разве имя не более точно указывает, с чем работаешь? :)
Синтаксис с типом после имени более удобен тем, что его можно опускать, если в языке есть вывод типов. Опустить тип, который указан перед именем переменной, получается как-то не очень красиво.
reified generics, не придумали хорошего решения, и тоже Java-интероп;
хотели сделать, чтобы '==' был по конвенции, а не доступен на чём угодно (если есть в скоупе функция equals, возможно экстеншн, то '==' вызывает её), а также интерфейс Hashable с функцией hashCode, но это было давно и сейчас уже звучит несколько забавно;
была идея сделать все модификаторы аннотациями, не получилось;
хотели сделать полную защиту от NPE и считать всё, что из Java, nullable. Это была долгая и поучительная история
1) Если писать код, эквивалентный аналогичному коду на Java, то производительность почти ровно такая же. На данный момент нам неизвестно никаких существенных проблем с перформансом. Единственное заметное отличие от байткода Java — для выражений и параметров non-null типов у нас генерируется приличное количество проверок на null, но, по нашему опыту, они не особо что-то замедляют (кроме того, они отключаемы).
Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.
С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.
Map<String?, String?>?
.Но ведь… Разве имя не более точно указывает, с чем работаешь? :)
Синтаксис с типом после имени более удобен тем, что его можно опускать, если в языке есть вывод типов. Опустить тип, который указан перед именем переменной, получается как-то не очень красиво.
Если какие-то вещи в документации имеет смысл раскрыть подробнее, это повод сообщить нам или исправить самим :) Сайт с документацией лежит на гитхабе
Другое дело, что если использовать идиомы и стандартные функции Котлина, производительность может быть даже лучше. Например, разные map/filter не только заинлайнятся вместе с передаваемой лямбдой, но и создадут правильные коллекции с оптимальной capacity.
С нативными языками, думаю, сравнивать несколько странно и этого сравнения пока никто не делал, по крайней мере мне об этом неизвестно.
2) Планируется.