Да мы все тут уже давно поняли, что это за кодер тут топит за Kotlin. Вы разрабатываете обычные приложения на Kotlin, ходите на собеседования на вакансию разработчика на Kotlin, и вообще весь мир состоит из приложений на Kotlin, полных активностей и сервисов. На Kotlin можно написать все, а что нельзя — того не существует. Использовать C++ в Google придумали от скуки и практической пользы от этого никакой. Приложения можно писать только на каком-то одном языке, от и до, и только последний оставшийся в живых имеет право носить гордое имя официально поддерживаемого языка.
.
Непонятно только два момента: чего вы в самом начале прикопались к использованию Rust в экосистеме, которая с вашим опытом может быть пересекается примерно никак, и с чего вы вдруг взяли что если лично вам C++ не вперся, то значит язык неофициальный, сколько бы там официальных материалов Google по нему не опубликовал.
Не ну понятное что «если долго мучится, что-нибудь сломается» =). Там и не только unsafe, знающий человек на самом деле много чего может сломать в Rust. Но суть в том, что это сделать очень сложно и обычно невозможно сделать случайно.
Ну то есть официальным языком у вас является только тот, под который вы подогнали свои личные условия. А то, что он везде упоминается наравне, официальная SDK для него есть и т. п. это пофигу.
.
The native-activity sample resides under the NDK samples root, in folder native-activity. It is a very simple example of a purely native application, with no Java source code. In the absence of any Java source, the Java compiler still creates an executable stub for the virtual machine to run. The stub serves as a wrapper for the actual, native program, which is located in the .so file
Если автоматически генерируемая формальная заглушка «for the actual, native program» это причина утверждать что на чистом С++ приложение написать нельзя — ну что тут сказать, действительно остается только рассмеяться. Давайте тогда и Java не будем считать официальным языком, а то ведь приложение на чистом Java тоже нельзя просто так взять и запустить, нужен написанный на С++ рантайм.
.
Игрушки уже сто лет никто на чистом C++ не пишет
Ага, игрушки типа Genshin почему-то пишут на C#, который якобы тоже вообще не настоящий язык для мобилок, требует 10 интерпретаторов деля на сколько-то там производительность и прочая дичь.
.
А все дело в том, что давно уже до лампочки на каком языке писать обычные приложения, лишь бы системный API был доступен. Java или Kotlin вообще не уникальные единороги, на которых свет клином сошелся. С++ и Rust выделяются только тем, что позволяют залезть чуточку ближе к железу и не имеют оверхеда в виде рантайма.
Плюс Rust — это вроде нативный язык, а это небезопасно
Особенность Rust, из-за которой он и оброс всем этим хайпом, заключается в довольно революционном подходе, когда небезопасности нативного языка делаются невозможными на стадии написания. Язык изначально так спроектирован, что на нем например невозможно написать программу с утечкой памяти.
.
Смысл Java в том, что вы изначально пишете в безопасной виртуально среде, а в нативный код это преобразуется уже на конечном устройстве, так что заражение кода вирусом где то по дороге просто исключено.
Ничего подобного, прямо вообще не близко. Во-первых, приложения пишутся одинаково, одинаково проверяются и распространяются и выполняются потом тоже в одной и той же среде. С++ менее безопасный только в том плане, что там больше шансов феерично накосячить. Грубо говоря, приложение на нативном языке легче развести на секретные данные и неожиданное поведение, чем приложение на Java.
.
Во-вторых, приложения из официального источника (магазина приложений) одинаково проверены на наличие вирусов и всякой вредоносной функциональности. А если вы ставите приложение из стороннего источника, то там уже без разницы что за язык использовался, в Java может быть даже проще встроить что-нибудь эдакое.
Котлин — это самое крутое, что было сделано за последние лет 5
Ну а Rust например самое крутое, что было сделано за последние 10 лет — в своей нише, разумеется, как и Kotlin.
.
Разработка для мобильных устройств смартфонами не ограничивается. Если экосистема охватывает устройства начиная с «200 МГц и 32 МБ» и предъявляет повышенные требования к энеогоэффективности, то Kotlin запросто может оказаться не самым подходящим вариантом.
.
нативные языки для Android: Java/Kotlin
Так и вы неправильно помните =) полный список официальных это Java, Kotlin и С++ (https://developer.android.com/guide/components/fundamentals). Разумеется, Rust там тоже рано или поздно будет — пару лет назад выходила статья от Android Team в Google на эту тему.
Он тут при том, что транспилятор выполняет перманентный перевод из одного кода в другой на одном уровне абстракции, например из одного высокоуровневого ЯП в другой или из одного микрокода в другой (в отличие от компилятора, который производит так же перманентный перевод, но из высокоуровневого в низкоуровневый или наоборот).
.
В то время как транслятор это самый общий термин — это и интерпретатор на лету, и транспилятор из чего угодно во что угодно, и компилятор это тоже транслятор. Хз вообще что он подразумевает без уточнений.
.
Поэтому «транспилятор» это как раз уточнение какой вид транслятора тут имеется в виду.
Вообще GDB умеет все то же самое, в том числе интерактивность. Просто интерфейс консольный, отсюда и ощущение неповоротливости. Та же история с LLDB. Ну и разумеется IDE просто используют их, никто в здравом уме не будет целый отладчик писать.
Точнее даже транспилятор. Транслятор обычно подразумевает постоянную конвертацию в реальном времени, тогда как на macOS, ЕМНИП, бинарный код целиком, но однократно конвертируется при первом запуске и потом уже выполняется «нативное» приложение.
Так никто торопиться и не будет, вот в чем петрушка =). Но вопрос был не останутся ли бедные пользователи без софта, не надо ли будет ждать пока разработчики все не перепишут с нуля. Ответ — не останутся. А что кому-то придется полгода подождать перед покупкой пока пару багов в Autocad пофиксят — ну так это статистическая погрешность.
.
Вот игры, это да. С играми может не все радужно быть поначалу.
На самом деле нет =(. В плане переписать/адаптировать разница между ОС намного больше, чем между x86 и ARM. Есть много кроссплатформенного софта, который уже написан с учетом того, что его будут собирать и под такую ОС, и под такую, но если программа была написана не учитывая этого — переписать обычно ой как нелегко. Жопка даже, я бы сказал.
Само собой, кому-то пришлось и раздать. Во-первых, чтобы самые популярные приложения проверили-обкатали и не было конфуза на пафосном старте. Во-вторых, чтобы подправили и/или максимально отладили «вау-приложения», которые используют специфичное аппаратное ускорение.
.
Windows одновременно и сложнее, и проще. Сложнее потому что зоопарк софта несравненно больше и полюбому будут всплывать разные проблемы, которых на macOS и не могло быть, неподдерживаемое легаси, всякий упоротый производственный софт и т. п. Вони при переходе будет много, тут и рассуждать нечего.
.
Проще потому, что в целом никто и не ожидает что вот так вот презентовали и почти сразу вообще все само заработало. Банально покупать эти новые компы будут потихоньку, а не так массово как все обновлялись на M1.
.
Тем не менее, практически весь набор софта простого обывателя за исключением может быть игр — ему до лампочки на каком там процессоре выполняться, ну разве что перекомпилировать придется, ОС намного важнее в этом плане.
еще на цифро мыльницах проходили такие «переменные» диафрагмы на «глазках» объективах
Так на мыльницах тех времен матрицы были вообще милипипические. Когда диафрагма регулируется в пределах типа f/10-f/20 полнокадрового эквивалента, то действительно толку от этого мало. А в случае с Xiaomi 14 Pro диапазон изменения получается f/5.0-f/14.25 полнокадрового, что уже хотя бы заметно.
Тем не менее, порядка 48 МП очень даже имеют смысл, потому что можно кропнуть 2x центр кадра с довольно вменяемым качеством. А это по сути плюс фокусное расстояние без установки дополнительного модуля.
На ЛОРЕ, как и везде, 80% идиоты. У меня Lenovo X1 Nano — да, это на x86, но от установки Ubuntu вместо Windows (ничего не имею против Windows, просто надо было по работе) продолжительность работы от батареи изменилась примерно никак. С чего бы вдруг на ARM быть по-другому? То, что Windows или Linux в примерно одинаковой конфигурации (похожие интерфейсные рюшечки, похожий софт) как-то себя по-разному ведут в плане производительности/энергоэффективности — тупой миф.
Про все переписывать — лукавство.
.
Навскидку, 80% программ будет достаточно просто пересобрать под новую платформу или даже вообще ничего делать не надо. Потому что они либо написаны на в том или ином виде абстрагированном от архитектуры языке типа Java, .NET, Python, JS и пр., либо уже кросс-платформенные и потому более вылизанные, либо просто написаны без явных косяков. Потому что разница между Windows на x86 Windows на ARM несравнимо меньше, чем между скажем Windows на x86 и Linux на том же x86.
.
15% придется подправить по причине некритичной, но халтуры в коде.
.
5% специфичного софта да, придется переписывать. Или просто эмулировать и забить на производительность, вопрос в деньгах.
.
Непонятно только два момента: чего вы в самом начале прикопались к использованию Rust в экосистеме, которая с вашим опытом может быть пересекается примерно никак, и с чего вы вдруг взяли что если лично вам C++ не вперся, то значит язык неофициальный, сколько бы там официальных материалов Google по нему не опубликовал.
.
Если автоматически генерируемая формальная заглушка «for the actual, native program» это причина утверждать что на чистом С++ приложение написать нельзя — ну что тут сказать, действительно остается только рассмеяться. Давайте тогда и Java не будем считать официальным языком, а то ведь приложение на чистом Java тоже нельзя просто так взять и запустить, нужен написанный на С++ рантайм.
.
Ага, игрушки типа Genshin почему-то пишут на C#, который якобы тоже вообще не настоящий язык для мобилок, требует 10 интерпретаторов деля на сколько-то там производительность и прочая дичь.
.
А все дело в том, что давно уже до лампочки на каком языке писать обычные приложения, лишь бы системный API был доступен. Java или Kotlin вообще не уникальные единороги, на которых свет клином сошелся. С++ и Rust выделяются только тем, что позволяют залезть чуточку ближе к железу и не имеют оверхеда в виде рантайма.
.
Ничего подобного, прямо вообще не близко. Во-первых, приложения пишутся одинаково, одинаково проверяются и распространяются и выполняются потом тоже в одной и той же среде. С++ менее безопасный только в том плане, что там больше шансов феерично накосячить. Грубо говоря, приложение на нативном языке легче развести на секретные данные и неожиданное поведение, чем приложение на Java.
.
Во-вторых, приложения из официального источника (магазина приложений) одинаково проверены на наличие вирусов и всякой вредоносной функциональности. А если вы ставите приложение из стороннего источника, то там уже без разницы что за язык использовался, в Java может быть даже проще встроить что-нибудь эдакое.
.
Разработка для мобильных устройств смартфонами не ограничивается. Если экосистема охватывает устройства начиная с «200 МГц и 32 МБ» и предъявляет повышенные требования к энеогоэффективности, то Kotlin запросто может оказаться не самым подходящим вариантом.
.
Так и вы неправильно помните =) полный список официальных это Java, Kotlin и С++ (https://developer.android.com/guide/components/fundamentals). Разумеется, Rust там тоже рано или поздно будет — пару лет назад выходила статья от Android Team в Google на эту тему.
Кроп-фактор сенсора размером 1/1.3" равен 3.56, то есть получается f/4*3.56 = f/14.24 в полнокадровом эквиваленте.
.
В то время как транслятор это самый общий термин — это и интерпретатор на лету, и транспилятор из чего угодно во что угодно, и компилятор это тоже транслятор. Хз вообще что он подразумевает без уточнений.
.
Поэтому «транспилятор» это как раз уточнение какой вид транслятора тут имеется в виду.
.
Вот игры, это да. С играми может не все радужно быть поначалу.
.
Windows одновременно и сложнее, и проще. Сложнее потому что зоопарк софта несравненно больше и полюбому будут всплывать разные проблемы, которых на macOS и не могло быть, неподдерживаемое легаси, всякий упоротый производственный софт и т. п. Вони при переходе будет много, тут и рассуждать нечего.
.
Проще потому, что в целом никто и не ожидает что вот так вот презентовали и почти сразу вообще все само заработало. Банально покупать эти новые компы будут потихоньку, а не так массово как все обновлялись на M1.
.
Тем не менее, практически весь набор софта простого обывателя за исключением может быть игр — ему до лампочки на каком там процессоре выполняться, ну разве что перекомпилировать придется, ОС намного важнее в этом плане.
.
Навскидку, 80% программ будет достаточно просто пересобрать под новую платформу или даже вообще ничего делать не надо. Потому что они либо написаны на в том или ином виде абстрагированном от архитектуры языке типа Java, .NET, Python, JS и пр., либо уже кросс-платформенные и потому более вылизанные, либо просто написаны без явных косяков. Потому что разница между Windows на x86 Windows на ARM несравнимо меньше, чем между скажем Windows на x86 и Linux на том же x86.
.
15% придется подправить по причине некритичной, но халтуры в коде.
.
5% специфичного софта да, придется переписывать. Или просто эмулировать и забить на производительность, вопрос в деньгах.