меня в котлине пока только его связь с джавой напрягает)

что за связь?

порочная

что за связь?

Валентная ?

что за связь?

монструозные API на библиотеках с кучей абстрактных фабрик экосистема которая на этом завязана, всякие спринги и тд помимо корутин нужно еще париться о потоках повсюду блокирующее и синхронное апи, либо убогий rx новым людям в языке сложно это все дается

монструозные API на библиотеках с кучей абстрактных фабрик экосистема которая на этом завязана, всякие спринги и тд помимо корутин нужно еще париться о потоках повсюду блокирующее и синхронное апи, либо убогий rx новым людям в языке сложно это все дается

это проблема не Java, а говнокода. Она существует во многих языках, которые сами по себе вроде не так плохи.

это надо на Go писать, ни дженериков, ни исключений, ничего лишнего

Match pattern*

это проблема не Java, а говнокода. Она существует во многих языках, которые сами по себе вроде не так плохи.

+

монструозные API на библиотеках с кучей абстрактных фабрик экосистема которая на этом завязана, всякие спринги и тд помимо корутин нужно еще париться о потоках повсюду блокирующее и синхронное апи, либо убогий rx новым людям в языке сложно это все дается

на котлине говнокодить можно тоже

это проблема не Java, а говнокода. Она существует во многих языках, которые сами по себе вроде не так плохи.

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

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

если JB смогут сделть multiproject + common - то появится вакансия где нужно будет знать только котлин, и они будут писать бизнес код, имхо. И это идельный расклад

а вообще то что развивают свой ktor, serialization и тд проекты это круто

я именно после того как почитал код ktor начал хейтить

я именно после того как почитал код ktor начал хейтить

Пожалуйста, ткни в примеры кода

https://github.com/ktorio/ktor-samples/blob/master/app/httpbin/src/HttpBinApplication.kt

а что именно смущает?

https://github.com/ktorio/ktor-samples/blob/master/app/httpbin/src/HttpBinApplication.kt

Так тут же пример реализации. Все отлично

меня только fun Application.main() { fun Route.handleRequestWithBodyFor(method: HttpMethod): Unit { эти штуки сразу сбивали с толку

а что они делают? скажите плз. я до сих пор не знаю. искал, не нашёл

плез

Документацию надо прочитать хотя бы один раз. Если не поможет, то два. А если ещё не помогло, идите в го.

Даю подсказку: extension

Между прочим, самая клёвая стука во всей котлине.

Между прочим, самая клёвая стука во всей котлине.

+

Документацию надо прочитать хотя бы один раз. Если не поможет, то два. А если ещё не помогло, идите в го.

+

https://ktor.io/servers/application.html#modules

https://ktor.io/servers/application.html#modules

и

всем привет. есть какие-то соглашения глобальные на тему того, как аннотации должны писаться у параметров основного конструктора (в той же строке, или на предыдущей)? в "Coding Conventions" предлагается только аннотации без аргументов писать в той же строке. но в примерах в интернете пишут, обычно, аннотацию в той же строке, например из документации jackson "@JsonProperty("address") lateinit var primaryAddress: String" пишется в одну линию, но тут есть аргумент.

Хм у нас стикеры больше на удаляться что ли ?

для метрики что лучше испольовать, либо надо что то свое написать ?

вообще есть какой-нибудь проект с открытыми исходниками, который можно посмотреть, чтобы проникнуться тем, как правильно должен код на котлине выглядеть в смысле оформления?

вообще есть какой-нибудь проект с открытыми исходниками, который можно посмотреть, чтобы проникнуться тем, как правильно должен код на котлине выглядеть в смысле оформления?

https://github.com/JetBrains/kotlin ?

А вообще в IDEA есть же новый официальный стиль-форматирования

Вот интересно и зачем же приделывать/расширять к Application метод main() ? как до такого додумались ?

Вот интересно и зачем же приделывать/расширять к Application метод main() ? как до такого додумались ?

ты можешь написать обычный main

вообще есть какой-нибудь проект с открытыми исходниками, который можно посмотреть, чтобы проникнуться тем, как правильно должен код на котлине выглядеть в смысле оформления?

Многое описано тут: http://kotlinlang.org/docs/reference/coding-conventions.html

Вот интересно и зачем же приделывать/расширять к Application метод main() ? как до такого додумались ?

"приделывать" - странно звучить, что ты под эти понимаешь. "расширять к Application" - ты расширяешь Application созданием в ней функции main

тут нет магии

Многое описано тут: http://kotlinlang.org/docs/reference/coding-conventions.html

там сильно общие слова

там сильно общие слова

я где то видел ввидео, и там было описано как включить в идее автоинспекцию, которая включала исправления (ее то нашел) и как получать текущий кодстайл. Но найти сам не могу

там сильно общие слова

Ну некоторые случаи не покрыты, тут уже кто во что горазд. Идея форматирует из коробки всё как надо. Для примера можно посмотреть например ktor

и пакет ктор видит main не смотря на то что он не импортит мой пакет? не импортит пакет, но видит "statically resolved function" из него ??

там сильно общие слова

Местами неожиданно детально, например "Do not use tabs"

И я не понимаю, почему по дефолту наследуемые классы/интерфейсы отделяются двоеточием с двумя пробелами class FooImpl : Foo, а тип возвращаемого значения функции двоеточием с одним пробелом - fun Foo(): Foo, есть ли в таком непостоянстве какой-то скрытый смысл?

И я не понимаю, почему по дефолту наследуемые классы/интерфейсы отделяются двоеточием с двумя пробелами class FooImpl : Foo, а тип возвращаемого значения функции двоеточием с одним пробелом - fun Foo(): Foo, есть ли в таком непостоянстве какой-то скрытый смысл?

мне проще читается, а разделения классов с интерфейсами пришло из с++ и с#, скорей всего

И я не понимаю, почему по дефолту наследуемые классы/интерфейсы отделяются двоеточием с двумя пробелами class FooImpl : Foo, а тип возвращаемого значения функции двоеточием с одним пробелом - fun Foo(): Foo, есть ли в таком непостоянстве какой-то скрытый смысл?

+ class Name( val name: String = "sada", val age: Int = 22, ... ) : { } вот така конструкция лучше смотрится, имхо

И я не понимаю, почему по дефолту наследуемые классы/интерфейсы отделяются двоеточием с двумя пробелами class FooImpl : Foo, а тип возвращаемого значения функции двоеточием с одним пробелом - fun Foo(): Foo, есть ли в таком непостоянстве какой-то скрытый смысл?

хм, я думал я один этого не понимаю )

а в функциях ":" не только в котле без пробела пишется

так а зачем по-разному писать в разных местах?

так а зачем по-разному писать в разных местах?

разницу видно: коструктор с наследованием и функция

ну и JB не настаивают на кодстайле, это их "видиние яп" (что-то в таком духе)

Тогда уж и C#, но да, Swift почти один в один.

Да так с любым языкoм будет. Вoпpoс всегда в стеке библиoтек и вpемени, кoтopoе вы будете их изучать. Язык-тo oсвoить любoй в целoм ничегo не стoит.

https://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-in-kotlin-1-3-m1/

> Capturing when subject in a variable Два года ждал)) все теперь все домашнее на 1.3 надо перевозить

Вау корутины не экспериментальные

И СЕРИАЛИЗУЕМЫЕ!

Сколько классных фич)

Релиз бомба )

Сколько классных фич)

но ведь фичи - это лишнее, ведь так сложней код понимать, все нада знать ..

☺️?

но ведь фичи - это лишнее, ведь так сложней код понимать, все нада знать ..

Всё знать не обязательно

По надобности можно обращаться к докам

ничоси, Бреслав не просто кулстори рассказывал, такой баг реально был https://youtrack.jetbrains.com/issue/KT-21354

Всё знать не обязательно

а как читать чужой код?

Ну знать всё невозможно же)

ERROR: S client not available

но ведь фичи - это лишнее, ведь так сложней код понимать, все нада знать ..

Котлин прекрасен тем, что тут объём знаний небольшой, а эффект гиганский. Просто не надо мозговывертом в коде заниматься...

Котлин прекрасен тем, что тут объём знаний небольшой, а эффект гиганский. Просто не надо мозговывертом в коде заниматься...

с - сарказм, выше почитайте

Unsigned это шикарно

Многое описано тут: http://kotlinlang.org/docs/reference/coding-conventions.html

может запинить ?

https://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-in-kotlin-1-3-m1/

хмм, почему 255 параметров функции — предел? Там же варарг, а предельный размер массива — в районе двух миллиардов.

Это на уровне исходников варарг. А в байткод через хак компилятора попадает прямое перечисление параметров. А их у JVM больше 255 не может быть

хмм, почему 255 параметров функции — предел? Там же варарг, а предельный размер массива — в районе двух миллиардов.

Ну так у параметров же типы разные могут быть

Это на уровне исходников варарг. А в байткод через хак компилятора попадает прямое перечисление параметров. А их у JVM больше 255 не может быть

а что там за хак? Разве JVM каким-нибудь образом поддерживает варарги?

Ну так у параметров же типы разные могут быть

Не понял, к чему это

JVM то поддерживает, но в котлине просто ипользовали синтаксис варарга, чтобы не писать кучу функциональных типов

Это на уровне исходников варарг. А в байткод через хак компилятора попадает прямое перечисление параметров. А их у JVM больше 255 не может быть

А не массив?

// Here, we load all arguments on the stack, then wrap them into array and then // invoke Lkotlin/jvm/functions/FunctionN.invoke([Ljava/lang/Object;)Ljava/lang/Object; block(Any(), Any(), ..., Any())

JVM то поддерживает, но в котлине просто ипользовали синтаксис варарга, чтобы не писать кучу функциональных типов

каким образом она поддерживает?

Короче тут всё описано: https://github.com/Kotlin/KEEP/blob/master/proposals/functional-types-with-big-arity-on-jvm.md

Короче тут всё описано: https://github.com/Kotlin/KEEP/blob/master/proposals/functional-types-with-big-arity-on-jvm.md

Я именно исходя из этого КИПа вопрос и задавал.

А не массив?

ок. Тупанул. Но это не всё равно не про тот кейс

Перечитал ещё раз, внимательнее... Видимо да. Таки искуственное ограничение. Можно предположить, что просто на будущее подстраховались.

Ну такое, вроде дают возможности, но как-то скомканно и безсистемно. Например, литералы для unsigned integers зашиты, возможности для определения литералов для экземпляров своих inline classes не заявлены. Не то чтобы все сразу побегут реализовывать библиотеки кватернионов, но хочется большего для тех же DSL

как я понял, SuccessOrFailure рекомендуют использовать исключительно с Deferred, и очень настоятельно рекомендуют воздерживаться от него во всех других ситуациях? ?

Ребят, кто имеет опыт JDBC, можно ревью? https://github.com/Miha-x64/reactive-properties/blob/602558355d2936615ebec1622b92df7bb66ce43b/sql/src/main/kotlin/net/aquadc/properties/sql/jdbc-sqlite.kt Замечания можно сюда https://github.com/Miha-x64/reactive-properties/issues/32 или к коммиту

как я понял, SuccessOrFailure рекомендуют использовать исключительно с Deferred, и очень настоятельно рекомендуют воздерживаться от него во всех других ситуациях? ?

Ну да или когда уже есть готовое апи с 2 обратчиками (типа rx.single), теперь его заменить на лямбду

https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.24.0

https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.24.0

?

как я понял, SuccessOrFailure рекомендуют использовать исключительно с Deferred, и очень настоятельно рекомендуют воздерживаться от него во всех других ситуациях? ?

Скорее не рекомендуется использовать вообще

Скорее не рекомендуется использовать вообще

А зачем добавлять тогда?)

Вот тут перечислены use-cases: https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/success-or-failure.md

попробуй получить full path

и чекни, а и чем собираешь проект?

и чекни, а и чем собираешь проект?

gradle решил проблему, передав в fxml не LoginView.fxml, а /LoginView.fxml

А зачем указываешь resourse это же корень?