Мне интересно, все ли еще важно разрабатывать нативные приложения или редких и дорогих мобильных разработчиков можно на 80% заменить доступными фронтендерами, как это сделали ВК и другие?
А доступные фронтендеры — это кто? JS разработчики стоят не дешевле (а то и дороже) Swift/Kotlin.
Итого, если вам нужно портировать C++ библиотеку с обилием шаблонов, то ожидайте сложностей!
Не очень понятно каких. Сейчас Cmake умеет в iOS toolchain, можно собрать статическую библиотеку и далее обернуть ее в Swift, как динамический framework. Можно даже написать скрипт, который сделает fat статическую библиотеку для работы как на устройстве, так и на симуляторе.
В статье, как я понял, речь о header only части библиотеки.
По ссылке все же ошибка, а не стандартное поведение. Такую же ошибку можно допустить и в самом Metal API и защититься от этого разработчику не получится.
Изменилось, конечно. Одно дело стоять у доски с маркером и решать задачу под пристальным взглядом одного или двух человек, а совсем другое сидеть в любимом кресле и писать код задачи в редакторе.
Некоторые компании (Amazon, Facebook) перешли на формат Virtual On Site и перестали возить на очное собеседование. На LeetCode пишут что некоторые уже прошли такие собеседования, вроде даже получили предложения о работе.
Это для какой версии macOS и Swift? У меня вот так (https://habrastorage.org/webt/tk/4e/ji/tk4ejimhubxqfrilanvyrje_rlm.png), правда я исправлял несколько проблем.
1) Буферизованное посимвольное чтение файла, потоковый парсинг и выделение объектов из массива.
Если в случае Rust это видимо так, то в случае Swift никакого буфера для чтения не используется. Мало того, на каждый вызов чтения вы создаете новый Data объект.
Если это заменить на InputStream, то становится 13 секунд (https://gist.github.com/ivan-ushakov/65ad074216e33f222b6a572069e4e8f5). Это по прежнему много, но тут проблема в том что текущий парсер JSON не сохраняет информацию о типе при разборе, и вынуждает использовать as? для логики, что выливается в _dynamicCastFromExistential, который занимает много времени, судя по отчету Time Profiler.
Еще не очень корректно сравнивать язык с постоянным ARC, и язык где ARC можно использовать только когда он нужен. В вашем коде Swift почти не предпринято усилий по минимизации создания объектов в куче.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Когда планируется более актуальная версия Open GL и поддержка Vulcan?
В моем случае это не так, но подозреваю что это зависит от суммы
Интересно, как теперь будут работать Solar Staff и Easy Staff, которые использовали данный банк для вывода денег в Россию
Это которая игры делает?
А доступные фронтендеры — это кто? JS разработчики стоят не дешевле (а то и дороже) Swift/Kotlin.
Не очень понятно каких. Сейчас Cmake умеет в iOS toolchain, можно собрать статическую библиотеку и далее обернуть ее в Swift, как динамический framework. Можно даже написать скрипт, который сделает fat статическую библиотеку для работы как на устройстве, так и на симуляторе.
В статье, как я понял, речь о header only части библиотеки.
В SceneKit у вас есть возможность использовать свои шейдеры на MSL, если речь о такой оптимизации.
Если в случае Rust это видимо так, то в случае Swift никакого буфера для чтения не используется. Мало того, на каждый вызов чтения вы создаете новый Data объект.
Если это заменить на InputStream, то становится 13 секунд (https://gist.github.com/ivan-ushakov/65ad074216e33f222b6a572069e4e8f5). Это по прежнему много, но тут проблема в том что текущий парсер JSON не сохраняет информацию о типе при разборе, и вынуждает использовать as? для логики, что выливается в _dynamicCastFromExistential, который занимает много времени, судя по отчету Time Profiler.
Еще не очень корректно сравнивать язык с постоянным ARC, и язык где ARC можно использовать только когда он нужен. В вашем коде Swift почти не предпринято усилий по минимизации создания объектов в куче.