EfficientNet-B0 сеть должна неплохо работать на мобильны устройствах. С ее помощью можно посчитать вектора для картинок, и потом самому между векторами посчитать косинусное расстояние или L2.
Если будет чем поделиться по итогам, то было бы интересно =)
И к слову, в coroutines есть и свой aktor (правда без remote акторов и т.п.), с ним можно было бы наиболее близкие варианты сравнить в рамках запуска на одной jvm.
Спасибо за статью, было интересно почитать про настройки Akka и особенности "внутренней кухни".
А вы не сравнивали kotlin coroutines с Akka по производительности? По использованию кода с coroutines, кажется, будет даже проще чем с Akka.
В некотором виде, Kotlin можно рассматривать как "lombok на стеройдах", если знать во что он превращается в итоге. Можно посмотреть подробнее на пост Kotlin, компиляция в байткод и производительность
В backend Kotlin уже полно. Даже с блокирующим JDBC иногда имеет смысл использовать корутины. Например, можно обернуть выполнение задачи на ThreadPool в методе, который возвращает CompletableFuture, а на нем уже можно использовать await из корутин, чтобы дождаться результата.
А в скором будущем будет R2DBC, который будет возвращать реактивные типы, и на которых также можно будет вызывать методы из корутин.
Да и том же "энтерпрайзе" все равно есть вызовы других сервисов, походы в кэш, или другие "неблокирующие" действия. Корутины для них отлично заходят.
Ошибки на сервере тоже могут быть весьма разными. Можно отталкиваться от стандартных HTTP кодов ошибок.
Так пользователь может ввести невалидные данные, очень часто отправлять запросы или может быть просто не авторизован.
Цитата с google io19:
«Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.
В Java ты чаще понимаешь по узкому контексту, что происходит. a = b — запись в поле или локал, a[1] = 2 — запись в массив ..
Да, частично это так. Но с помощью такой записи можно существенно упростить код:
Как самый простой пример: HashMap<String, Map<String, String>> someMap = new HashMap<>();
//Java
someMap.put("key","value");
//Kotlin
someMap["key"] = "value"
Котлин даёт одинаковый API для коллекций и сиквенсов, из-за чего люди злоупотребляют цепочками map/filter на коллекциях, создавая кучу промежуточных неленивых копий
Возможно только по незнанию и на первых порах. Одинаковый api позволяет делать многие сложные преобразования гораздо проще. И чтобы не плодить промежуточные цепочки (хотя иногда и они нужны) достаточно просто перейти к sequence.
Кстати, об IDE. Насколько хороша поддержка Kotlin в IntelliJ IDEA? Она действительно лучше, чем для Java?
Да, она хуже :) но не сильно. Если даже сравнивать с тем же Go, то поддержка языка лучше сделана. (да и сам релиз Kotlin состоялся только в 2016, пара лет всего прошло)
Котлин форсит использование it, что приводит к нечитаемому коду. Что-нибудь типа seq.map { it -> foo(it, 1); }.map { it -> bar(it, 2); }.filter { it -> it.getBaz() > 0; }. Что это вообще было?
Это может вызывать трудности только по началу. It значительно упрощает написание лямбд с одним аргументом. А в тех местах, где есть сложные преобразования всегда можно перейти к именованному аргументу.
Цепочки вроде ?.let { foo(it); }?.let { bar(it); }
Аналогично, сложности только по началу возникают. И Если таких цепочек становится много, то скорее всего что-то делается не так, и скорее всего можно сделать по другому.
От интеропа с джавой кровь идёт из глаз
Отчасти согласен, что местами не очень удобно, но все довольно просто и понятно. Даже тот же @JvmStatic по больше части не нужен, и функция просто выносится на уровень файла.
Экстеншн-методы загрязняют публичный интерфейс такими вещами, о которых автор и подумать боялся.
Автору и не нужно думать :)
Это лишь способ сделать api удобнее у классов, которые чаще всего используются в проекте. И в любом случае от них гораздо больше пользы чем вреда.
Библиотека местами не продумана. Например, reduce.
Тот пример с reduce/fold, что вы привели, это довольно устоявшаяся конструкция. И как уже было сказано выше, текущая реализация вполне удобна.
Давайте ещё навалим про библиотеку. Нафига в стандартную библиотеку языка, который поддерживает дата-классы, включили пары? Это ж прямое поощрение плохого кода.
Как же без пар :) Они весьма полезны. И в коде очень часто возникает необходимость вернуть именно два аргумента, и для этого отлично подходит пара. Да, не везде их нужно использовать, и порой лучше сделать еще один «data class», но для «write once» или просто прототипирования они подходят отлично. А говнокод можно сделать и без них.
Очень странный момент — возможность не указывать возвращаемый тип метода (особенно публичного).
Иногда его и правда можно опустить. Как возвращение того же when, или простые однострочные конструкции. Но по большей части хорошей практикой считается явное указание возвращаемого типа.
Kotlin/Native нужен для iOS. А вообще у Kotlin (мультиплатформенного) идеология немного другая. Основная суть заключается в том, что большая часть логики выносится в общие модули и в платформенных остаются только привязки к специфичным вещам и в том числе и привязки к UI.
Вот вопрос насколько много общей логики можно вынести и как ее потом просто будет привязывать к UI пока остается открытый.
И обе основаны на Netty.
Akka как-то трудно назвать "библиотекой для работы с сетью", это огромный набор инструментов. Но да, Lightbend сейчас гарантирует что api для Java будет не хуже чем для Scala, поэтому вполне можно работать и из Java.
На счет Twitter Finagle сложно что-то сказать, с ней не работал, но она не выглядит с виду чем-то невероятным, чего нельзя найти в Java. Тот же Armeria вполне может быть аналогом.
EfficientNet-B0 сеть должна неплохо работать на мобильны устройствах. С ее помощью можно посчитать вектора для картинок, и потом самому между векторами посчитать косинусное расстояние или L2.
Практически на одном из первых этапов загрузки контента такая проверка есть. Но она отсекает только часть совсем идентичных дубликатов.
Если будет чем поделиться по итогам, то было бы интересно =)
И к слову, в coroutines есть и свой aktor (правда без remote акторов и т.п.), с ним можно было бы наиболее близкие варианты сравнить в рамках запуска на одной jvm.
Спасибо за статью, было интересно почитать про настройки Akka и особенности "внутренней кухни".
А вы не сравнивали kotlin coroutines с Akka по производительности? По использованию кода с coroutines, кажется, будет даже проще чем с Akka.
В некотором виде, Kotlin можно рассматривать как "lombok на стеройдах", если знать во что он превращается в итоге. Можно посмотреть подробнее на пост Kotlin, компиляция в байткод и производительность
Все верно, там аналогично будет в районе 360мс для всех остальных реализаций.
Да, тут лишнее =)
Спасибо, подправил.
Еще хотелось бы R2DBC под все популярные БД, в том числе для Oracle =)
Для этого есть причина. Для inline
врапперовможно делать нелокальный возврат из функции.В backend Kotlin уже полно. Даже с блокирующим JDBC иногда имеет смысл использовать корутины. Например, можно обернуть выполнение задачи на ThreadPool в методе, который возвращает CompletableFuture, а на нем уже можно использовать await из корутин, чтобы дождаться результата.
А в скором будущем будет R2DBC, который будет возвращать реактивные типы, и на которых также можно будет вызывать методы из корутин.
Да и том же "энтерпрайзе" все равно есть вызовы других сервисов, походы в кэш, или другие "неблокирующие" действия. Корутины для них отлично заходят.
Ошибки на сервере тоже могут быть весьма разными. Можно отталкиваться от стандартных HTTP кодов ошибок.
Так пользователь может ввести невалидные данные, очень часто отправлять запросы или может быть просто не авторизован.
А не рассматривали deeplearning4j?
«Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.
Today we’re announcing another big step: Android development will become increasingly Kotlin-first..»
android-developers.googleblog.com/2019/05/google-io-2019-empowering-developers-to-build-experiences-on-Android-Play.html
В backend дела обстоят тоже неплохо, и много всего уже в проде.
Да, частично это так. Но с помощью такой записи можно существенно упростить код:
Как самый простой пример:
HashMap<String, Map<String, String>> someMap = new HashMap<>();//Java
someMap.put("key","value");
//Kotlin
someMap["key"] = "value"
Возможно только по незнанию и на первых порах. Одинаковый api позволяет делать многие сложные преобразования гораздо проще. И чтобы не плодить промежуточные цепочки (хотя иногда и они нужны) достаточно просто перейти к sequence.
Да, она хуже :) но не сильно. Если даже сравнивать с тем же Go, то поддержка языка лучше сделана. (да и сам релиз Kotlin состоялся только в 2016, пара лет всего прошло)
Это может вызывать трудности только по началу. It значительно упрощает написание лямбд с одним аргументом. А в тех местах, где есть сложные преобразования всегда можно перейти к именованному аргументу.
Аналогично, сложности только по началу возникают. И Если таких цепочек становится много, то скорее всего что-то делается не так, и скорее всего можно сделать по другому.
Отчасти согласен, что местами не очень удобно, но все довольно просто и понятно. Даже тот же @JvmStatic по больше части не нужен, и функция просто выносится на уровень файла.
Автору и не нужно думать :)
Это лишь способ сделать api удобнее у классов, которые чаще всего используются в проекте. И в любом случае от них гораздо больше пользы чем вреда.
Тот пример с reduce/fold, что вы привели, это довольно устоявшаяся конструкция. И как уже было сказано выше, текущая реализация вполне удобна.
Как же без пар :) Они весьма полезны. И в коде очень часто возникает необходимость вернуть именно два аргумента, и для этого отлично подходит пара. Да, не везде их нужно использовать, и порой лучше сделать еще один «data class», но для «write once» или просто прототипирования они подходят отлично. А говнокод можно сделать и без них.
Иногда его и правда можно опустить. Как возвращение того же when, или простые однострочные конструкции. Но по большей части хорошей практикой считается явное указание возвращаемого типа.
Вот вопрос насколько много общей логики можно вынести и как ее потом просто будет привязывать к UI пока остается открытый.
Сам тоже в самом начале удивился что нет Joker, но потом повнимательней прочитал описание.
п.с. в списке еще не хватает Backend Stories 2.0
Десять лет прошло с того момента, а некоторые и за 5 лет до техлидов и тимлидов вырастают.
И обе основаны на Netty.
Akka как-то трудно назвать "библиотекой для работы с сетью", это огромный набор инструментов. Но да, Lightbend сейчас гарантирует что api для Java будет не хуже чем для Scala, поэтому вполне можно работать и из Java.
На счет Twitter Finagle сложно что-то сказать, с ней не работал, но она не выглядит с виду чем-то невероятным, чего нельзя найти в Java. Тот же Armeria вполне может быть аналогом.