Язык Swift был представлен сообществу чуть больше года назад, что вызвало достаточно большой резонанс в среде разработчиков, при том не только iOS и OS X.
Но еще больший резонанс вызвал тот факт, что Apple пообещала открыть код компилятора и анонсировала возможность поддержки языка для операционных систем на базе linux.
Сегодня Apple представило исходный код Swift, а также библиотек Foundation, в своем репозитории на github.
Также, был запущен сайт swift.org (который, по понятным причинам, сейчас по большей части не доступен), на котором можно более подробно ознакомиться с языком.
В дополнение к этому, в репозитории Apple на github и на сайте swift.org можно ознакомиться с процессом разработки swift 3 и, возможно, поучаствовать в его совершенствовании.
Комментарии (55)
deniskreshikhin
03.12.2015 23:03+9Ох, как же чертовски приятно видеть в официальной документации Apple строчки вроде:
For Ubuntu, you'll need the following development dependencies:
sudo apt-get install git cmake ninja-build clang uuid-dev libicu-dev icu-devtools libbsd-dev libedit-dev libxml2-dev libsqlite3-dev swig libpython-dev libncurses5-dev pkg-config
Antelle
04.12.2015 10:15Ещё б под винды сделали официальную поддержку. А то странно как-то получается.
Gorthauer87
04.12.2015 00:38+3Кажется пришла пора наконец попробовать его в деле. Круто, что наконец новое поколение системных языков вылезает из пеленок.
DmitrySpb79
04.12.2015 10:15-10Попробуйте, будете удивлены. Этот *** язык не может сам даже int с float перемножить.
let quantity:Int = 5 let price:Float = 10.99 let priceTotal = price*quantity error: binary operator '*' cannot be applied to operands of type 'Float' and 'Int'
Вероятно в таком контроле типов есть особый дзен, но меня это бесит.Gorthauer87
04.12.2015 10:33+6В rust точно также. А особенно хорошо в нём, что нельзя так просто signed и unsigned сравнивать.
Это все соответствует принципу наименьшего удивления. Лучше уж явно кастануть целое или округлить флота, чем потом удивляться.DmitrySpb79
04.12.2015 10:42Я понимаю, но ведь раздражает же :) Особенно в примере как выше, здесь вполне было бы достаточно явно указать тип результата
let priceTotal:Float = price*quantity
чтобы дать компилятору понять, что я знаю что делаю (не пробовал, возможно можно переопределить operator '*' для Int и Float но это уже костыль).Gorthauer87
04.12.2015 11:09Ну такое может и неплохой компромис, но вообще это несколько снижает единообразие. Тут по видимому и разрабы раста и разрабы свифта одними и теми же научными работами руководствовались. Даже синтаксически они похожи.
flamefork
04.12.2015 21:38+2А вы какой вариант вычисления хотите сделать автоматическим/неявным в таком, например, случае?
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.DmitrySpb79
04.12.2015 22:04+2А зачем тут что-то особое придумывать? Существуют правила Type casting из языка «С», которые 20 лет уже существуют, и неоднозначностей там вроде нет.
Если говорить о частном примере, который я привел выше, то с точки зрения и здравого смысла, и школьного курса математики, все вполне логично: если мы берем некое вещественное число N раз (что эквивалентно умножению), то и результат будет вещественным. Если мы делим вещественное число на целое N, то и результат тоже будет вещественным. Это курс математики за 2й класс.flamefork
04.12.2015 22:09+2Если принимать как данное, что в «С» все идеально, то незачем создавать что-то новое. Вопрос «принимать или не принимать» оставим за скобкой.
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
asm0dey
05.12.2015 11:57-2А чем плохо перемножение целого и строки?
corristo
05.12.2015 19:51+1Я обычно хэшмапы на сокеты делю.
asm0dey
05.12.2015 21:20Ну в умножении логика более-менее очевидна. Не читая ничего про язык я сразу понял что оно делает и почему используется.
matiouchkine
07.12.2015 18:05Ровно так устроен дефолтный конструктор оператора хвостовой рекурсии в лиспе.
0xd34df00d
05.12.2015 21:50Эти правила в C++ периодически в моих вычислительных экспериментах заставляют меня жалеть, что для конкретного эксперимента я выбрал не хаскель, где вообще никаких приведений нет. Их очень трудно отлаживать.
NeoCode
04.12.2015 15:14+1А в чем проблема сравнивать signed и unsigned, если компилятор знает, что этот аргумент signed, а тот unsigned?
Да, там код сравнения должен сгенерироваться немного другой чем для двух signed или двух unsigned, но для компилятора-то в чем проблема?
egormerkushev
04.12.2015 16:27Попробуйте в ObjC
NSInteger i = -1; NSUInteger x = 1; NSLog(@"%d", MIN(i, x)); NSLog(@"%d", MAX(i, x));NeoCode
04.12.2015 21:09+2В C++ тоже странный результат. Но это проблема компилятора, и то что ее до сих пор не пофиксили, можно объяснить лишь тем что разработчики трясутся над обратной совместимостью с терабайтами древнего кода, который никто не будет переписывать:)
Сравнивать числа разных диапазонов нужно не так, как одного диапазона.
В частности, выражение
i < x
должно превращаться в
.i < 0 || x > INT_MAX || i<x
Можно вывести общую формулу для чисел любых диапазонов. Имплементировать это в компиляторах элементарно, все типы и диапазоны известны.
stychos
04.12.2015 03:24Хотелось бы увидеть сравнение производительности с Go.
voidnugget
04.12.2015 06:06+5Можешь спать спокойно, производительность на уровне плюсов, потому что llvm, и сравнивать корректнее с Rust'ом.
stychos
04.12.2015 06:09-2Я спокойно сплю, мне интересна фактология и что лучше изучать, поскольку Go пиарят сейчас нещадно все кому не лень.
voidnugget
04.12.2015 06:39С точки зрения соотношения производительности и соответствующих рисков у каждого окружения есть свои особенности.
Я сейчас потиху перебираюсь в DPDK JNA Netty Disruptor с самописными асинхронными конекторами под PostgreSQL и ScyllaDB, нужно offheap'ить много в MapDB, определять пулы объектов в directBuffer'ах netty, чтобы уменьшать давление на GC, но и задачи у меня довольно специфические. Не брезгую groovy, но вот в Scala overhead'ы получаются довольно большие.
Даже в том же Go тонна проблем, хорошо что запилили нормальное GC, как у Java 5 :|, особенно сильно меня кумарит отсутствие методов для динамического программирования — нужна кодогенерация, и даже самый банальный strcmp не использует simd оптимизации, очень много чего нужно переписывать ручками на asm'ик. Для примера можно взять тот же ffjson, как единственную нормальную реализацию json сериализации под golang, с кодогенерацией и golang'овским asm'ом в нужных местах.
Учить/не учить — сложно сказать, я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности, но, конечно, до правильно приготовленной неэнтерпрайсовской Java, по рецепту указанному выше, всему этому ширпотребу ещё далеко.
Rust не использую просто по причине плохого дизайна стандартной библиотеки — хрен его знает когда она будет стабильной.
Естественно вопрос are we web yet стоит комом. Вот у Swift'a под вэб сейчас вроде как ничего не видел.
Nimrod подаёт надежды, но его использование в продакшене связано с кучей рисков.
Сейчас требования к этому всему барахлу довольно специфические: нужны disruptor'ы, cqrs-es для пущих реактивностей и шаблонные REST CRUD мапперы для DataMapper ORM'ов, потом это всё ещё нужно обернуть вокруг SOA и сделать вменяемый менеджер зависимостей и интеграции. Большинство хомячков своё мировозрение держит в пределах MVC, и это печалит.
sk1nny_puppy
04.12.2015 10:48Для веба на swift есть perfect.org
voidnugget
04.12.2015 11:00Да, сегодня смотрел.
Из-за FastCGI есть накладные расходы на коммуникацию и производительность не ахти.
Выглядит юзабельно, но некоторые вещи морально устарели.
Googolplex
04.12.2015 16:14хрен его знает когда она будет стабильной
Хм, если вопрос только про стабильность, то стабильной она стала начиная с версии 1.0. Ломающих изменений в рамках 1.0 там быть не должно (исключая soundness-фиксы).
googol
05.12.2015 06:46> я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности
С Руби логичней слезать на что-нибудь вроде Crystal github.com/manastech/crystal:
— синтаксис похож на руби
— использует LLVM для генерации кода, производительность выше чем у Go
— легкая интеграция с C библиотеками
voidnugget
04.12.2015 06:07+3Отличный подарок к Новому Году.
Спасибо Apple.voidnugget
04.12.2015 07:51-12Плохой подарок: ABI и libdispatch отваливается местами, стабильность под Linux'ом стремится к нулю.
Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.
Пока юзабельно только для яблок :|gribozavr
04.12.2015 09:32+3Можете сказать что именно не работает? Мне не понятна фраза «ABI отваливается местами». Можете написать здесь или сразу на swift-users@swift.org.
voidnugget
04.12.2015 11:02-8Есть ошибки в реализации интерфейса с glibc и pthread'ами, под нагрузкой течёт конкретно.
gribozavr
04.12.2015 11:02+5Можно конкретный пример кода?
voidnugget
04.12.2015 11:03-28Нельзя.
gribozavr
04.12.2015 11:06+9Тогда я не могу воспроизвести вашу проблему. У нас в тестах используются pthread, причём под достаточной нагрузкой, что мне кажется, мы бы заметили, если эти тесты текут. Например, один из тестов на модель памяти и атомарные операции github.com/apple/swift/blob/master/validation-test/stdlib/AtomicInt.swift Все тесты проходят как на OS X, так и на Linux.
Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
MaximChistov
04.12.2015 16:37+3Не хотите написать немного про разработку Swift?) Думаю, тут многим это интересно )
egormerkushev
04.12.2015 11:23Я немного не понял, если они к Swift 3 всё перепишут, уберут NS и прочее – можно хоронить ObjC?
Makaveli
04.12.2015 12:15I don’t think anyone should have to fear for the future of Objective C
сказал Craig Federighi (Apple’s senior vice president of software)
А вот когда запилят всё что хотят — вполне возможно, но жить он будет ещё очень и очень долго. Полно проектов, которым переписывать всё на Swift накладно, но проект развивать или хотя бы поддерживать надо.egormerkushev
04.12.2015 12:37Спасибо, успокоили.
Gorthauer87
04.12.2015 13:38Ну а в чем будет сложность перейти на swift целиком, когда он подрастет и переболеет детскими болезнями? Совместимость с objC кодом оставят и не придется старый код переделывать, а новый уже на swiftе можно будет писать.
Не так уж это и сложно — выучить новый ЯП.egormerkushev
04.12.2015 15:06Нет, речь не про выучить новый ЯП. Оригинальный вопрос был в стиле «Надо ли переписывать работающие ObjC-проекты на Swift уже сейчас».
NayZaK
04.12.2015 11:30Concurrency как фичи языка нет, и в версии 3.0 не планируется. Расходимся.
Gorthauer87
04.12.2015 12:03А это что тогда?
github.com/apple/swift-corelibs-libdispatchNayZaK
04.12.2015 12:06+1github.com/apple/swift-corelibs-libdispatch
We are currently very early in the development of this project
github.com/apple/swift-evolution/blob/master/README.md
Concurrency: Swift 3.0 relies entirely on platform concurrency primitives (libdispatch, Foundation, pthreads, etc.) for concurrency. Language support for concurrency is an often-requested and potentially high-value feature, but is too large to be in scope for Swift 3.0.
Gorthauer87
04.12.2015 12:14-3Тогда можно пока учить Rust, после него Swift выглядит как упрощенное подмножество. А уж фреймворки как-то можно освоить в процессе.
Bringoff
06.12.2015 16:08А уж фреймворки как-то можно освоить в процессе.
Изучить синтаксис можно за несколько дней/недель, все остальное — изучение тех самых фреймворков и их подводных камней. Так что соыершенно неясно, чем Rust может помочь в будущем изучении Swift-а.Gorthauer87
06.12.2015 16:12На самом деле все эти концепции, пришедшие из мира computer science, чуть более базовые, чем подводные камни и баги фреймворков. Скажем так, знание всех особенностей конкретного фреймворка не поднимет тебя на качественно новый уровень. В отличии, скажем, от осознания новых для себя абстракций.
Скажем так, если ты знаешь, что такое типы суммы или типы произведения, то сможешь их различить и использовать даже в сишком коде. А если просто используешь ключевое слово enum, не задумываясь что это такое, то никогда.
vitorg
04.12.2015 16:57Grebenshikov опубликовало о том, что Apple опубликовало — так себе звучит, да? :)
house2008
04.12.2015 17:40кто хочет поиграться, то есть песочница от ibm swiftlang.ng.bluemix.net/#/repl
outcoldman
Ну вы хотя бы постарались собрать побольше информации.
— О планах Swift 3 github.com/apple/swift-evolution
— О том, что они реализовали Package Manager github.com/apple/swift-package-manager, и если посмотреть на contributors (https://github.com/apple/swift-package-manager/graphs/contributors) то можно найти, что главный contributor это Max Howell. Тот самый, которого не взяли в гугл, и тот самый, который создал homebrew.
— О шутке дня github.com/apple/swift/pull/17
— О том, что они включили всю историю, включая первый коммит 2010 года github.com/apple/swift/commit/afc81c1855bf711315b8e5de02db138d3d487eeb
kafeman
deniskreshikhin
Причем сам Крис Латнер работает в Эппл с сентября 2011 -))
Видимо даты действительно фальшивые)
Вот и верь после этого людям ((
DenimTornado
А сам он говорит, что с 2005 — http://nondot.org/sabre/ И про то, что к Сфифту подключился в 2010 там тоже есть. Вряд ли он себе ещё и фейковую страничку запилил.
deniskreshikhin
www.linkedin.com/in/chris-lattner-5664498a
Да, верно, это последнюю должность он занимает с 2011 года
roman_kashitsyn
В комментариях к коммиту имеется возможное объяснение: