После года разработки компания Apple представила (https://swift.org/blog/swift-4-0-released/) релиз языка программирования Swift 4.0 (https://swift.org), второй значительный выпуск после открытия (https://www.opennet.ru/opennews/art.shtml?num=43451) исходных текстов проекта. Официальные сборки подготовлены (https://swift.org/download/#releases) для Linux (Ubuntu 16.04, 16.10) и macOS (Xcode). Исходные тексты распространяются (https://github.com/apple/swift) под лицензией Apache 2.0.
В отличие от прошлых выпусков в Swift 4.0 сохранена полная обратная совместимость с исходными текстами ветки Swift 3. Изменения в Swift 4.0 сосредоточены (https://developer.apple.com/videos/play/wwdc2017/402/) на расширении возможностей стандартной библиотеки и реализации таких возможностей, как архивирование/сериализация структур и перечисляемых типов (например, теперь поддерживается сериализация в JSON и plist). В состав включена новая реализация типа String, которая отличается более высокой производительностью, обеспечением корректности Unicode и предоставлением инструментов для создания, использования и манипуляций подстроками (substring (https://github.com/apple/swift-evolution/blob/master/proposa...), многострочные литералы). Расширены возможности словарей и коллекций (тип Collection).
Представлена новая команда "swift run (https://github.com/apple/swift-evolution/blob/master/proposa...)" для сборки и запуска исполняемых файлов, определённых в текущем пакете. Реализована идея эксклюзивного доступа (https://github.com/apple/swift-evolution/blob/master/proposa...) к памяти, предотвращающая ситуации, когда может быть произведено изменение переменой, которая в данный момент используется или изменяется в другой части программы. Расширены возможности пакетного менеджера, в который добавлена функциональность, упрощающая одновременную разработку нескольких пакетов (несколько пакетов одновременно могут помечаться для релиза), представлен новый Package API, позволяющий управлять настройками сборки.
Напомним, что язык 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-0-released/
Новость: http://www.opennet.ru/opennews/art.shtml?num=47235
Конец Objective-C
Так Свифт с блестками и быстрее. Кому нужен несвежий Objective-C?
Нормальным разрабам без смузи на столе
Стол - для хипстеров, чтоб подставлять его под смузи. Наши предки жили в пещерах и обедали на голой земле.
PR-менеджер ЕР?
> Наши предки жили в пещерах и обедали на голой земле.А почему это сразу те, кто не догадался подстелить листья, лапник или травку - общие предки? Говорите за себя!
Сейчас в одном известном новом кампусе лапник и травка одни из самых мягких и самых "зелёных". А вот тот, кто оказался не в состоянии себе такие подстелить, сейчас глотает лапшу и сойлент под звуки разваливающейся грохочущей нечисти из под стола и занимается или думает что занимается догадайтесь каким ПО ;)
> Сейчас в одном известном новом кампусе лапник и травка одни из самых
> мягких и самых "зелёных". А вот тот, кто оказался не в
> состоянии себе такие подстелить, сейчас глотает лапшу и сойлент под звукиЯ правильно понимаю, что акцент тут на "травке" и прочих галлюциногенах? Или в вашей секте еще и гипнозом обрабатывают?
Походу он передает на частоте анального зонда. Там свой язык, понятный только сектантам.
> Походу он передает на частоте анального зонда. Там свой язык, понятный только сектантам.Я почему-то уверен, что конкретно тут маковод пел дифирамбы своему фетишу (классика про лапшу и "нищебрoдство", см. "кто оказался не в состоянии себе такие подстелить", как и "звуки из под стола"), хотя вроде как не сектант ;)
Знакомый писал полтора года на свифте, начиная с 2.сколько-то и заканчивая третьим (objc не знал совсем). Потом ему пришлось перейти на objc. Через пару месяцев сказал, что свифт - это как пластмассовый грузовичок на верёвочке, objc - как МаЗ.
Неа. Вот есть внешняя статическая библиотека (*.a), в objc можно написать "extern "C" libfunc(int argc, char** argv);" (если нет хедеров) и спокойно ее дергать, как в православной сишечке. В Swiftе - создаются три файла: 1) objc/objc++ с описанным выше вызовом, 2) h-файл для этой "прослойки", 3) *-bridging-header.h. Ну а потом, собственно, веселые вызовы, например для массива строк - создание мапы из UnsafeMutablePointer<Int8>. Весело.
В Swift точно также можно использовать C, нужен только h-файл, все символы будут импортированы автоматически (в Rust, например, нужно вручную генерировать обертку). Вы сравниваете интеграцию С + "другой язык" с интеграцией Obj-C + "другой язык". Умеет ли Rust собирать в одном проекте Rust + Obj-C? Может быть Go? C#? В них и С то не так просто работать.
С преобразованиями тоже проблем нет. 1 раз написать 10 строк:// корректность не проверял
extension Array where Element == String {
init(cStringArray: UnsafePointer<UnsafePointer<Int8>?>) {
var strings = [String]()
var next = cStringArray
while let pointer = next.pointee {
strings.append(String(cString: pointer))
next += 1
}
self = strings
}
}и можете дергать:
let strings = [String](cStringArray: getCStrings())
> в Swift 4.0 сохранена полная обратная совместимость с исходными текстами ветки Swift 3вот это залог успеха. Бесшовный переход на новый компилятор в существующем проекте рулит. В некотором смысле, это один из столпов успеха C++: несовместимости если и были, то тривиальные
подсчет ссылок - медленее gc
А конкретно в Boost приводит к false sharing и просадками производительности, если указатель шарится между потоками.
Подсчет ссылок детерминированней, чем ГЦ
Будущее за "недетерминированными" технологиями, например нейросети.
у вас смузи убежали
И лапку не пожали!
ага "недетерминированная" rt os для экзоскелета, например
Каким образом?
Странный вопрос. По определению.
Ваше заявление не является ложным до тех пор пока углубляешься в детали того как работает gc и схема с recount.
> теперь поддерживается сериализация в JSON ... новая реализация типа String, которая отличается более высокой производительностью, обеспечением корректности Unicode и предоставлением инструментов для создания, использования и манипуляций подстроками (substring, многострочные литералы).И всего этого не было в языке, который изобрели в 2014-м году и позиционируют как что-то свежее и удобное? Капец. По-моему JSON и UTF8 должны быть в самое ядро языка встроены в наше время.
Речь про американцев, которым переключать раскладки не нужно, поэтому очевидность проблемы для них неочевидна.А для россиян неочевидны проблемы LTR/RTL или нестандартной цветовой гаммы (перенастрой так чтобы был белый текст на чёрном фоне и посмотри как "поплывут" цвета в приложениях вплоть до нечитаемости меню чёрное-на-чёрном) или крупного шрифта по умолчанию в меню и диалогах (иероглифы размером 8 пкс нечитаемы).
> Речь про американцев, которым переключать раскладки не нужноУзко мыслите. Юникод - это не только арабская вязь, но и эмоджы, псевдографика, пиктограммы, стрелочки и т.п. Если в языке нет юникода, это не язык - это студенческая параша для лабораторки. Собсно, эппля никогда и не отличалась умением делать языки - там всё больше дизигнеры. :)
> Узко мыслите. Юникод - это не только арабская вязь, но и эмоджы, псевдографика, пиктограммы, стрелочки и т.п. Если в языке нет юникода, это не язык - это студенческая параша для лабораторки. Собсно, эппля никогда и не отличалась умением делать языки - там всё больше дизигнеры. :)Да что уж там. Супер языка XXI века - это язык поддерживающий исключительно эмоджи, псевдографику, пиктограмму и стрелочки. Все остальное - мусор и студенческая параша для лабораторки.
Уже есть http://ekd.me/2017/09/marsianskij-yazyk-kak-kitajcy-obxodyat.../Скоро и у вас
> Да что уж там. Супер языка XXI века - это язык поддерживающий
> исключительно эмоджи, псевдографику, пиктограмму и стрелочки. Все остальное - мусор и
> студенческая параша для лабораторки.
Вас сейчас неправильно поймут и сделают операторы в виде эмоджи. Будете картинками писать программы
Юникод это, конечно, хорошо, но json то зачем? Сдохнет этот ваш js и всё, никому эта лапша будет не нужна.
Ну так уж получилось, что распространение веба по миру сделало json универсальным форматом, для которого существуют отлаженные рабочие библиотеки почти во всех языках.Вот в нашей конторе долгое время использовались sexp-ы вместо json. В принципе та же ерунда, они один в другой перегоняются запросто. Но вот когда наши питонисты с явистами и вебниками полезли с sexp-ами работать, они нехило так огребли из-за отсутствия библиотек. Понаписали своих кривых реализаций, которыми как-то с матюками и справлялись со своими проблемами. В то же время, я смекаю, что если бы вместо sexp-ов для API и сериализации данных использовался бы json, проблем было бы на порядок меньше.
Не, пихание JSON куда ни попадя — зло. Его возможность ограничены возможностями JS, так что он даже IEEE 754 не поддерживает. И как прикажете флоаты из нормальных языков сеарилизовать?
JSON ограничен своей спецификацией, а не js. Какие проблемы у тебя с флоатами? Нормальные числа без проблем сериализуются в number, всякие NaN и бесконечности в string, если вообще имеет смысл их сериализовать.
> всякие NaN и бесконечности в stringДа? И в каком же стандарте это прописано? Покажи мне хотя бы пару реализаций, делающих это совместимым между собой образом.
> Нормальные числа без проблем сериализуютсяНормальные числа *с плавающей точкой* без проблем сериализуются
Комплексные и рациональные, поддерживаемые некоторыми языками, сериализуются уже не так просто.
> Юникод это, конечно, хорошо, но json то зачем? Сдохнет этот ваш js
> и всё, никому эта лапша будет не нужна.JS - сдохнет, но не JSON! У нас .NET проекты - ВСЁ в них висит на JSON'ах, хотя выбор был широкий. XML себя не оправдал - тухлятина из 70-ых. Yaml - отвратителен. JSON полюбился сразу.
XML - 98-й год.... Какие-то очень затянувшиеся 70-е....А вот json, очевидно, надо чем-то заменять. Никакого автоматического контроля целостности. JSON Schema так и не приняли как стандарт.
> А вот json, очевидно, надо чем-то заменять. Никакого автоматического контроля целостности. JSON Schema так и не приняли как стандарт.а что её мешает использовать? у нас в проекте реализована, правда с кое-какой свистелкой, чтоб схема компактнее местами была, но всё же
> Yaml - отвратителен.Ну не надо, YAML очень даже приятен, но с двумя оговорками: во-первых, версии 1.1, а во-вторых, там, где надо хотя бы изредка читать глазами и писать руками. По сравнению с JSON у него большой оверхед на сериализацию/десериализацию, так что в тех местах, где важна производительность, и не нужны NaN'ы и бесконечности, JSON лучше.
js -- это не perl, php, ruby или python, держащиеся по большому счету лишь на энтузиазме разработчиков их использующих.
это часть современного веба. вон даже флэш, который не является частью никаких стандартов, и тот толком похоронить до сих пор не могут, а js пока еще никто и не собирался то особо
Смайлики нового айфона в старый String не влазят, надо улучшать же.
> И всего этого не было в языке, который изобрели в 2014-м году
> и позиционируют как что-то свежее и удобное? Капец. По-моему JSON и
> UTF8 должны быть в самое ядро языка встроены в наше время.Unicode там с первых дней и получше чем где бы то ни было. Над чем ломали голову можете почитать тут https://github.com/apple/swift/blob/master/docs/StringManife.... Вкратце - борьба между производительностью, корректностью и удобством: cтроки теперь хранятся в памяти в UTF-16, объект строки вернули свойство коллекции символов (до этого ввели .characters, а по самому объекту нельзя было просто так итерироваться), ввели тип Substring для производительности и многое другое. Unicode это не просто "есть utf-8 или нет", это большая головная боль в т.ч. с индексами в разных представлениях, нормализацией и т.д.
JSON в языке - спорный вопрос, хотелось бы конечно, но не критично. Он всегда был в Foundation, сейчас же добавили возможность архивировать любой объект с помощью универсального протокола - вот это в языке. А в Foundation добавили реализацию для этого протокола как обертку над существовавшим JSON. Теперь просто вручную не надо его разбирать, достаточно добавить протокол и компилятор сам сгенерирует упаковку/распаковку:
struct User: Codable {
let name: String
let age: Int
}Все. Компилятор сгенерирует (условно) keyedContainer["name"] = name и т.д. осталось только сунуть объект в JSONEncoder.encode(user)
PS: вот чего не хватает, так это регулярок в самом языке, обещают в пятом, вроде..
А еще он предлагает создавать алиасы всего и вся и половина встроенных методов содержит десяток псевдонимов.
Это конечно все очень удобно, до того момента когда тебе нужно просмотреть код человека, написанный в другом стиле.Путь Go, с его 25 ключевыми словами куда более правильный.
Хотя последнее обновление ввело чертовы алиасы, которые Гугл просто продавил — сообществу они ненужны.
Какие 25 слов? Вы о чём?
https://golang.org/ref/spec#Keywordsв golang 25 зарезервированных слов, в swift, судя по всему, их ~95
> в golang 25 зарезервированных слов, в swift, судя по всему, их ~95Как прогер, я не против 95 слов, т.к. всё равно 70% из них вы не увидите в обычном коде. Одно ключевое слово куда удобнее заклинаний public virtual static friend void. :)
> public virtual static friend voidБоже какая чушь..
>> public virtual static friend void
> Боже какая чушь..public static const Borscht borscht = new Borscht()
> Как прогер, я не против 95 словХорошо, что ты не "прогер".
Lua - 22
Forth - 0
ну, и парсите себе json, yaml и делайте http-запросы из forth дальше. хотя нет, это в реальном мире не встречается.а покажете в swift зарезервированное ключевое слово для создания нового легковесного треда? в erlang оно spawn, в go оно go. а в swift? да, я в курсе про разные operationqueue, всё равно это не аналог.
> ну, и парсите себе json, yaml и делайте http-запросы из forth дальшеа в чем проблема-то, кстати? Первое - прекрасно ложится, второе неудобно, но вполне можно, третье - если кто-то не поленится написать low level socket api - в принципе, для простых вещей тоже можно (простых - потому что для сложных нужна асинхронность, а с этим у форта никак)
> хотя нет, это в реальном мире не встречается.
скорее всего потому, что те кто еще могут что-то написать на форте, полагают что json, что yaml неописуемо уродливыми форматами, придуманными ниасиляторами "зато есть готовая библиотечка".
кстати, выше про "0 зарезервированных слов в forth" -- не совсем правда. if/else/then/dup/cr/emit -- разве это всё не ключевые слова языка, оверрайдить которые не надо или невозможно?
Начем писать на Swift, если есть богоподобная Сишечка?
Зачем писать на сишечке, когда можно перфокартами? Зачем вычислительная техника, если и на бумаге можно делить в столбик?
Смотря что делать. Если обговорить правила и протоколы, довольно просто и на ассемблере писать и сейчас, с некоторым количеством стандартных либ (кроме разве что многопоточности, да и то).
вот есть jabber. стандартов хоть жопой жуй. ни одного сервера на ассемблере. зато есть на erlang и java.
Богоподобным молятся. Мирским пишут.
на божественной сишечке не осилили написать ни одну очередь общего применения. на java написали kafka, на erlang rabbitmq. даже на c++ есть zeromq (который на самом деле лишний в этом списке). а на c нет. зато на c написаны отличные ос linux, bsd, да и вообще тот самый юникс.не впадайте в юношеский максимализм. есть яп для ос и есть для приложений под айфон.
> на божественной сишечке не осилили написать ни одну очередь общего применения.Redis же.
ну, во-первых, redis -- это key-value storage, а не message broker. как message broker его иногда пытаются использовать, но это и неудобно, и тормозит.не теряющиеся при падении воркера задачи? не, не слышали. приоритеты? тоже не предусмотрели. локи на одновременное чтение одной задачи несколькими воркерами? делайте сами. из redis такой себе message broker, он предназначен под другие юзкейсы.
Да, давай, доказывай теперь, что очередь на сях вовсе не очередь. Слив засчитан.
вы б ещё memcached как пример брокера привели. теоретически драйвер под celery есть. на практике -- ну его нафиг из этой области.
А графовая база данных на этом языке есть?
То есть никаких новых языковых фишечек не представлено?
Самое лучшее в Swift 4 - наконец-то можно посчитать количество символов в строке, без влезания в characters.
А под какую платформу?
Подсчет ссылок прямо скажем, очень спорное решение.
Почем никто не сравнивает с Хрустом?Казалось бы прямой конкурент. Оба типа убийцы С.
Какой же это убийца С, если он, кроме как для написания софта для девайсов Apple, больше нигде не используется?
Правильно ли я понимаю, что swift позволяет писать кросплатформенные приложения mac<->linux ?
Не в том смысле, в котором ты подумал. Под Linux доступен только компилятор языка и какие-то core-библиотеки. Cocoa, на котором пишут почти все нормальные приложения под macOS, никто не открывал и на Linux не портировал. Так что swift не приносит здесь ничего нового по сравнению с другими языками.