После года разработки компания Apple опубликовала (https://swift.org/blog/swift-5-released/) релиз языка программирования Swift 5 (https://swift.org). Официальные сборки подготовлены (https://swift.org/download/#releases) для Linux (Ubuntu 14.04, 16.04, 18.04) и macOS (Xcode). Исходные тексты распространяются (https://github.com/apple/swift) под лицензией Apache 2.0.
В новой версии стабилизирован (https://swift.org/blog/abi-stability-and-more/) ABI для платформ macOS, iOS, tvOS и watchOS. Обеспечена возможность поставки новых версий библиотек без перекомпиляции приложений. В стандартной библиотеке внутреннее представление строк переведено (https://swift.org/blog/utf8-string/) на кодировку UTF-8. Улучшена (https://swift.org/blog/behind-se-0200/) поддержка raw-текста (со спецсимволами и переводами строк) в строковых литералах. Добавлены новый тип для обработчиков ошибок Result (https://github.com/apple/swift-evolution/blob/master/proposa...) и векторный тип SIMD (https://github.com/apple/swift-evolution/blob/master/proposa...).
Расширены возможности по интерполяции строк с типом String (выделение текста из произвольных данных). Увеличена производительность типов Dictionary и Set.
В runtime добавлены (https://swift.org/blog/swift-5-exclusivity/) средства для организации эксклюзивного доступа к памяти (для проверки, что переменная не доступна через другие имена в момент изменения в функции), которые могут включаться как в отладочном режиме, так и для релизов.
Реализована (https://github.com/apple/swift-evolution/blob/master/proposa...) возможность создания динамически вызываемых типов (предложен атрибут "@dynamicCallable"), нацеленных на улучшение переносимости с языками с динамической типизацией, такими как Python, JavaScript и Ruby. Добавлена (https://github.com/apple/swift-evolution/blob/master/proposa...) поддержка условного оператора "меньше чем" в выражениях управления ходом компиляции (например, "#if swift(‹4.2)").
В пакетном менеджере представлена поддержка зеркалирования зависимостей (https://github.com/apple/swift-evolution/blob/master/proposa...), привязки (https://github.com/apple/swift-evolution/blob/master/proposa...) параметров сборки к целевой платформе, генерации coverage-данных и определения (https://github.com/apple/swift-evolution/blob/master/proposa...) собственных требований к поддерживаемым целевым платформам. В команду "swift run" добавлена возможность импорта библиотек в REPL без сборки в формате исполняемых файлов.
Напомним, что язык Swift наследует лучшие элементы языков C и Objective-C, и предоставляет объектную модель, совместимую с Objective-C (Swift-код может смешиваться с кодом на С и Objective-C), но отличается использованием средств автоматического распределения памяти и контроля переполнения переменных и массивов, что значительно увеличивает надёжность и безопасность кода. Swift также предлагает множество современных методов программирования, таких как замыкания, обобщенное программирование, лямбда-выражения, кортежи и словарные типы, быстрые операции над коллекциями, элементы функционального программирования. Версия для Linux не привязана к Objective-C Runtime, что позволяет использовать язык в окружениях, в которых отсутствует поддержка Objective-C.Pеализация Swift построена с задействованием технологий свободного проекта LLVM. Для обеспечения высокой производительности Swift-программы компилируются в машинный код, выполняемый в тестах Apple на 30% быстрее кода на Objective-C. Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты. В поставку входит пакетный менеджер Swift Package Manager (https://swift.org/package-manager/), предоставляющий средства для распространения модулей и пакетов с библиотеками и приложениями на языке Swift, управления зависимостями, автоматизированной загрузки, сборки и связывания компонентов.
URL: https://swift.org/blog/swift-5-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=50393
Версия 5, а UTF-8 только сейчас прикрутили. Зачем так жить?
Ждем код со смайликами в качестве названий объектов и переменных
В Ruby вон под новый год еще завезли )
Еще в 2014 году официальный мануал описывал использование смайликов как имена переменных )
А по ссылке сходить слабо? Изначально было UTF-16.
У вас с чтением всё хорошо? При чём тут эта днище-16 кодировка?
чего вы д..читесь UTF-8 и UTF-16 это один и тот же набор символов, просто UTF-16 больше заточен под азиатов в плане уменьшения размера при кодировании символов
ну и чего мунусятники возбудились ? ведь все легко проверить$ echo -n "词" > utf8.txt
$ file -bi utf8.txt
text/plain; charset=utf-8
$ xxd -bi utf8.txt
00000000: 11101000 10101111 10001101
$ iconv -f UTF-8 -t UTF-16BE -o utf16.txt utf8.txt
$ xxd -bi utf16.txt
00000000: 10001011 11001101
А ничего, что один имеет статический размер, а второй динамический?
А ничего, что размер символов в UTF-16 перестал быть фиксированным при добавлении понятия суррогатных пар в середине 1990-х?
> А ничего, что размер символов в UTF-16 перестал быть фиксированным при добавлении
> понятия суррогатных пар в середине 1990-х?И ACSII поэтому кодируется в 2 байта, а не в 1, как на UTF-8?
А всё просто. В Objective-C все NSString хранились в памяти как UTF-16. Swift в прошлых версиях для облегчения интеропа также унаследовал эту структуру (свифтовый String внутри имел NSString как backing storage). Сейчас они переделали внутреннюю реализацию, т.к. 99% разработчиков работают с UTF-8 строками и в этом случае производительность важнее.
> официальные сборки подготовлены для Linux (Ubuntu 14.04, 16.04, 18.04)
> версия для Linux не привязана к Objective-C Runtime, что позволяет использовать язык в окружениях, в которых отсутствует поддержка Objective-C.
> выполняемый в тестах Apple на 30% быстрее кода на Objective-C
> вместо сборщика мусора в Swift используются средства подсчёта ссылок на объектыSwift уничтожит C/C++ и станет основным языком разработки в Linux? Тревожные новости, однако.
Не станет. Си - это почти асм, простейшая реализация, "без колонок, без усилка и без защиты от дурака, которого ты тут валяешь, Ник". Ядро линукса будут писать только на Си, а что там понаприкручивают поверх него - это уже не забота Торвальдса
> Ядро линукса будут писать только на СиРечь идёт не о системном программировании ядра Linux, а о прикладном программировании, где как раз есть все шансы у Swift потеснить С/С++.
Пусть сначала хотя бы objective-c потеснит.
В линуксе?
Swift даже на маке никому не сдался, все как кодили на Оbjective-С так и дальше будут. Swift мертворожденное поделие.
XCode формочки уже научился собирать под Linux? XCode может быть есть под Linux? Нет? Не соберет. Swift-разрабы на рынке дорогие. Они нужны на Mac/iOS.А Linux swift чисто по фану.
> Они нужныне очень
Зависит от рынка труда
Я бы не отказался поменять nodejs на swift (тем более что я его знаю) в бекенд разработке. Из альтернатив заказчики рассматривают разве что Go, но язык (будем честными) весьма упрт и сильно отличается от С-подобной группы языков. На Java тоже нет особого желания писать, там свои приколы (разве что на Kotlin перейти - но опять же заказчики).
Как бы представляете архитектуру бекенда на swift?
У него, вроде, нет GC; prefork?
>о прикладном программировании, где как раз есть все шансы у Swift потеснить С/С++.Objective-C не потеснил, и это при том, что Objective-C входит в состав GCC, с чего бы их потеснить Swift-у?
Посмотрим сколько у Apple займёт времени переписать WebKit Safari с С++ на Swift. А вообще лично я ещё ни разу не видел, чтобы этим Swift кто-то из программистов пользовался.
Разработчики на Swift c 99% вероятностью разрабатывают на Mac/iOS. Сюрприз? Нет?1% - такие чудики как на этом сайте
Ну вот например Skype для макоси написан на Typescript/javascript, а для iOS многие пишут на Xamarin или Qt. Никто не заморачивается с native API уже давно.
>Ну вот например Skype для макоси написан на Typescript/javascript, а для iOS многие пишут на Xamarin или Qt. Никто не заморачивается с native API уже давно.Каждое утверждение в этой цитате - чушь.
Тут ошибка в слове многие ) Многие среди его окружения видимо из 2.5 студентов-разработчиков
Насчет Skype для MacOS не знаю. Но все возможно
Если ты не знаешь даже насчёт Skype для macOS, то ты не знаешь ничего, как и комментатор выше.
Ой помню как Делфисты радовались в свое время, что скайп на делфи написан и везде в пример ставили типа "великие аппы, писанные на Делфи". Ладно, подловили)) Хотя, конечно, все, что там более менее низкоуровневое, работа с камерой, звуком, звонки - там конечно не на тупомскрипте или js-е... Тоесть веб макак посадили только UI сверстать.
Но касательно "Никто не заморачивается с native API уже давно." - это по прежнему чушь. Не заморачиваются только те, кто ничего сложнее калькулятора или там rest-клиента к какому-нибудь онлайн магазину не пишут.
Приложение для видеозвонков на жс делается очень легко благодаря WebRTC, так что js понятный выбор в этом случае. Правда у меня на i7 тестовый пример с 640*480 так себе по перформансу работал.
Оно там уже научилось без проблем звонить хотя бы между Firefox/Chrome и другими браузерами? Про поддержку других протоколов, кодеков и любых возможностей не входящих в минимум описанный в спеках WebRTC, конечно, вообще молчу. Но да, для того чтобы сделать еще один глючный клон скайпа этого и не надо. Так уж сложилось, что для бизнеса в большинстве случаев качество не нужно - нужно как можно быстрее состряпать корявый клон. И тут веб подходит как нельзя лучше - натренировались уже на вордпрессах с джумлами клоны лендингов делать, че.
Telegram для макоси на Qt если что. И все эти приложения не то что не выглядят чужеродными, они выглядят лучше какого-нибудь iMovie например.
Версий Telegram для макоси две, если что ) На Qt и нативная на Swift. На хакинтоше юзаю Qt версию просто потому что она такая же как на винде и линуксе. А вот на макбуке лучше оказалась свифтовая версия - у кутяшной есть всплески по CPU, когда открывается картинка или видос в чате, что макбук на взлёт идёт и energy impact от него самый большой получается.
Всплески и energy impact там не от видео, а от блокировок роскомпозора.
Какую версию Хакинтоша юзаете?
На Мак/iOS кодят на Objective-C и только пара хипстеров-велосипедистов на Swift.
> А вообще лично я ещё ни разу не видел, чтобы этим Swift кто-то из программистов пользовался.Ты не видел программистов, пишущих под iOS. Окей.
Видел разумеется. Но пишут они на Xamarin и Objective-C.
ObjC и есть нативка для iOS.Последняя студия, которых мы собеседовали на проект, пишут именно натив -- и ObjC, и свифт. Замарин не любят и почти не используют.
Пользуюсь Swift с конца 2015 года. На ObjC один раз за 3 года написал маленький лоадер для программы и то только потому, что бинарник-запускалка на 50 строк получился аж в 6 метров на свифте против 40 кб на обжси. И как раз это и должен починить 5 свифт.
> чтобы этим Swift кто-то из программистов пользовался.кодовая база Телеграм реализована на Swift под OS X и iOS. На iOS он называется Telegram X и садит батарею меньше чем C++ с Обж Ц обвязкой.
В 2020 Apple выкатит единый фреймворк разработки приложений под iOS/OS X под названием Марципан
https://www.imore.com/marzipanОчевидно, что это будет Swift-only фреймворк и число разработчиков под мобилы/десктопы только увеличится, так как обналичивать монеты с двух платформ куда веселее, чем с одной.
Но ведь гуй, работающий и на десктопе, и на мобиле, обычно работает плохо и там и там? Чувствую, кактус получится.
Kotlin Native по сути улучшенная версия Swift. При этом позволяет совмещать код на Swift с кодом на Kotlin примерно так же как Kotlin JRE c Java.
Булки расслабь и тревожность отступит. С/С++ ещё сотни лет будут рулить.
Продуманный язык. Жаль, что уже не сможет вытеснить Go
> Продуманный язык.Уберите клоуна с арены! Свой индивидуальный синтаксис под каждую микрофичу - это "продуманный"? Понатыкали кусков из разных языков и зарелизили что получилось, не более.
Продуманный - это Lisp, C.
C - более-менее, а вот lisp - да, продуманней некуда. Но это только потому, что проще тоже, наверное, некуда.
> lisp - да, продуманней некуда. Но это только потому, что проще тоже, наверное, некуда.Проще?! Вы вообще лиспы видели?
Жаль только медленный ппц и в компиляции и в принципе. Даже на том же godbolt можно сравнить: для аналогичных функций в swift раза в 2,5 - 3 больше ассемблерного кода чем на С++. Я понимаю что объем asm кода это не всегда надежный показатель, но в большинстве случаев все же позволяет делать уверенные выводы.
Ну язык и не позиционировался как убийца плюсов. В первую очередь эппл хочет перетащить на него побольше разрабов с Obj-C и протащить как язык для бекенд разработки (даже сделали отдельный комитет под это https://swift.org/server/). Они хотят своими фичами сразу на два стула сесть. А системным языком его и не называли никогда. В той же макоси драйвера пишутся на ограниченном подмножестве C++ (без исключений и ещё чего-то), даже не на обжективе (ибо медленный).
Документация/книги на русском есть?
Литературы масса. В т.ч. на русском. Жалко, мне не пригодилась, ибо пишу на С++/Qt для Linux/macOS/Windows 100% кроссплатформенный код.
Мне пару раз пригодилось. Довольно лаконичный язык
А UI там можно писать для Linux платформы? Примеры связко с сишным кодом есть?
Под другие дистрибутивы надо собирать или кто-то добренький есть?
остановитесь, зачем еще один язык, тут один то выучить не успеваешь, а еще кучу нагородили нахрена всякие гоу, свифты, вам че с++, си шарпа, джава, php мало?
А это для тех, чтобы мучать тех, у кого нет чувства меры и критического мышления
"разделяй и властвуй"
Мало. Как ни крути, а на тот же иос без обжектива или свифта комфортно не пописать.
Прямо слоган для рекламы простамола...
> Официальные сборки подготовлены для Linux (Ubuntu 14.04, 16.04, 18.04) и macOS (Xcode)Удивило в хорошем смысле.
Каждому _языку_ --- по своему пакетному менеджеру, VCS, системе сборки!
Чем C++/Qt не нравится? Работает на каждой платформе с нативным компилятором: clang, gcc, msvc.
>Чем C++/Qt не нравится?
>C++Сложна и объективно не нужно в большинстве случаев.
Когда ваш продукт рабоатет на всех прошлых и будущих версиях ОС и ставится без плясок с бубном - это полезно.
жалко, что это не про Qt
Такие вбросы стоит сопровождать фактами. Я вот вижу что на моём ПК с Дебиан и на вин-планшете тот-же smplayer юзающий qt работает одинаково отлично, а вы врёте.
Каждому _производителю_железок_ --- по своей операционке, язык, пакетному менеджеру, VCS, системе сборки и т.д.
В комплекте идет Clang-7. Забавно.
И это хорошо. Clang в силу его как бы повышенной строгости способствует улучшению качества кода, даже если вы создаете основную версию программы не в нем.
Ты сам то понял что сказал?
Под WIdnows то есть версия?
А нафига оно под виндой(как и под линуксом)?