The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Компания Apple выпустила язык программирования Swift 4.1

30.03.2018 08:47

Компания Apple опубликовала релиз языка программирования Swift 4.1. Официальные сборки подготовлены для Linux (Ubuntu 14.04, 16.04, 16.10) и macOS (Xcode). Исходные тексты распространяются под лицензией Apache 2.0.

В новой версии компилятора представлен новый режим оптимизации "-Osize", позволяющий на 5-30% сократить размер результирующего кода, ценой небольшого снижения производительности. В набор для настройки процесса сборки добавлены функции для проверки возможности импорта определённых модулей (например "#if canImport(UIKit)...") и определения выбранной целевой платформы (например, "#if targetEnvironment(simulator)..."). В пакетном менеджере обеспечено корректное разрешение зависимостей при использовании различных URL-схем (например, ssh и http). Существенно увеличена производительность обработки графов пакетов, содержащих общие зависимости.

В языке продолжена реализация идей связанных с поддержкой обобщений (generic). Например, добавлена поддержка условных соответствий, при которых типы Optional, Array и Dictionary, в которых хранятся другие типы, могут использоваться в операциях, требующих соответствия протоколам Equatable и Hashable. Например, 'let a = ["1","2","x"].map(Int.init); a == [1,2,nil]'; Из новых возможностей языка также отмечается возможность определения ограничений для ассоциированных типов с рекурсивными ссылками на определяемый протокол, синтез соответствия типов протоколам Equatable и Hashable, реализация метода "Sequence.compactMap(_:)", приведение индексируемых типов стандартной библиотеки к соответствию протоколу Hashable, исключение ассоциированного типа IndexDistance из протокола Collection. В классы JSONEncoder и JSONDecoder добавлено свойство для определения стратегии преобразования ключей в процессе кодирования или декодирования.

Напомним, что язык 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, предоставляющий средства для распространения модулей и пакетов с библиотеками и приложениями на языке Swift, управления зависимостями, автоматизированной загрузки, сборки и связывания компонентов.

  1. Главная ссылка к новости (https://swift.org/blog/swift-4...)
  2. OpenNews: Компания Apple выпустила язык программирования Swift 4.0
  3. OpenNews: Создатель LLVM и Swift уходит из компании Apple
  4. OpenNews: Компания Apple представила язык программирования Swift 3.0
  5. OpenNews: В язык Swift добавлена начальная поддержка платформы Android
  6. OpenNews: Компания Apple представила Swift 2.2, первый выпуск с поддержкой Linux
Лицензия: CC-BY
Тип: Программы
Ключевые слова: swift, lang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (90) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:20, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Кто - нибудь объяснит: для чего официальные сборки подготавливают для Linux?
     
     
  • 2.2, A.Stahl (ok), 09:23, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Реклама. "Какие мы открытые и вы, сраные прыщавые очкарики, тоже можете приобщиться к прекрасному и подумать иначе". А технически, вероятно, поддержка двух платформ почти ничего не стоит. Поэтому под Винду и нет версии.
     
     
  • 3.5, Солнышко (??), 09:39, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Основа потому что nix.

    А кто-нибудь скажет компетентный, есть хоть какие-то преимущества использования этого поделия на Linux? Как язык? Как Python?

    Я вот на Clojure пишу для бытовых задач и небольших личных проектов и все тип-топ. Зачем еще и Swift?

     
     
  • 4.13, rscx64_ (?), 09:55, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    может вдруг его не для целей "заменить твой clojure" делали? может для своих яблочных задач?
     
     
  • 5.34, Солнышко (??), 11:19, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы лично какие-такие яблочные задачи на Linux собираетесь решать?
     
     
  • 6.64, Аноним (-), 14:35, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Не знаю как он, но разработчики homebrew поголовно сидят на линуксе. Мак не готов для разработчика.
     
     
  • 7.71, Anin (?), 15:32, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вас не смущает что homebrew на линуксе это порт от маковской версии?
     
     
  • 8.75, Аноним (-), 15:57, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    homebrew как раз оригинал на маке Для линукса linuxbrew Под консольку на лине ... текст свёрнут, показать
     
     
  • 9.87, Аноним (-), 03:29, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну вон там уже зашкаливает версия в NET и я слышал окна можно вращать в WPF ... текст свёрнут, показать
     
  • 9.89, Аноним (-), 04:03, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, а чем консолька в линуксе отличается от консольки в маке ... текст свёрнут, показать
     
     
  • 10.92, Аноним (-), 11:18, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ничем, но утилит для работы с консолькой больше в линуксе и проще развернуть сре... текст свёрнут, показать
     
  • 7.90, Аноним (-), 05:53, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Мак не готов для разработчика

    Ну да, ну да. Все коллеги сидят на таком не готовом маке, успешно кодят веб, и вообще тащатся.

     
  • 4.15, Alexey (??), 09:59, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вам он скорей всего никогда не понадобится. Его ниша - приложения для iOS, macOS и всего остального от эппл. Можно писать консольные и серверные приложения для Linux, но здесь наверно не взлетит т.к. много конкурентов. Как язык для бекенда его IBM пытается двигать: https://developer.ibm.com/swift/
     
     
  • 5.61, bOOster (ok), 14:28, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Похожая разновидность ООЯП используется для программирования контроллеров XMOS. Даже можно сказать брат близнец, но с интересными доработками полного параллелизма многоядерной аппаратной реализации этих контроллеров.
     
  • 4.24, _hide_ (ok), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вам бы в википедию заглянуть :-)
    А то Ваш вопрос обескураживает.
     
  • 4.40, Аноним (-), 11:55, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если у Вас последний гном, то есть преимущество. На этом языке можно писать смайлами!
     
     
  • 5.43, Солнышко (??), 12:07, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы это про стрижа?
     
  • 2.3, anonymous (??), 09:34, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что могут?
     
  • 2.44, Аноним (-), 12:09, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего не стоит портировать программу с макоси на линух, потому что оба никсы.
     
     
  • 3.49, Аноним (-), 12:20, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы заблуждаетесь. POSIX - да, nix - нет.
     
     
  • 4.53, Аноним (-), 13:10, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В чём собственно разница? Это очередной дистрибутив с нескучными обоями, только закрытый.
     
     
  • 5.72, kk (??), 15:37, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как вы считаете *BSD сильно от линукса отличается или нет? А солярка? А HP-UX?
     
     
  • 6.77, Аноним (-), 17:09, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Почему нет порта Adobe под FreeBSD если всё так просто?
     
     
  • 7.84, kk (??), 20:05, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    потомучто нет коммерческого смысла?
     
     
  • 8.85, Аноним (-), 20:48, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Линуксоиды пересядут на бздю по такому поводу и от systemd избавятся ... текст свёрнут, показать
     
  • 2.51, papa Ken (?), 13:05, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Swift часть Google Fuchsia...
     

  • 1.4, Аноним (-), 09:37, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    чтобы на swift  backend ы пилить
     
     
  • 2.6, Солнышко (??), 09:40, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > чтобы на swift  backend ы пилить

    В чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?

     
     
  • 3.11, Аноним (-), 09:54, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он нативный, быстрее и вообще был написан для iOS, где на вот этих ваших Python/Java/Ruby без костылей не попишешь
     
     
  • 4.22, Аноним (-), 10:21, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –16 +/
    Это когда через LLVM, то нативный? Это сейчас такое у хипстеров нативным называется?
    А вот Python - да, нативный.
     
     
  • 5.37, Ordu (ok), 11:37, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот сами и жрите своё нативное интерпретируемое гно с утиной типизацией и GIL. Хотя, java тут несколько выбивается -- там всё же многое можно решить статической типизацией, а если и динамической, то хотя бы доступ к полю не через хештабличку по имени. Но интерпретируемость тем не менее остаётся.
     
     
  • 6.65, Анонимусис (?), 14:55, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тсс, obj-c runtime тоже с утиной типизацией ;)
     
  • 5.59, Аноним (-), 14:18, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это когда через LLVM, то нативный?

    Да

    >А вот Python - да, нативный.

    Нет, интерпертируемый

     
  • 5.62, bOOster (ok), 14:30, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А вот Python - да, нативный.

    Охренненно в лужу пернул...

     
  • 4.31, trdm (ok), 11:03, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Он нативный

    нативные языки для компьютера - только машинные коды.
    Остальные языки требуют обработки для упаковки в машинные коды.
    Т.о. чистых нативных популярных языков просто нет в природе.
    Как и нативных контролов - они все популисткие допущения.

     
     
  • 5.32, Аноним (-), 11:08, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну значит моё допущение, я имел ввиду компилируемый, как собственно написали чуть ниже
     
  • 3.14, rscx64_ (?), 09:56, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    swift это компилируемый язык а не интерпретируемый, почему ты вообще его сравниваешь с ruby/python/остальными? просто игнорируй факт того что он существует
     
  • 3.63, bOOster (ok), 14:33, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> чтобы на swift  backend ы пилить
    > В чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?

    Вообще отличное сравнение. Язык уровня С++ который практически напрямую ложиться в машинные коды, сравнивать с интерпретаторами и виртуальными машинами. Все в кучу...
    -"Вы уж либо трусы наденьте, либо крестик сымите"

     

  • 1.7, ДяДя (?), 09:43, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.

    Это оксюморон!!!
    Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является сборкой мусора.

     
     
  • 2.8, Аноним (-), 09:50, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хер там, циклические зависимости подсчет ссылок не разрулит.
     
     
  • 3.16, angra (ok), 09:59, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Погугли weak reference
    У каждого сборщика мусора есть свои проблемы. Но наличие проблем не превращает их в другие сущности. Другое дело, что большинство технически безграмотно и считает трассирующие сборщики мусора их единственным вариантом.
     
     
  • 4.86, Аноним (-), 23:29, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Погугли weak reference

    Я прекрасно знаю что такое weak reference. И то что их ставить надо руками. В отличие от сборщика мусора где просто все работает само и ничего делать не надо.

     
  • 2.12, Alexey (??), 09:55, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    в Swift подсчет ссылок выполняется на этапе компиляции а не выполнения как в Java. На мобилках отсутствие GC визуально заметно.
     
     
  • 3.17, angra (ok), 10:04, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора. Ну и задача тебе на каникулы, напиши программу, которая примет от пользователя число, а потом создаст массив с количеством объектов, равным введенному числу, а потом по очереди их из массива уберет. Помедитируй над подсчетом ссылок во время компиляции в этом случае.


     
     
  • 4.28, Alexey (??), 10:31, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем проблема? Код arc не читал, но документация утверждает что после прекращения использования объекта он зарелизится (уменьшится количество ссылок на 1), если количество сылок будет равно 0 то объект удалится. Это раньше надо было делать руками в Objective-C, с появлением arc просто пропала необходимость писать [object release].

    > В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора.

    возможно я ошибся, на java не пишу

     
     
  • 5.41, Очередной аноним (?), 11:59, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Что-то от Ваших слов в моих слабых ограниченных мозгах просто какой-то аццкий лю... текст свёрнут, показать
     
  • 5.46, Crazy Alex (ok), 12:13, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы путаете автоматический подсчёт ссылок (который делается в рантайме, разумеется, но не требует явных указаний со стороны программиста) с "подсчётом на этапе компиляции" что, разумеется, невозможно кроме совсем уж частных случаев или введения очень жёстких правил доступа и контроля времени жизни, как в Rust.
     
     
  • 6.57, Alexey (??), 13:51, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    абсолютно верно, я был неаккуратен в формулировках
     
  • 3.25, ДяДя (?), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в Swift подсчет ссылок выполняется на этапе компиляции

    Это невозможно.

     
  • 3.26, ДяДя (?), 10:29, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >в Swift подсчет ссылок выполняется на этапе компиляци

    Это невозможно в нашей Вселенной.

     
     
  • 4.30, Alexey (??), 10:38, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    имел ввиду добавление retain/release методов в код делает компилятор

    https://developer.apple.com/library/content/releasenotes/ObjectiveC/RN-Transit

     
  • 2.27, _hide_ (ok), 10:31, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не является. Потому что подсчет ссылок приводит к перманентному удалению объекта, а не к отложенной очистке.
    Так что подсчет ссылок и сборка мусора является способами управления жизненным циклом объектов, просто частенько их используют вместе.
     
     
  • 3.42, ДяДя (?), 12:03, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    См. первоисточники.
    Чисто формально в OpenJDK вообще не сборка мусора, а поиск живых объектов.
     
  • 3.66, Анонимусис (?), 14:58, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    autorelease pool --- это не отложенная очистка?
     
  • 2.50, Аноним84701 (ok), 13:02, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.
    > Это оксюморон!!! Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является
    > сборкой мусора.

    Это маркетология.
    Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".

     
     
  • 3.67, Анонимусис (?), 15:00, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".

    во-первых arc = automatic reference counting, перевод нужен?

    во-вторых в питоне все же другой алгоритм

     
     
  • 4.69, Andrey Mitrofanov (?), 15:08, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
    > во-первых arc = automatic reference counting, перевод нужен?

    Так вот вы про какой http://www.arclanguage.org/ "arc".

    Что ж вы сразу-то молчали? :7

    > во-вторых в питоне все же другой алгоритм

     
  • 4.70, Аноним84701 (ok), 15:17, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
    > во-первых arc = automatic reference counting, перевод нужен?

    Ох уж эти фанаты.
    С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?

    А фигурирует оно везде почему-то как "ARC", хотя вне ябла обычно ограничиваются "ref(erence) count(ing)", т.к. всем причастным ясно, что оно, в этом контексте, обычно таки всегда автоматическое. Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.

     
     
  • 5.78, Анонимусис (?), 18:10, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?

    а потому что вы так свои комменты формулируете

    >Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.

    молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксе тормозной? (я надеюсь, вы сможете нагуглить что оно делает без сторонней помощи)

     
     
  • 6.81, Аноним84701 (ok), 18:33, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?
    > а потому что вы так свои комменты формулируете

    В общем, из серии "сам додумал, сам оспорил" …

    >>Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
    > молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксе

    Дедуля, про контекст, см "оно, в этом контексте"  в предыдущем предложении было не ради красного словца написано. А то ведь ref. counting много где еще применяется - см. тот же гткшный gobject или ФС.

     
     
  • 7.82, Анонимусис (?), 19:08, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Дедуля, про контекст, см "оно, в этом контексте" (т.е. – ЯП) в предыдущем предложении было не ради красного словца написано.

    внучек, контекст заключается в том, что "подсчет ссылок" и "использование malloc/free" --- это ни разу не антонимы, это во-первых.

    во-вторых, можно ручками (как в л-нуксе) прописывать вызовы к манипуляторам рефкаунта, а можно сделать так, чтобы компилятор сам это делал. собственно ябл и сделал второе

     
     
  • 8.83, Аноним84701 (ok), 19:37, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дедуля бы меньше додумывал и читал между строк, особенно про какие-то антонимы, ... текст свёрнут, показать
     
     
  • 9.94, Анонимусис (?), 15:07, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    внучек, ты же в курсе, что в старых версия gcc там где еще был obj-c , нет ARC ... текст свёрнут, показать
     
     
  • 10.95, Аноним84701 (ok), 17:41, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О как Причина, оказывается, уже не пробно-успешное коммерческое закрытое испо... текст свёрнут, показать
     
  • 5.79, Crazy Alex (ok), 18:17, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Оно ARC потому что до 2013-го, кажется, года оно именно ручным и было (плюс костыль NSAutoreleasePool), а потом эппл таки сподобилась сделать автомат и обозвала это дело ARC.
     

  • 1.9, ктота (?), 09:50, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    исправьте: не сборки языка, а сборки компилятора.
     
     
  • 2.10, A.Stahl (ok), 09:53, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А ведь там наверное не только компилятор, но и стандартная либа, линковщик, дебаггер, профайлер...
    Так что это проще назвать "язык" и не заниматься излишним буквоедством.
     
  • 2.55, Аноним (-), 13:37, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Там не только компилятор, но и стандартная библиотека и спецификации на сам язык.
     
     
  • 3.56, Аноним (-), 13:40, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Там не только компилятор, но и стандартная библиотека и спецификации на сам
    > язык.

    Т.е. обновился именно язык, а в компиляторе лишь обеспечили поддержку изменений.

     

  • 1.18, Аноним (-), 10:08, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нет, ну, конечно, есть надежда, что будет реализована возможность разработки для IOS на Linux дистрах...
     
     
  • 2.23, anonas (?), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    писать то можно на чем угодно, вот скомпилировать и залить в стор получается только на маке :(
     
     
  • 3.91, Аноним (-), 05:59, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > писать то можно на чем угодно, вот скомпилировать и залить в стор
    > получается только на маке :(

    И правильно, нефиг плодить разработчиков-маргиналов.

     

  • 1.21, Аноним (-), 10:17, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    как они задолбали со своими новыми версиями. вместо того чтобы код писать, постоянно приходится разруливать результаты преобразования к очередному диалекту.
     
     
  • 2.29, A.Stahl (ok), 10:35, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое, что к этому моменту не успело безнадёжно устареть и иногда кем-то использовалось.
     
     
  • 3.36, Crazy Alex (ok), 11:26, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так это ж не эппловская песочница, где разработчиков можно куда угодно загнать. А сишный или плюсовый "стандарт", ломающий совместимость, тупо остался бы на бумаге.
     
  • 3.45, iPony (?), 12:12, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое,

    А мне вот что-то плакать хочется 😢
    Потому что, если ты чисто пишешь Hello World ы то, это дно. А на практике все равно со всеми стыками взаимодействия ломается всё и вся.

     
     
  • 4.48, A.Stahl (ok), 12:16, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >ломается

    Ну расскажи нам поучительную историю...

     
  • 3.68, Анонимусис (?), 15:03, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    std::auto_ptr removed in C++17. Не для всех платформ есть компиляторы с C++11


     
     
  • 4.80, Crazy Alex (ok), 18:18, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Для всего хоть как-то актуального есть минимум 14 плюсы. В которых, да, auto_ptr заменили на share_ptr + unique_ptr.
     
     
  • 5.93, Анонимусис (?), 14:58, 31/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Для всего хоть как-то актуального

    у вас актуальное только винда да лялекс

    для глубокого эмбеддеда не все так однозначно

     

  • 1.47, iZEN (ok), 12:15, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Нужно больше языков на разных версиях LLVM. У меня, например, на FreeBSD сейчас два LLVM-5.0.1: системный и прикладной для Mesa3D и Rust и ещё один LLVM-6.0.0 ждёт своего часа для обновлённого порта Rust (который будет использоваться в будущих версиях Firefox, выходящих через неделю). Ждём чего-то полезного на Swift, который к тому времени будет требовать LLVM-7.0.0.
     
     
  • 2.58, Moomintroll (ok), 14:16, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Swift, который к тому времени будет требовать LLVM-7.0.0

    Когда я последний раз смотрел на Swift, он требовал патченного LLVM и, соответственно, не мог использовать системный...

    С тех пор что-нибудь изменилось?

     
  • 2.60, Аноним84701 (ok), 14:18, 30/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > будет использоваться в будущих версиях 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.
    Для полноты набора, так сказать :)

     

  • 1.88, Аноним (-), 03:31, 31/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пока яблойды не портируют свою Какоу или Кокау или каккау под линус толку от всех этих языков просто не будет. А по понятным причинам какуау портировать не будут так как она наследине некста и вообще у линукойдов свой гтк на пару с аляпистым кутэ
     
  • 1.96, Аноним (-), 11:36, 01/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сколько весит hello world! на Swift?
     
     
  • 2.97, csdoc (ok), 16:26, 01/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Сколько весит 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-gnu

    P.S.

    Swift можно поставить на убунту и самому попробовать, https://swift.org/download/

     
     
  • 3.101, 1 (??), 09:15, 03/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А рантайм сколько?
     

  • 1.98, csdoc (ok), 16:51, 01/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    подробное объяснение, почему в Swift сделали ARC
    и не сделали полноценный GC, как например, в Java:

    https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.
    [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.

     
     
  • 2.99, Анонимный аноним (?), 20:43, 01/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > подробное объяснение, почему в Swift сделали ARC и не сделали полноценный GC, как например, в Java:
    > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.

    Оттуда же, для танкистов:
    > 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.

     

  • 1.102, Аноним (-), 20:10, 03/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Судя по списку зависимостей с Арча https://aur.archlinux.org/packages/swift/
    swift 4.1 живет на llvm 4.1
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру