Компания Apple опубликовала (https://swift.org/blog/swift-4-1-released/) релиз языка программирования Swift 4.1 (https://swift.org). Официальные сборки подготовлены (https://swift.org/download/#releases) для Linux (Ubuntu 14.04, 16.04, 16.10) и macOS (Xcode). Исходные тексты распространяются (https://github.com/apple/swift) под лицензией Apache 2.0.В новой версии компилятора представлен (https://swift.org/blog/osize/) новый режим оптимизации "-Osize", позволяющий на 5-30% сократить размера результирующего кода, ценой небольшого снижения производительности. В набор для настройки процесса сборки добавлены (https://github.com/apple/swift-evolution/blob/master/proposa...) функции для проверки возможности импорта определённых модулей (например "#if canImport(UIKit)...") и определения выбранной целевой платформы (например, "#if targetEnvironment(simulator)..."). В пакетном менеджере обеспечено корректное разрешение зависимостей при использовании различных URL-схем (например, ssh и http). Существенно увеличена производительность обработки графов пакетов, содержащих общие зависимости.
В языке продолжена реализация идей связанных с поддержкой
обобщений (https://github.com/apple/swift/blob/master/docs/GenericsMani...) (generic). Например, добавлена поддержка условных соответствий (https://swift.org/blog/conditional-conformance/), при которых типы Optional, Array и Dictionary, в которых хранятся другие типы, могут использоваться в операциях, требующих соответствия протоколам Equatable и Hashable. Например, 'let a = ["1","2","x"].map(Int.init); a == [1,2,nil]'; Из новых возможностей языка также отмечается возможность (https://github.com/apple/swift-evolution/blob/master/proposa...) определения ограничений для ассоциированных типов с рекурсивными ссылками на определяемый протокол, синтез (https://github.com/apple/swift-evolution/blob/master/proposa...) соответствия типов протоколам Equatable и Hashable, реализация (https://github.com/apple/swift-evolution/blob/master/proposa...) метода "Sequence.compactMap(_:)", приведение (https://github.com/apple/swift-evolution/blob/master/proposa...) индексируемых типов стандартной библиотеки к соответствию протоколу Hashable, исключение (https://github.com/apple/swift-evolution/blob/master/proposa...) ассоциированного типа IndexDistance из протокола Collection. В классы
JSONEncoder и JSONDecoder добавлено (https://forums.swift.org/t/jsonencoder-key-strategies/6958) свойство для определения стратегии преобразования ключей в процессе кодирования или декодирования.Напомним, что язык 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-4-1-released/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48358
Кто - нибудь объяснит: для чего официальные сборки подготавливают для Linux?
Реклама. "Какие мы открытые и вы, сраные прыщавые очкарики, тоже можете приобщиться к прекрасному и подумать иначе". А технически, вероятно, поддержка двух платформ почти ничего не стоит. Поэтому под Винду и нет версии.
Основа потому что nix.А кто-нибудь скажет компетентный, есть хоть какие-то преимущества использования этого поделия на Linux? Как язык? Как Python?
Я вот на Clojure пишу для бытовых задач и небольших личных проектов и все тип-топ. Зачем еще и Swift?
может вдруг его не для целей "заменить твой clojure" делали? может для своих яблочных задач?
Вы лично какие-такие яблочные задачи на Linux собираетесь решать?
Не знаю как он, но разработчики homebrew поголовно сидят на линуксе. Мак не готов для разработчика.
Вас не смущает что homebrew на линуксе это порт от маковской версии?
homebrew как раз оригинал на маке. Для линукса linuxbrew. Под консольку на лине разрабатывать проще для любой платформы, а на маках пишут только приложения с графическим интерфейсом для iOS и macOS. На других платформах это или невозможно или очень сложно.
Да ну вон там уже зашкаливает версия в .NET и я слышал окна можно вращать в WPF ;)
Хм, а чем консолька в линуксе отличается от консольки в маке?
Ничем, но утилит для работы с консолькой больше в линуксе и проще развернуть среду разработки на линуксе.
>Мак не готов для разработчикаНу да, ну да. Все коллеги сидят на таком не готовом маке, успешно кодят веб, и вообще тащатся.
Вам он скорей всего никогда не понадобится. Его ниша - приложения для iOS, macOS и всего остального от эппл. Можно писать консольные и серверные приложения для Linux, но здесь наверно не взлетит т.к. много конкурентов. Как язык для бекенда его IBM пытается двигать: https://developer.ibm.com/swift/
Похожая разновидность ООЯП используется для программирования контроллеров XMOS. Даже можно сказать брат близнец, но с интересными доработками полного параллелизма многоядерной аппаратной реализации этих контроллеров.
Вам бы в википедию заглянуть :-)
А то Ваш вопрос обескураживает.
Если у Вас последний гном, то есть преимущество. На этом языке можно писать смайлами!
Вы это про стрижа?
Потому что могут?
Ничего не стоит портировать программу с макоси на линух, потому что оба никсы.
Вы заблуждаетесь. POSIX - да, nix - нет.
В чём собственно разница? Это очередной дистрибутив с нескучными обоями, только закрытый.
Как вы считаете *BSD сильно от линукса отличается или нет? А солярка? А HP-UX?
Почему нет порта Adobe под FreeBSD если всё так просто?
потомучто нет коммерческого смысла?
Линуксоиды пересядут на бздю по такому поводу и от systemd избавятся.
Swift часть Google Fuchsia...
чтобы на swift backend ы пилить
> чтобы на swift backend ы пилитьВ чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?
Он нативный, быстрее и вообще был написан для iOS, где на вот этих ваших Python/Java/Ruby без костылей не попишешь
Это когда через LLVM, то нативный? Это сейчас такое у хипстеров нативным называется?
А вот Python - да, нативный.
Ну вот сами и жрите своё нативное интерпретируемое гно с утиной типизацией и GIL. Хотя, java тут несколько выбивается -- там всё же многое можно решить статической типизацией, а если и динамической, то хотя бы доступ к полю не через хештабличку по имени. Но интерпретируемость тем не менее остаётся.
Тсс, obj-c runtime тоже с утиной типизацией ;)
> Это когда через LLVM, то нативный?Да
>А вот Python - да, нативный.
Нет, интерпертируемый
> А вот Python - да, нативный.Охренненно в лужу пернул...
> Он нативныйнативные языки для компьютера - только машинные коды.
Остальные языки требуют обработки для упаковки в машинные коды.
Т.о. чистых нативных популярных языков просто нет в природе.
Как и нативных контролов - они все популисткие допущения.
Ну значит моё допущение, я имел ввиду компилируемый, как собственно написали чуть ниже
swift это компилируемый язык а не интерпретируемый, почему ты вообще его сравниваешь с ruby/python/остальными? просто игнорируй факт того что он существует
>> чтобы на swift backend ы пилить
> В чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?Вообще отличное сравнение. Язык уровня С++ который практически напрямую ложиться в машинные коды, сравнивать с интерпретаторами и виртуальными машинами. Все в кучу...
-"Вы уж либо трусы наденьте, либо крестик сымите"
> Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.Это оксюморон!!!
Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является сборкой мусора.
Хер там, циклические зависимости подсчет ссылок не разрулит.
Погугли weak reference
У каждого сборщика мусора есть свои проблемы. Но наличие проблем не превращает их в другие сущности. Другое дело, что большинство технически безграмотно и считает трассирующие сборщики мусора их единственным вариантом.
>Погугли weak referenceЯ прекрасно знаю что такое weak reference. И то что их ставить надо руками. В отличие от сборщика мусора где просто все работает само и ничего делать не надо.
в Swift подсчет ссылок выполняется на этапе компиляции а не выполнения как в Java. На мобилках отсутствие GC визуально заметно.
В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора. Ну и задача тебе на каникулы, напиши программу, которая примет от пользователя число, а потом создаст массив с количеством объектов, равным введенному числу, а потом по очереди их из массива уберет. Помедитируй над подсчетом ссылок во время компиляции в этом случае.
А в чем проблема? Код arc не читал, но документация утверждает что после прекращения использования объекта он зарелизится (уменьшится количество ссылок на 1), если количество сылок будет равно 0 то объект удалится. Это раньше надо было делать руками в Objective-C, с появлением arc просто пропала необходимость писать [object release].> В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора.
возможно я ошибся, на java не пишу
Что-то от Ваших слов в моих слабых ограниченных мозгах просто какой-то аццкий лютый диссонанс происходит.> в Swift подсчет ссылок выполняется на этапе компиляции
Вам указали, что в общем случае компилятор не может знать сколько объектов будет создано в процессе работы программы, которая ещё только компилируется в данный момент, ибо как минимум (компилятор) не знает, какие данные придут извне для обработки (какой будет пользовательский ввод, или что придет с файловой системы или по сети). Но Вы тут же:
> Код arc не читал, но документация утверждает что после прекращения использования
> объекта он зарелизится (уменьшится количество ссылок на 1), если количество сылок
> будет равно 0 то объект удалится.В Вашем Swift-мирке компилятор (то самое, что компилирует исходный код) в процессе своей работы ещё и выполняет компилируемую программу? И даже входные данные для обработки тут же откуда-то получает?
Вы путаете автоматический подсчёт ссылок (который делается в рантайме, разумеется, но не требует явных указаний со стороны программиста) с "подсчётом на этапе компиляции" что, разумеется, невозможно кроме совсем уж частных случаев или введения очень жёстких правил доступа и контроля времени жизни, как в Rust.
абсолютно верно, я был неаккуратен в формулировках
> в Swift подсчет ссылок выполняется на этапе компиляцииЭто невозможно.
>в Swift подсчет ссылок выполняется на этапе компиляциЭто невозможно в нашей Вселенной.
имел ввиду добавление retain/release методов в код делает компиляторhttps://developer.apple.com/library/content/releasenotes/Obj...
Не является. Потому что подсчет ссылок приводит к перманентному удалению объекта, а не к отложенной очистке.
Так что подсчет ссылок и сборка мусора является способами управления жизненным циклом объектов, просто частенько их используют вместе.
См. первоисточники.
Чисто формально в OpenJDK вообще не сборка мусора, а поиск живых объектов.
autorelease pool --- это не отложенная очистка?
>> Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.
> Это оксюморон!!! Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является
> сборкой мусора.Это маркетология.
Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".во-первых arc = automatic reference counting, перевод нужен?
во-вторых в питоне все же другой алгоритм
>> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
> во-первых arc = automatic reference counting, перевод нужен?Так вот вы про какой http://www.arclanguage.org/ "arc".
Что ж вы сразу-то молчали? :7
> во-вторых в питоне все же другой алгоритм
>> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
> во-первых arc = automatic reference counting, перевод нужен?Ох уж эти фанаты.
С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?А фигурирует оно везде почему-то как "ARC", хотя вне ябла обычно ограничиваются "ref(erence) count(ing)", т.к. всем причастным ясно, что оно, в этом контексте, обычно таки всегда автоматическое. Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
>С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?а потому что вы так свои комменты формулируете
>Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксе тормозной? (я надеюсь, вы сможете нагуглить что оно делает без сторонней помощи)
>>С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?
> а потому что вы так свои комменты формулируетеВ общем, из серии "сам додумал, сам оспорил" …
>>Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
> молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксеДедуля, про контекст, см "оно, в этом контексте" в предыдущем предложении было не ради красного словца написано. А то ведь ref. counting много где еще применяется - см. тот же гткшный gobject или ФС.
>Дедуля, про контекст, см "оно, в этом контексте" (т.е. – ЯП) в предыдущем предложении было не ради красного словца написано.внучек, контекст заключается в том, что "подсчет ссылок" и "использование malloc/free" --- это ни разу не антонимы, это во-первых.
во-вторых, можно ручками (как в л-нуксе) прописывать вызовы к манипуляторам рефкаунта, а можно сделать так, чтобы компилятор сам это делал. собственно ябл и сделал второе
>>Дедуля, про контекст, см "оно, в этом контексте" (т.е. – ЯП) в предыдущем предложении было не ради красного словца написано.
> внучек, контекст заключается в том, что "подсчет ссылок" и "использование malloc/free"
> --- это ни разу не антонимы, это во-первых.Дедуля бы меньше додумывал и читал между строк, особенно про какие-то антонимы, а то ведь уже второй раз что-то придумывает и тут же опровергает …
> во-вторых, можно ручками (как в л-нуксе) прописывать вызовы к манипуляторам рефкаунта,
> а можно сделать так, чтобы компилятор сам это делал. собственно ябл и сделал второеМожно, разрешаю! Все лучше, чем сравнивать ядерное, сишное API и концепт на уровне ЯП с автоматическим управлением памятью.
Разъясняю:
кроме (и задолго до) Ябла то же самое [ARC, "манипуляция" счетчика на уровне ЯП/компилятора] сделала еще куча разработчиков, в куче ЯП/ЯП-реализаций: начиная скриптухой вроде питона или перла, частично-опционально плюсы с их смартпоинтерами (тот же shared-pointer) и вплоть до такой "маргинальщины", как гнумовские vala или geany, реализованные буквально в одно-два лица, студентами (как минимум, в случае с vala).
Но громко орут, похваляются (и чуть что – оскорбляются), преподнося все как "великое достижение", каждый раз только надкушенные – _вот это_ и есть контекст "про ЯП" и вообще, этой ветки, дедуля ;)
>Но громко орут, похваляются (и чуть что – оскорбляются), преподнося все как "великое достижение", каждый раз только надкушенные – _вот это_ и есть контекст "про ЯП" и вообще, этой ветки, дедуля ;)внучек, ты же в курсе, что в старых версия gcc (там где еще был obj-c), нет ARC? потому что реализовать ARC в терминах gcc было нереальной задачей и именно поэтому ябл переехала на шланг.
а про достижение - во времена java/go/python/js/c#, использование ARC вместо тормозного gc можно и нужно считать достижением
> внучек, ты же в курсе, что в старых версия gcc (там где
> еще был obj-c), нет ARC? потому что реализовать ARC в терминах gcc было нереальной задачей и именно поэтому ябл переехала на шланг.О как? Причина, оказывается, уже не пробно-успешное коммерческое (закрытое) использование LLVM Яблом и одновременный переход GCC на GPLv3, а "неосиляние", тьху, "нереальность" решения задачи, с которой справились два студня (см. vala)
Ясно. Понятно . *ищет вилку, чтобы снять лапшу с ушей*
> а про достижение - во времена java/go/python/js/c#, использование ARC вместо тормозного gc можно и нужно считать достижением
> использование ARC вместо тормозного gcДостижением маркетолугов Ябла – безусловно. Именно об этом и речь - ARC оказывается уже совсем не тормозит (повторять перед зеркалом каждое утро) и вообще, не является одной из разновидностей GC.
В общем,
/0
Оно ARC потому что до 2013-го, кажется, года оно именно ручным и было (плюс костыль NSAutoreleasePool), а потом эппл таки сподобилась сделать автомат и обозвала это дело ARC.
исправьте: не сборки языка, а сборки компилятора.
А ведь там наверное не только компилятор, но и стандартная либа, линковщик, дебаггер, профайлер...
Так что это проще назвать "язык" и не заниматься излишним буквоедством.
Там не только компилятор, но и стандартная библиотека и спецификации на сам язык.
> Там не только компилятор, но и стандартная библиотека и спецификации на сам
> язык.Т.е. обновился именно язык, а в компиляторе лишь обеспечили поддержку изменений.
Нет, ну, конечно, есть надежда, что будет реализована возможность разработки для IOS на Linux дистрах...
писать то можно на чем угодно, вот скомпилировать и залить в стор получается только на маке :(
> писать то можно на чем угодно, вот скомпилировать и залить в стор
> получается только на маке :(И правильно, нефиг плодить разработчиков-маргиналов.
как они задолбали со своими новыми версиями. вместо того чтобы код писать, постоянно приходится разруливать результаты преобразования к очередному диалекту.
Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое, что к этому моменту не успело безнадёжно устареть и иногда кем-то использовалось.
Ну так это ж не эппловская песочница, где разработчиков можно куда угодно загнать. А сишный или плюсовый "стандарт", ломающий совместимость, тупо остался бы на бумаге.
> Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое,А мне вот что-то плакать хочется 😢
Потому что, если ты чисто пишешь Hello World ы то, это дно. А на практике все равно со всеми стыками взаимодействия ломается всё и вся.
>ломаетсяНу расскажи нам поучительную историю...
std::auto_ptr removed in C++17. Не для всех платформ есть компиляторы с C++11
Для всего хоть как-то актуального есть минимум 14 плюсы. В которых, да, auto_ptr заменили на share_ptr + unique_ptr.
>Для всего хоть как-то актуальногоу вас актуальное только винда да лялекс
для глубокого эмбеддеда не все так однозначно
Нужно больше языков на разных версиях LLVM. У меня, например, на FreeBSD сейчас два LLVM-5.0.1: системный и прикладной для Mesa3D и Rust и ещё один LLVM-6.0.0 ждёт своего часа для обновлённого порта Rust (который будет использоваться в будущих версиях Firefox, выходящих через неделю). Ждём чего-то полезного на Swift, который к тому времени будет требовать LLVM-7.0.0.
> Swift, который к тому времени будет требовать LLVM-7.0.0Когда я последний раз смотрел на Swift, он требовал патченного LLVM и, соответственно, не мог использовать системный...
С тех пор что-нибудь изменилось?
> будет использоваться в будущих версиях Firefox, выходящих через неделю). Ждём чего-то
> полезного на Swift, который к тому времени будет требовать LLVM-7.0.0.Могу "посоветовать" pure (" Modern-style functional programming language", в чем-то прикольный ЯП, основывающийся на term-rewriting) - зависит от llvm 3.5, openshadinglanguage (llvm 4.0), ponyc ("Pony language compiler") - llvm 5.0.
Для полноты набора, так сказать :)
Пока яблойды не портируют свою Какоу или Кокау или каккау под линус толку от всех этих языков просто не будет. А по понятным причинам какуау портировать не будут так как она наследине некста и вообще у линукойдов свой гтк на пару с аляпистым кутэ
Сколько весит hello world! на Swift?
> Сколько весит hello world! на Swift?Hello.swift:
print("Hello, World!")
бинарник с отладочной информацией получается 14808 байт,
если сделать strip - будет 11408 байт.$ swift -version
Swift version 4.1 (swift-4.1-RELEASE)
Target: x86_64-unknown-linux-gnuP.S.
Swift можно поставить на убунту и самому попробовать, https://swift.org/download/
А рантайм сколько?
подробное объяснение, почему в Swift сделали ARC
и не сделали полноценный GC, как например, в Java:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
[swift-evolution] What about garbage collection?[...]
> Has a GC been considered at all?
GC also has several *huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted *much* more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life).
I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.
> подробное объяснение, почему в Swift сделали ARC и не сделали полноценный GC, как например, в Java:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...Оттуда же, для танкистов:
> Technically speaking, reference counting is a form of garbage collection,
> Since there are multiple forms of GC, I'll assume that you mean a generational mark and sweep algorithm like you’d see in a Java implementation.
Судя по списку зависимостей с Арча https://aur.archlinux.org/packages/swift/
swift 4.1 живет на llvm 4.1