Rust прекрасен, а Kotlin Native чет не очень
ฝัง
- เผยแพร่เมื่อ 30 ม.ค. 2021
- Kotlin Native стал лушче? Лучше чем Rust? Проверим!
Репозиторий с кодом: github.com/thenixan/rs_vs_kna...
Задача: adventofcode.com/2020/day/2
С вами Илья Никсан и мы учим язык программирования Kotlin с нуля для начинающих программистов
Если ты хочешь быстро научиться писать код на языке котлин то смело подписывайся и следи на новыми видео на канале
Про меня:
Меня зовут Илья, мне стукнуло 30 лет
С 20 лет я плотно занимаюсь программированием и всем что связано с айти. В 2010 году я начинал карьеру как Android разработчик в QIWI. За прошедшие 10 лет я побывал во многих ролях: от джуниор-программиста, был тимлидом, менеджером, техническим директором. Успел поработать на фрилансе, в студии разработки и даже в Яндексе.
Ссылки:
nixan.org/
/ seemsnerdy
/ nixan
Было бы хорошо, если бы Вы сделали цикл видео по Rust - от азов до глубин. И - практика, конечно же!
тоже было бы очень интересно
Жду про rust. На Ютубе мало контента на русском языке!((
Расскажу о нашем использовании Kotlin Native, может кому интересно. Написана библиотека (чисто логика), которая собирается в Maven-артефакт Java/Kotlin (для Android-фронтенда и Java/Kotlin-бэкенда), npm-пакет для Javascript (web-фронтенд и NodeJS-бэкенд) и cocoapod для Objective-C/Swift (iOS/MacOs-фронтенд). Выгода в том, что код полностью протестирован в одном месте, вместо тестирования на каждой стороне по отдельности. Удобно!
на Котлин есть .count { ... } - это замена .filter { ... }.count() или .filter { ... }.size - чтобы не создавать лишний промежуточный список.
String не обязательно переводить в toCharArray() чтобы взять нулевой символ или чтобы выполить .count {...}
Так что твой код на котлин можно ОЧЕНЬ сильно оптимизировать, убрав создания огромного количества действительно лишних объектов в цикле
useLines - не только итерация по строкам файла, а ещё и закрытие файлового дескриптора в случае IOException, так что твоя реализация на Kotlin Native не совсем аналогичная JVM
Плюсую! На каждой итерации цикла есть 3 лишних выделения памяти под массивы при вызовах toCharArray и filter.
Жаль что у этого коммента мало лайков. Вот бы автор обратил внимание и сравнил повторно с учётом правок, думаю, что код на котлин практически не будет уступать.
Привет. Спасибо за контент. Хотел бы видеть еще больше видео по Rust, обзор возможностей и т.п. Буду очень рад.
Классный видос, ты любишь раст так-же как я котлин)) интересно будет послушать про раст, а котлин нейтив да платит производительностью за то что нет в языке сильных и слабых ссылок, ещё было-бы интересно послушать от тебя Flater VS kotlin multiplatform, короче крутой канал, успехов!
Про то, что kotlin Native медленнее JVM версии пишут уже давно. Хотя авторы намекают на обратное :)
Тормоза JVM версии, при неправильном замере, это просто время запуска java.exe + (возможно) "разогрев" JVM
Мсье, у вас качественный продакшен. Как так вышло, что я о вас ничего не слышал? Про раст интересно, но я невывожук, пока, что сеньор котлин дев и раст для меня выглядит максимально больно. Но может твои видео вдохновят меня на изучение раст. Спасибо за крутое видео! Контент очень качественно снят и тема интересная. Пойду смотреть дальше твои видео
Классный рассказ спасибо!
Очень крутой канал!!! Моя подписка и лайк!
Хочу твою лекцию о Rust! Жги)))
Привет, как думаешь, большие перспективы у Раст? Я писал только на пайтоне, но раст меня впечатлил и я загорелся желанием заботать его. Вообще твоё мнение по этому языку интересно
Ля , мужик , ну ты ваще крут )
Есть что-нибудь связанное с мобильной (а лучше кроссплатформенной) разработкой на раст (не через WASM)? (Понятно, что будут обвязки, но хотелось хотя бы стандартную обвязку + нативную либу).
Ну и желательно для игр. Есть движки которые это умеют?
Учу котлин по урокам в ютубе и послушав тебя,понимаю,что учить еще до жопы((
Я чет не понял. Любимый язык Rust а весь канал о Kotlin ))
Интересно. Один из лучших каналов. Желаю Божьих благословний и вдохновения, во имя Иисуса Христа.
Мои замеры с усреднением от 100 прогонов именно процедуры main внутри одного запуска приложения:
Kotlin jvm ~ 0.7 ms
Kotlin Native ~ 10 ms
Delphi (Rust не было под рукой. код разумеется другой, но по мотивам) ~ 0.9 ms
Так что все весьма интересно...
Уверены что оптимизация не вырезала ваших 100 лупов? Если они выполняют одну и ту же работу в пустую, компилятор может их убрать
Понимаю) мне в универе отбили желание в английский, ооп, и указатели, стеки, очереди и т,д
Крутой видос) Прошло три года. Как изменилась ситуация с вакансиями в rust?)
Всё еще пару штук по России😢
Вроде разработчики говорили, что используют подсчёт ссылок вместо графа достижимости (JVM).
В мультиплатформе много готовых либ, поэтому ты эти интерфейс тут будешь редко писать. И то ты их пишешь один раз, а потом из проектиков старых вытаскивает. Ну и когда к тебе приходит заказчик, а ты ему говоришь что логика может быть написана один раз, а не два например для IOS и Android, то он очевидно выберет один раз так как это дешевле. А сейчас ещё ui можно писать в мультиплатформе. Так что скорость разработки увеличивается на процентов 40+-
Боюсь тесты не корректны. Нужно исключить время запуска приложений, т.к. для маленьких задач, оно оказывает неадекватно большое влияние.
Еще и код не прогрет на JVM, в общем, опять дилетантство.
3.14k -- пик! Растём)
0:00 Рассел Кроу на минималках 😃
Только посмотрел Робина Гуда с Расселом Кроу, а тут это
1. В safe rust нет указателей...
2. Нельзя говорить о том почему что-то медленно работает не используя профайлер. Можно, но лучше не надо
Браги с версуса подался в программирование)
flutter + rust было бы круто, да, очень
🤟🏼
Trait - можно назвать что это ‘особенность’ / ‘характерная черта’
10:31 -- traits -- черты
Да, сам думал о том, что прикольно было бы увидеть что-то типа флаттера для Rust. Зачем нам этот dart? Он кроме флаттера нафиг нигде больше не нужен. На rust не хватает решений для production ready разработки в больших индустриях.
Flutter хорош, но Dart который в нем используется, так себе... Раст вместо дарта было бы круто!
Jvm медленная из-за множества гарантий потокобезопасности
реализация подсчета кол-ва символов на котлине не оптимальная
единственный значимый профит от котлин натива это интерроп с С, все! jvm по производительности ничуть не уступает тому же с++, поэтому профита по производительности не стоит искать от котлин натива
Майнкрафт щас где то поржал
@@syoritohatsuki плюсы возможно быстрее на несколько процентов, да даже на десяток иногда. Вот только коммерческая разработка это ещё и про скорость разработки и поддерживаемость, а не про бенчмарки и кто кого быстрее. И коммент был про котлин натив и его основное предназначение
@@unpub2 мой ответ бы был на слова что JVM машина не уступает C++
Одно истина. 2 года прошло. На пороге уже К2. С новым нативным компилятором. Нужны новые тесты🤣
@@syoritohatsuki и таки да, в общих задачах на бэкэнде не уступает, и напишешь ты это в разы быстрее на kotlin|java.
Так компоненты флаттера на расте уже пишут
один вопрос - почему так мало лайков?
13:02 i mean do i even need to comment, this is just embarrassing you shouldn't talk about java/kotlin
everything is passed by reference except primitive types, if you don't know that you shouldn't make content comparing languages
На тысяче подписчиков зазнался и перестал пилить видосы
На 600 у меня прост дочь родилась
dude you have no clue what you're talking about
anyone use rust for more than a year and tell me you still like it... its damn ugly as f
also it does not matter how fast your programs start
it matters how fast they run over long periods of time... anyone benchmarking jvm stuff without letting it jit compile is a moron
@@krellin It's true for backend, but on android, for example, a piece of code might newer be compiled especially by optimising compiler.
из-за дурацкой музыки не могу воспринимать что говорит автор