Это уже обсудили в соседней ветке. В прикладных языках программистам редко приходится работать с ресурсами и, в этих редких случаях, приходится страдать. Но как бонус не надо думать о памяти в 99.99% обычного прикладного кода где нет никаких ресурсов. Это, кстати, очень надежный признак который позволяет отличить современный прикладной язык от языка системного программирования.
Речь шла про то, что рефлексии нет на Kotlin/JS, только не понятно зачем она там нужно. Source generator будет же работать на Kotlin/JVM (где рефлексия есть) и полученный код может работать на Kotlin/JS без всякой рефлексии.
Данный код печатает на экран значение каждого поля, как я понял. То же самое очень легко делается через kotlinx.serialization (поля, которые не нужно обходить, можно пометить Transient). А в чем конечная цель?
Извините, но я ничего не понял. Во-первых форматирование кода настолько далеко от Kotlin Code Style (см. https://kotlinlang.org/docs/reference/coding-conventions.html ) что мне очень тяже через него продраться… и вообще что он призван проиллюстрировать? Зачем вот это всё? В чем смысла этого кода? Какую задачу вы пытаетесь решить?
А что мешает делать это сейчас? Берете какой-нибудь Kotlin Poet и генерируете нужные вам исходники. Генератор запускаете на JVM, на нем с помощью рефлексии можете пройтись по вашей модели данных и всё узнать. Результирующий код будет работать где угодно — на JVM, JS, и Native.
Про сериализацию знаем. Делаем так, чтобы можно было сериализовывать из/в любых форматов (в т.ч. в БД) без рефлексии, то есть очень быстро и абсолютно type-safe на любой платформе (JVM/JS/Native). Следите за проектом https://github.com/Kotlin/kotlinx.serialization
В C++ тоже не надо писать delete или close. Rust развивает эту идею, вынося все опасные операции в unsafe. Это круто. Но дело же не в том, что надо писать. Важно то, о чем программисту надо думать. И в Rust и в C++ программисту надо думать о том чем объекты владеют и какой вообще у того или иного объекта lifetime. В этом и основное отличие современных прикладных языков с полностью автоматическим управлением памяти, что программисту об этом думать не надо вообще. Ни декларативно, ни императивно.
Такая попытка была в языке D. В Rust же, напротив, сделали всё верно и не пошли по этому пути. В Rust нет никакого "полностью автоматического управления памятью". Программисту на Rust, как и полагается системному программисту, надо самому думать об управлении памятью и правильно применять всякие аннотации времени жизни объектов и т.п. Отличие языка Rust от C и C++ в том, что Rust из-за этого получается более надежным, так как ошибки работы с памятью (если не использовать unsafe) приведут к ошибке компиляции, а не к падению во время исполнения.
Да. Всё так. Некоторые языки пытались совместить полностью автоматический GC и ручное управление ресурсами, но успешных примеров (среди популярных языков) в настоящее время нет. Если кто-то что-нибудь на эту тему придумает, то мы с радостью реализуем.
В ближайшем будущем не стоит ожидать в языке Котлин чего-то масштаба RAII в C++ или Lifetimes в Rust. Котлин в настоящее время ориентируется на прикладных программистов, которым редко приходится работать с внешними ресурсами, требующими явного освобождения/закрытия. Для целевой аудитории языка Котлин конструкций языка типа use и её подобных в целом хватает. В сложных случаях неудобно, но приоритеты — есть более актуальные задачи дизайна языка.
Однако, в Kotlin/Native, который ставит целью удобно интегрироваться с нативной (С) экосистемой, где ручное управление памятью и ресурсами широко распространено, есть дополнительные механизмы в виде арен и memScoped выделение памяти.
Воспользуюсь случаем спросить для сбора данных. А какой у вас use-case для рефлексии? Для чего вы её используете (если для разного, то расскажи в порядке важности, пожалуйста)?
Конечено можно. C++ один из ведущих языков по количеству пользователей и Rust дает для этих программистов надежду на светлое будущее и освобождение от оков legacy. Будь я программистом на C++ я бы тоже любил Rust. Да и вообще для задач где важно четкий контроль за ресурсами и производительностью Rust рулит. Но вот если решаешь чисто бизнес-задачу, то голова занята другим. Не хочется думать о том, надо передавать объект по значению, по ссылке или в коробке, какой у него лайфтайм и т.п. Язык прикладного программирования не должен отвлекать программиста от его бизнес-задачи на эти мелочи.
Ну вроде как уже давно есть top-level val coroutineContext через который можно в любой момент получить доступ к текущему контексту, плюс недавно мы доделали затаскивание любых threadLocal в контекст через ThreadLocal.asContextElement()
Ну вот это вряд ли, ибо сериализация это в принципе сложная доменно-специфичная штука, которой тяжело быть "стандартной". Вот в Java пытались, так теперь жалеют. Но в 1.3 будет намного лучше чем сейчас. С помощью того же Cryo в версии 1.3 будет очень легко записывать и восстанавливать состояние корутины (конечно, если её состояние поддается сериализации через Cryo).
Уже есть прототип. В 1.3 всё будет. Конечно, дизайн JDK exceptions (Throwable) для этого не очень подходит, но нам вроде удалось получить адекватный вариант.
Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
Это скорее нужно понимать, как язык, пригодный для системного программирования. Им он не ограничивается.
Это надо понимать ровно так, как это написано. Авторы языка Rust считают его языком системного программирования. Это как бы намекает, что существующий функционал языка и планы по его развитию заточены под задачи стоящие перед системными программистами. Я написал "очевидно", потому что мое понимание о том, что такое язык системного программирования и что он должен уметь, похоже, сильно совпадает с пониманием этого вопроса авторами языка Rust. Когда я первый раз почитал tutorial по языку Rust (но не видел этой фразы) и увидел набор его фич, то я сразу подумал "какой крутой язык для системного программирования — у него есть все шансы победить С/C++".
Да. Пишите на Kotlin: JavaClass.getRawList() as List<String>. Будет компилироваться с любой из версий метода getRawList(). Под разной версии будут разные warnings (можно сделать suppress и того и другого, чтобы обе версии компилировались без warnings).
Тут я могу процитировать rust-lang.org "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.", но вообще-то из без этой цитаты Rust очевидно является системным языком по своему дизайну и набору функционала.
Потому что inline это не оптимизация, а механизм мета-программирования, который призван заменить многие use-cases где в других языках прибегают к макросам. Может в уме заменять слово "inline fun" на "macro def" и тогда может будет понятней зачем оно нужно.
Это уже обсудили в соседней ветке. В прикладных языках программистам редко приходится работать с ресурсами и, в этих редких случаях, приходится страдать. Но как бонус не надо думать о памяти в 99.99% обычного прикладного кода где нет никаких ресурсов. Это, кстати, очень надежный признак который позволяет отличить современный прикладной язык от языка системного программирования.
В порядке убывания популярности по TIOBE: Java, Python, VB.NET, C#, PHP, JS, Ruby, Go, Perl, Dart, F#, Scala и т.д.
Речь шла про то, что рефлексии нет на Kotlin/JS, только не понятно зачем она там нужно. Source generator будет же работать на Kotlin/JVM (где рефлексия есть) и полученный код может работать на Kotlin/JS без всякой рефлексии.
Данный код печатает на экран значение каждого поля, как я понял. То же самое очень легко делается через
kotlinx.serialization(поля, которые не нужно обходить, можно пометить Transient). А в чем конечная цель?Извините, но я ничего не понял. Во-первых форматирование кода настолько далеко от Kotlin Code Style (см. https://kotlinlang.org/docs/reference/coding-conventions.html ) что мне очень тяже через него продраться… и вообще что он призван проиллюстрировать? Зачем вот это всё? В чем смысла этого кода? Какую задачу вы пытаетесь решить?
Вот здесь не понял. Можете пояснить на примере? Буду очень признателен если дадите ссылку на issue.
А что мешает делать это сейчас? Берете какой-нибудь Kotlin Poet и генерируете нужные вам исходники. Генератор запускаете на JVM, на нем с помощью рефлексии можете пройтись по вашей модели данных и всё узнать. Результирующий код будет работать где угодно — на JVM, JS, и Native.
Про сериализацию знаем. Делаем так, чтобы можно было сериализовывать из/в любых форматов (в т.ч. в БД) без рефлексии, то есть очень быстро и абсолютно type-safe на любой платформе (JVM/JS/Native). Следите за проектом https://github.com/Kotlin/kotlinx.serialization
А какого рода кодогенерация интересует?
В C++ тоже не надо писать delete или close. Rust развивает эту идею, вынося все опасные операции в unsafe. Это круто. Но дело же не в том, что надо писать. Важно то, о чем программисту надо думать. И в Rust и в C++ программисту надо думать о том чем объекты владеют и какой вообще у того или иного объекта lifetime. В этом и основное отличие современных прикладных языков с полностью автоматическим управлением памяти, что программисту об этом думать не надо вообще. Ни декларативно, ни императивно.
Такая попытка была в языке D. В Rust же, напротив, сделали всё верно и не пошли по этому пути. В Rust нет никакого "полностью автоматического управления памятью". Программисту на Rust, как и полагается системному программисту, надо самому думать об управлении памятью и правильно применять всякие аннотации времени жизни объектов и т.п. Отличие языка Rust от C и C++ в том, что Rust из-за этого получается более надежным, так как ошибки работы с памятью (если не использовать unsafe) приведут к ошибке компиляции, а не к падению во время исполнения.
Да. Всё так. Некоторые языки пытались совместить полностью автоматический GC и ручное управление ресурсами, но успешных примеров (среди популярных языков) в настоящее время нет. Если кто-то что-нибудь на эту тему придумает, то мы с радостью реализуем.
В ближайшем будущем не стоит ожидать в языке Котлин чего-то масштаба RAII в C++ или Lifetimes в Rust. Котлин в настоящее время ориентируется на прикладных программистов, которым редко приходится работать с внешними ресурсами, требующими явного освобождения/закрытия. Для целевой аудитории языка Котлин конструкций языка типа use и её подобных в целом хватает. В сложных случаях неудобно, но приоритеты — есть более актуальные задачи дизайна языка.
Однако, в Kotlin/Native, который ставит целью удобно интегрироваться с нативной (С) экосистемой, где ручное управление памятью и ресурсами широко распространено, есть дополнительные механизмы в виде арен и memScoped выделение памяти.
Воспользуюсь случаем спросить для сбора данных. А какой у вас use-case для рефлексии? Для чего вы её используете (если для разного, то расскажи в порядке важности, пожалуйста)?
Конечено можно. C++ один из ведущих языков по количеству пользователей и Rust дает для этих программистов надежду на светлое будущее и освобождение от оков legacy. Будь я программистом на C++ я бы тоже любил Rust. Да и вообще для задач где важно четкий контроль за ресурсами и производительностью Rust рулит. Но вот если решаешь чисто бизнес-задачу, то голова занята другим. Не хочется думать о том, надо передавать объект по значению, по ссылке или в коробке, какой у него лайфтайм и т.п. Язык прикладного программирования не должен отвлекать программиста от его бизнес-задачи на эти мелочи.
Ну вроде как уже давно есть top-level val coroutineContext через который можно в любой момент получить доступ к текущему контексту, плюс недавно мы доделали затаскивание любых threadLocal в контекст через ThreadLocal.asContextElement()
Ну вот это вряд ли, ибо сериализация это в принципе сложная доменно-специфичная штука, которой тяжело быть "стандартной". Вот в Java пытались, так теперь жалеют. Но в 1.3 будет намного лучше чем сейчас. С помощью того же Cryo в версии 1.3 будет очень легко записывать и восстанавливать состояние корутины (конечно, если её состояние поддается сериализации через Cryo).
Уже есть прототип. В 1.3 всё будет. Конечно, дизайн JDK exceptions (Throwable) для этого не очень подходит, но нам вроде удалось получить адекватный вариант.
Это надо понимать ровно так, как это написано. Авторы языка Rust считают его языком системного программирования. Это как бы намекает, что существующий функционал языка и планы по его развитию заточены под задачи стоящие перед системными программистами. Я написал "очевидно", потому что мое понимание о том, что такое язык системного программирования и что он должен уметь, похоже, сильно совпадает с пониманием этого вопроса авторами языка Rust. Когда я первый раз почитал tutorial по языку Rust (но не видел этой фразы) и увидел набор его фич, то я сразу подумал "какой крутой язык для системного программирования — у него есть все шансы победить С/C++".
Да. Пишите на Kotlin:
JavaClass.getRawList() as List<String>. Будет компилироваться с любой из версий методаgetRawList(). Под разной версии будут разные warnings (можно сделать suppress и того и другого, чтобы обе версии компилировались без warnings).Тут я могу процитировать rust-lang.org "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.", но вообще-то из без этой цитаты Rust очевидно является системным языком по своему дизайну и набору функционала.
Да.
Потому что inline это не оптимизация, а механизм мета-программирования, который призван заменить многие use-cases где в других языках прибегают к макросам. Может в уме заменять слово "inline fun" на "macro def" и тогда может будет понятней зачем оно нужно.