Comments 40
— Стабильно
— Без «плюшек» ввиде багов с ооочень долгим компиляцией массива, в котором ты запилил еще OPTIONAL переменную…
Ну и разумеется AppCode отвратительно работает, что очень удурчяет.
Вообщем поживём, увидим :).
ввиде багов с ооочень долгим компиляцией массива
Это далеко не самый страшный баг свифта) но вернуться на обж-си я уже не могу, глаза вытекают…
http://openradar.appspot.com/radar?id=4971716266688512
Не понятно зачем они это называют 3.0, а не 0.3.
При этом правило «стабилизируем API на версии 1.0» в этом случае уже не работает.
Мне более импонирует использование semver + плюс оговорки для major == 0
, чем такой популизм.
Тот же rust пошёл по пути постепенного развития, но базовые вещи зафиксированы с версии 1.0.0
. А то, что ещё не зафиксировано и развивается — недоступно в stable. Т. е. новые api в libstd и libcore появляются только после их обкатки и в финальном виде. Что, несмотря на довольно высокий темп релизов (раз в 6 недель) позволяет выдавать продуманное стабильное API
во-первых, это более массовое тестирование, а значит меньше укромных уголков для крупных дефектов;
во-вторых, после набора определенной критической массы поддержка Obj-C может быть сильно ограничена с высвобождением средств разработки.
Но разделяю вашу фрустрацию.
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Это примерно соответствует тому, на какой стадии сейчас находиться разработка Swift, учитывая то, с какой легкостью они позволяют себе переименовывать базовые методы в стандартной библиотеке языка. Я не хочу сказать что это само по себе плохо, просто в таком случае было бы честно говорить, что текущая версия языка – 0.3.
Это говорит о том, что либа, собраная на Swift 2.0 уже не будет резолвиться с 2.2 версией языка. Коллеги из стабильных языков:
В C++, насколько я знаю, стандартизации ABI нет до сих пор (я знаю только про пропозал Саттера: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf, но за его судьбой не следил). Ну и интересно узнать про языки вне платформ JVM и .NET, у которых есть стандартизованные ABI интерфейсы.
Посмотрим что тут получится. Так сказать, сравнение развития ситуации при инъекции бабла.
Swift 2:
func square(a:Int) -> Int { return a * a }
print(square(10))
Swift 3:
func square(a:Int) -> Int { return a * a }
print(square(a:10))
или
func square(_ a:Int) -> Int { return a * a }
print(square(10))
Переименование функций, например, из «3.0».componentsSeparatedByString(".") в «3.0».components(separatedBy: ".") могли быть следствием этого.
https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md
В данном случае речь идет о единообразии и чистоте языка. Теперь функции единообразны с инициализаторами, где требовалось указывать первый параметр обязательно, а если ты не хочешь, то надо было ставить "_". А в других функциях требовалось наоборот дважды указывать название первой переменной, чтобы мочь ее указывать в вызове. Это могло быть confusing для людей, изучающих язык. Теперь все сделано единообразно.
ЗЫ как человек, который «волею судеб» год писал приложение в продакшене только на Swift каждый день, скажу, что язык мне нравится. Очень дисциплинирует. Иногда, когда возвращался на 5 минут в Obj-С, глаза действительно кровоточили от синтаксиса. Также, привыкнув к Optionals, порой было страшно в Obj-C, что передам nil в какой-то метод, которые его не принимает. Но на днях прям плотненько вернулся в старый проект на Obj-C и оказалось, что это как ездить на велосипеде, руки то помнят :))) и можно писать точно также хорошо.
Вообще, сейчас в язык добавили много операторов-подсказок для компилятора, вроде NS_REQUIRES_NIL_TERMINATION.
Планируется, что Swift будет работать на многих платформах, включая FreeBSD, Raspberry Pi, Android, Windows.
Захотел тут попробовать что-то для Linux сделать на Swift — упёрся в то, что ничего для работы с сетью пока не реализовано. Когда хотят реализовать — планов не нашёл, только «not implemented yet», то есть сделать на сервере какой-то запрос к какому-то другому REST API надо какими-нибудь обёртками на, например, сишным CURL (так делают IBM). Но хочется как-то из коробки
Ещё потихоньку портируют Foundation Framework из Obj C. Здесь сказано, что NSURLRequest доступен и для Swift тоже.
В кроссплатформенный Swift ещё перенесли не все возможности Foundation Framework, но это одна из главных целей, поставленная для Swift 3.0:
Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift 3 goal of portability.
Источник
Сейчас Foundation собирается довольно сложно, но к релизу должны поправить.
Здесь сказано, что NSURLRequest доступен и для Swift тоже
Так это документация для макоси, никаких проблем для iOS / tvOS / OX X нет, там бриджинг на все фреймворки из Objective-C из коробки.
В Linux то нужно опенсорсный Swift тащить и опенсорсный Foundation (тот что swift-corelibs-foundation), а там, к сожалению, написано:
NSURLSession and related classes are not yet implemented.
Насколько я понимаю, по уровню и наличию синтаксических плюшек вроде лямбда-выражений/nullable-переменных языки сопоставимы. Об IDE судить не берусь. Но на C# уже можно писать и для Android, и для iOS, а Swift только на пути к этому (да и с этой самой ABI-совместимостью у .NET получше)?..
Если есть желание писать под все мобильные платформы (iOS, Android, и, возможно, Windows Phone) на C#, то вероятно речь идет о silver bullet в лице Xamarin. Говорить о нем можно бесконечно, при этом как хваля его, так и презирая. Объективно, чтобы создать приложение, нужно:
1. Какая-то IDE для проектирования интерфейса;
2. Знание жизненного цикла приложения на мобильной ос;
3. Знание нативных библиотек;
«Мираж» Xamarin в том, что для того чтобы написать что-то на C#, вам, хотите вы или нет, придется разобраться в пунктах 1, 2 и 3. При этом на май 2016 года ни Xamarin Studio, ни Visual Studio нет нормального дизайнера.
— Для iOS вам придется использовать XCode Interface Builder, так как Storyboard формируются криво, а работа с Constraints начинает утомлять неточностью;
— Для Android вам придется использовать Android Studio и линковать xml-файлы обратно в Xamarin Studio, так как «IntelliSense» работает не очень хорошо, а для ресурсных xml не работает вовсе. Если конечно вы не ниндзя и пишете без подсказок в коде.
Далее вам будет необходимо использовать стандартные функции фреймворка или даже наследоваться:
— Из мира iOS вас теплыми объятиями встретит именование Objective-C функций, binding'а, интересные конструкторы с указателями;
— Из мира Android вас повстречает обязательное наследование от Java.Lang.Object и увлекательное жонглирование интерфейсами;
Ну и вишенка конечно — вопросы многопоточности, работы с сетью и хранения данных. Тут вы быстро попытаетесь спрятаться в уютном .NET домике. Он будет настолько теплым, что вы начнете выстраивать в нем свою параллельную вселенную, которая действительно будет работать.
Потратив значительное время на изучение нативных инструментов разработки, зазубривание нативного API и библиотек, а также переиначивая их на C#-лад, вы сделаете свое первое мобильное приложение, которое будет работать как надо. И будет выглядеть как нативное.
Но в этот момент *гифка где Гендальф-Белый плачет на фоне Хельмовой Пади, дождавшись помощи Эомера с войском рохирримов* — вы оглянетесь и скажете «я сделал это!», но встретившись глазами со своим боевым конем Xamarin'ом проскользнет секундная неловкость, и вы скажете: «Спасибо друг, дальше я сам», и нативная разработка станет для вас не такой страшной и более привлекательной.
Вытерев скупую мужскую слезу с мужественной щеки и, оценив перспективы C#, понимаешь, что он имеет крайне нишевое применение в мобильной разработке. Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. Вероятно это случится к 5 или 6 версии Swift года через два-три. И новые программисты вряд ли будут выбирать C# для этой связки.
Мое субъективное мнение — Swift на текущий момент слишком дорого обходится в промышленном использовании. Перепиливание проекта после каждой новой версии требует вливание человека-часов, конвертируемых в $. Тот же Xamarin стабильнее.
Objective-C не такой страшный как кажется на первый взгляд, и не такой «динозавр» как можно подумать. Если понимать как он работает внутри, то у него много общего с тем же C#.
C# отличный язык, мой любимый. И я фанат Miguel de Icaza. Но я понимаю, что доля C# в мобильной разработке даже в среднесрочной перспективе имеет форму дули. Но, тем не менее, Xamarin — это фантастическая штука, через которую я бы советовал пройти каждому C#/.NET программисту, который хочет приоткрыть для себя дивный мир мобильной разработки.
А насчёт
«Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. » Вероятно это случится к 5 или 6 версии Swift года через два-три."
мне кажется, за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса. Впрочем, не знаю, насколько это вероятно — просто тоже нравится C#. )
за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса.
К тому моменту для большинства может встать один единственный, и страшный вопрос: «а зачем, если есть Swift?»
C# никуда не денется, как и Xamarin, но может стать своеобразным «шахматным клубом».
А на данный момент можно расслабиться, Google от слов к делу пока не перешел. Так что сейчас Xamarin, это «Уникальное предложение… Только сейчас… Вы сможете без труда… и т.д.» :-)
Swift 3.0, много шума, а что на деле?