Потому что тогда ты не будешь получать значения по мере их вычисления

почему? в том примере когда мы делаем http запросы, у нас это делается в N корутинах и результат бросается в send сразу же как получен ответ от сервера

Кто на митап идёт?

Кто на митап идёт?

@kug_spb?

Kugm

Kugm

уместнее спросить в соответствующем чате

Такое не скомпилируется class A(val param: String = this::class.java.simpleName) А вот так работает open class B { companion object } class A(val param: String = this::class.java.simpleName) : B() ... print(A().param)Угадайте что будет напечатано? Фича или баг?

Подскажите, слишком ли костыльное решение: есть сервер, который принимает сообщения и кладёт их в список. А есть ресайклер, который выводит сообщения на экран. Мне нужно как-то уведомить последнего, что пора обновить данные на экране. Вот что придумал: сделаю независимый channel, в который будет писать сервер, а читать будет ресайклер,. Как только channel.receive() сработало - пора обновиться. Пихать буду булеаны, наверное.

Такое не скомпилируется class A(val param: String = this::class.java.simpleName) А вот так работает open class B { companion object } class A(val param: String = this::class.java.simpleName) : B() ... print(A().param)Угадайте что будет напечатано? Фича или баг?

A$Companion?

A$Companion?

Просто Companion. Было неожиданно получить такой результат, особенно если companion object где-то глубоко

Просто Companion. Было неожиданно получить такой результат, особенно если companion object где-то глубоко

А, ну да, simpleName же. Думаю, что всё ок, this и не должен быть доступен.

А, ну да, simpleName же. Думаю, что всё ок, this и не должен быть доступен.

Наверное, лучше бы не компилировались оба варианта

А, ну да, simpleName же. Думаю, что всё ок, this и не должен быть доступен.

а почему не должен?

а почему не должен?

Это конструктор, this там ещё не инициализирован.

Это конструктор, this там ещё не инициализирован.

в джаве же инициализирован

Это конструктор, this там ещё не инициализирован.

public class Test { private String param; public Test() { this.param = this.getClass().getSimpleName(); } }

в джаве же инициализирован

Нет, объект недосоздан. То, что он доступен (даже в котлине) — скорее баг чем фича.

Нет, объект недосоздан. То, что он доступен (даже в котлине) — скорее баг чем фича.

может и недосоздан, но this вполне инициализирован, я могу оперировать с полями и вызывать методы внутри конструктора

может и недосоздан, но this вполне инициализирован, я могу оперировать с полями и вызывать методы внутри конструктора

В моём примере this вызывается до того как будет вызван конструктор, при инициализации класса. В самом же конструкторе, да и вообще при инициализации экземпляра объекта this вполне можно использовать и будет работать как и ожидалось

В моём примере this вызывается до того как будет вызван конструктор, при инициализации класса. В самом же конструкторе, да и вообще при инициализации экземпляра объекта this вполне можно использовать и будет работать как и ожидалось

сейчас проверил, вызывается именно в конструкторе

В моём примере this вызывается до того как будет вызван конструктор, при инициализации класса. В самом же конструкторе, да и вообще при инициализации экземпляра объекта this вполне можно использовать и будет работать как и ожидалось

fun main(args: Array<String>) { println(Test().test) } class Test(val test: String = defaultProp()) fun defaultProp(): String { println(Thread.currentThread().getStackTrace().joinToString("\n")) return "hello" }

В моём примере this вызывается до того как будет вызван конструктор, при инициализации класса. В самом же конструкторе, да и вообще при инициализации экземпляра объекта this вполне можно использовать и будет работать как и ожидалось

Технически это часть конструктора.

Как рестартануть корутину после того как был вызван .cancel()? Вызов .start() чёт не помог.

Подозреваю, что никак

Кроме, разумеется, создания её заново

Они вроде одноразовые. Метод start вообще для другого (запуск lazy корутины). P.S. когда мне нужна многоразовая корутина, я заменяю ее на фабрику курутин. suspend () -> T

Понятно, благодарю.

Привет. Можете ткнуть в статью про Observable для даунов?

РХовскому?

Привет. Можете ткнуть в статью про Observable для даунов?

юзай корутины)

РХовскому?

ла

да

юзай корутины)

это не взаимо заменяемые вещи носколько я понимаю

смотря для чего

ну насколько я понимаю реактив стримы это пуш модель корутины пул

ну насколько я понимаю реактив стримы это пуш модель корутины пул

отнюдь

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

а как же backpressure стримы?

На случай, если тут есть Физтехи (МФТИ). В ближайшую среду, мы попробуем сделать небольшой семинар (или скорее просто обсуждение) по поводу использования Kotlin для научных расчетов. В 15.30 в 517-А ГК. Я пока не очень понимаю, кто там будет, поэтому формат тоже непонятен. Если это будет интересно, мы потом сделаем регулярный семинар на эту тему.

На случай, если тут есть Физтехи (МФТИ). В ближайшую среду, мы попробуем сделать небольшой семинар (или скорее просто обсуждение) по поводу использования Kotlin для научных расчетов. В 15.30 в 517-А ГК. Я пока не очень понимаю, кто там будет, поэтому формат тоже непонятен. Если это будет интересно, мы потом сделаем регулярный семинар на эту тему.

Может лучше было бы об этом писать во внутренних порталах МФТИ? Или вы зовёте к себе всех со стороны?

Во внутренних порталах тысяч 6-7 человек. И сообщества для Kotlin пока нет. Я пытаюсь понять, есть ли кто-то заинтересованный, чтобы это сообщество организовать.

@noraltavir жаль, я из другого ВУЗ'а, и страны. Мне очень интересно.

Ну между вузами, а тем более между странами, это я пока не умею. То есть умею, но по физике, не по Kotlin.

Так-то я бы тоже принял участие, но я не студент, к сожалению. Тема интересная.

Да, я бы тоже принял участие, как раз два с лишним года на котлине в проде. Жаль я не студент и не технарь

Если действительно серьезный интерес будет, мы можем потом отдельный семинар в Москве сделать. Мне кажется, что kotlin может попытаться захватить кусок ниши научных вычислений у C++

Ну как и джава могла уже много лет. Но есть миф о том что плюсы быстрее

Во-первых, действительно есть миф (его надо ломать). Во вторых ученые любят быстро и на коленке, а идеология Java этого не позволяет. В Kotlin есть ряд синтаксических упрощений, которые позволяют писать код гораздо компактнее и понятнее.

Вообще, и Java 8 в этом смысле отлично работает, но тут вопрос психологии, на простую смену циферки люди не клюют, а вот на новый язык могут.

Ну и на горизонте маячит Kotlin Native...

Во-первых, действительно есть миф (его надо ломать). Во вторых ученые любят быстро и на коленке, а идеология Java этого не позволяет. В Kotlin есть ряд синтаксических упрощений, которые позволяют писать код гораздо компактнее и понятнее.

Писал простые скрипты на коленке... на Java. Так что вроде позволяет)

Кроме того, в Java 1.8 я не вижу каких-то изменений, которые сильно помогают что-то писать на коленке. А вот в Java 9 — да.

Я писал и на Java, и на Groovy, и на Kotlin. На Groovy пока лучше всего получается (потому что поддержка kts неадекватная). Но с++ или питоне быстрее получается (хотя и кривее).

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

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

jshell же

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

Я думал, речь о «скриптовости» языка.

Не чувствую разницы. Groovy уже много-много лет был.

Скриптовость - это условная вещь. Обычно под скриптовостью вообще динамическую типизацию подразумевают

А никакой язык, в котором надо писать System.out.println() никто никогда в скриптовые не возьмет. Я сам большой противник скриптов если что.

На случай, если тут есть Физтехи (МФТИ). В ближайшую среду, мы попробуем сделать небольшой семинар (или скорее просто обсуждение) по поводу использования Kotlin для научных расчетов. В 15.30 в 517-А ГК. Я пока не очень понимаю, кто там будет, поэтому формат тоже непонятен. Если это будет интересно, мы потом сделаем регулярный семинар на эту тему.

Живу рядом с МФТИ, можно будет на семинар попасть? Я с другого ВУЗа

ERROR: S client not available

Если действительно серьезный интерес будет, мы можем потом отдельный семинар в Москве сделать. Мне кажется, что kotlin может попытаться захватить кусок ниши научных вычислений у C++

А там разве не пайтон юзают (или R)? Там же код “на выброс” + все равно юзается куча готовых либ

Живу рядом с МФТИ, можно будет на семинар попасть? Я с другого ВУЗа

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

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

Отлично :)

Я писал и на Java, и на Groovy, и на Kotlin. На Groovy пока лучше всего получается (потому что поддержка kts неадекватная). Но с++ или питоне быстрее получается (хотя и кривее).

Мне kts не понравился. Если бы, как с Clojure, один раз запустил интерпретатор и работаешь — то ок. А так — скомпилируется и запустится быстрее, чем стартанёт kts.

А никакой язык, в котором надо писать System.out.println() никто никогда в скриптовые не возьмет. Я сам большой противник скриптов если что.

Что значит «противник скриптов»? :)

А там разве не пайтон юзают (или R)? Там же код “на выброс” + все равно юзается куча готовых либ

Питон, да. Но, этот самый "на выброс" часто оказывается не выброшенным. В результате возникают 4-5 этажные скриптовые конструкции.

Плюс надо понимать, что физики программировать не умеют, хотя и думают, что умеют

Что значит «противник скриптов»? :)

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

Привет. В Kotlin нужно положить число 255 (0xFF) в байт. как это лучше сделать?

Привет. В Kotlin нужно положить число 255 (0xFF) в байт. как это лучше сделать?

В Kotlin, как в Java, байты знаковые, поэтому val b = 0xFF.toByte() — это будет -128.

но 0xFF это Int ?

Литерал 0xFF имеет тип Int, да.

то что -128 туда можно засунуть это понятно. уже так делал. на особо больших числах это выглядит достаточно дико

Особо большие числа засунуть в Byte нельзя :)

бинарные протоколы наносят ответный удар :(

Особо большие числа засунуть в Byte нельзя :)

в байт то понятно

Бинарные протоколы восхитительны.)

Бинарные протоколы восхитительны.)

апач трифт - огонь

апач трифт - огонь

Почему именно он?

используем в проде, микросёрферы

(как раз хочу сделать масштабное сравнение бинарных протоколов, надо на работе убедить людкй выкинуть JSON)

Почему именно он?

гм. когда тебе дают док документ и говорят там описание бинарного протокола, то тебе не поможет ни трифт, ни протобуф

для микросёрферной архитектуры зашибись, правда мы допиливали мальца, для балансировки итд

гм. когда тебе дают док документ и говорят там описание бинарного протокола, то тебе не поможет ни трифт, ни протобуф

кастомные протоколы хороши, когда хорошо описаны, да

(как раз хочу сделать масштабное сравнение бинарных протоколов, надо на работе убедить людкй выкинуть JSON)

Зачем? Их даже “глазами” не продебажишь

и это значит, что они плохие?)

Зачем? Их даже “глазами” не продебажишь

Быстро работают, мало срут в память, надёжны.

Быстро работают, мало срут в память, надёжны.

Ну если у тебя “нагрузка” и json не вывозит, то это без вопросов. Но обычно это “экономия на спичках”

В JSON можно любое говно прислать и медленно наблюдать, как всё рушится. А вот сгенерировал proto-файл — и сразу понятно, что можно, а что нельзя.