Одна из причин в том, что язык ещё не достиг стабильности ABI: сейчас никто не гарантирует, что после выхода его новой версии ваш код не сломается. Однако в Apple называют важнейшим приоритетом исправление этой ситуации. А недавно на горизонте показалась версия 3.0, которая должна принести много нового. Означает ли всё это, что настаёт время браться за Swift всерьёз, или целесообразность его использования всё ещё под большим вопросом?
Мы решили расспросить о настоящем и будущем языка трёх специалистов из крупных компаний, уже использующих Swift и не понаслышке знакомых с темой. На наши вопросы ответили:
- Максим Соколов (Avito);
- Игорь Кашкута (Badoo);
- Егор Толстой (Rambler&Co).
Насколько активно используется Swift в вашей компании?
Максим СоколовAvito развивает несколько мобильных продуктов. Наша команда работает над тремя мобильными приложениями. Мы активно используем и будем продолжать использовать Swift. Одно из наших приложений полностью написано на Swift и доступно в App Store. Два других мы начинали писать на Objective-C, но на текущий момент весь новый код пишем только на Swift.
Игорь КашкутаМы не только используем Swift, но и опубликовали на GitHub часть нашего проекта. Chatto был первой ласточкой, пробой языка в нашей CI инфраструктуре и проекте в целом — не без проблем, конечно, но дело удалось. В дальнейшем мы планируем использовать Swift и в остальных частях приложения.
Егор ТолстойСейчас на Swift мы разрабатываем два проекта. Один из них, изначально разрабатывавшийся на этом языке, должен в течение месяца появиться в App Store. Второй, Рамблер.Почта, изначально был написан на Objective-C, но после первого релиза в рамках рефакторинга команда начала постепенно переводить его на новый язык.
Что дал этот опыт? С какими подводными камнями пришлось столкнуться? Рекомендуете ли использовать Swift другим, и в каких именно случаях?
Максим Соколов
Использование Swift имеет как преимущества, так и недостатки. К недостаткам я бы отнёс, во-первых проблемы со стороны IDE Xcode — случаются падения компилятора, самого Xcode, может отваливаться подсветка синтаксиса. Во-вторых, сам язык ещё очень молод, иногда не хватает каких-то инструментов: например, в сообществе всё ещё отсутствует адекватный мок-фреймворк, помогающий писать unit-тесты. Очень не хватает старого доброго OCMock, поддержка которого в Swift оставляет желать лучшего.
Некоторые конструкции языка могут существенно влиять на время компиляции, такие проблемы иногда вводят в ступор. Также большой проблемой сейчас является отсутсвие поддержки рефакторинга со стороны Xcode. Нужно учесть предстоящий выход Swift 3.0, где-то ломающий обратную совместимость. Будем надеяться, что Apple сделает шаги для улучшения ситуации.
Но, несмотря на все недостатки, я всё равно рекомендовал бы разработчикам начинать использовать Swift. Apple очень активно его развивает, и мы видим интерес к языку со стороны других крупных компаний, таких, как IBM. Компаниям стоит задуматься об этой инвестиции в будущее, поэтому Avito уже сейчас имеет приложение в App Store, полностью написанное на Swift. Swift помогает нам существенно повысить качество продукта и положительно сказывается на скорости разработки. Строгая типизация языка позволяет нам писать более безопасный код, поведение которого предсказуемо. Новые языковые конструкции, такие, как дженерики, отсутствующие в Objective-C, позволяют по-новому взглянуть на архитектуру приложения в целом и дают возможность писать код, который можно эффективно переиспользовать.
Игорь Кашкута
Мы не сталкивались с чем-либо, что было бы невозможно преодолеть, все проблемы решаемы. Где баг в языке находился (кстати, часто чинится новыми версиями компилятора, они молодцы), где надо было старый код подтюнить, чтобы его можно было использовать в свифте. Но в целом всё идёт достаточно хорошо. Лично я не вижу смысла в том, чтобы начинать новый проект на Objective-C, пишите сразу на свифте. Если только вам не нужен интероп с C++, эту часть всё же надо на objc делать, у свифта интеропа просто нет. Но опять, и это решаемо, можно сделать на objc и сверху нахлобучить свифт.
Егор Толстой
Опыт интересный — во-первых, поймали очень много различных подводных камней, и узнали, как с ними справляться. Во-вторых, поняли, что нужно срочно писать кодогенератор — время, требуемое на ручное создание моковых классов для написания юнит-тестов просто нереальное. Ну и, конечно, как и все остальные, успели огрести проблем со временем компиляции. Сейчас как раз занимаемся его оптимизацией.
Насчет рекомендаций — хороший вопрос. Как и в большинстве других случаев, здесь просто не может быть однозначного ответа. Нужно смотреть на конкретный проект, его команду, требования бизнеса. Если проект очень крупный и долгоиграющий — лично я все еще склоняюсь к Objective-C.
Как вы предполагаете, что будет со Swift в течение ближайшего года — например, произойдёт ли большой рост популярности с выходом версии 3.0? Может ли он оказаться востребованным ещё и за пределами iOS-экосистемы?
Максим Соколов
Я уже могу отметить большую популярность Swift. И в ближайший год мы наверняка увидим применение Swift за пределами мобильной разработки под iOS. Swift является open source-проектом, и мы уже можем наблюдать появление фреймворков для работы, например, с backend’ом и базами данных.
Игорь Кашкута
С моей точки зрения, версия 3.0 будет по-настоящему нормальной версией 1.0 — детские проблемы будут закрыты, гайды появились, Package Manager есть, исходные коды приложены. Большого скачка популярности я не ожидаю, язык принципиально не изменится — нет никаких преград, чтобы начать что-то делать уже сейчас. Я ожидаю, что рост будет происходить более плавно, по мере появления новых проектов — кажется, почти не осталось причин начинать что-то новое на Objective-C.
Что касается использования вне iOS (OS X, watchOS и tvOS ), то здесь всё не так радужно. С iOS всё понятно, раньше выбора не было, в будущем тоже не будет. У свифта как языка нет никаких «фишек», которые бы побудили разработчиков его использовать. Сравните с другими: Go простой и у него есть горутины; Scala про строгую и гибкую типизацию, но на многолетней базе JVM; Clojure — lisp с интересной идеологией, встроенной в язык, на многолетней базе JVM; JavaScript в виде Node.js позволяет иметь один и тот же код на клиенте и сервере, что открывает путь к изоморфным приложениям + модель программирования в ноде весьма простая и понятная большинству веб-разработчиков + npm, где всё есть. Rust — это такой новый безопасный С++, где всё под контролем, с понятным оверхедом и возможностью использования без рантайма.
Свифт берёт всего понемногу у всех, он очень неплох, но я пока не понимаю, какую нишу он может занять. Мне и самому очень интересно, но всё, что остаётся, — наблюдать.
Егор Толстой
Думаю, что в ближайший год хайп постепенно уменьшится. С другой стороны, сообщество взрослеет, разрабатываются новые архитектурные подходы, компоненты и библиотеки, которые будут упрощать жизнь разработчикам — так что появится больше аргументов в пользу его использования.
Про востребованность за пределами экосистемы пока еще говорить рано, на мой взгляд — время покажет.
4 июня на петербургской конференции Mobius все ответившие выступят с докладами, касающимися iOS-разработки. Один из их докладов будет непосредственно о Swift: Максим Соколов подробно расскажет об использовании в нём дженериков. Если после этого материала вы ощутили, что для вашего проекта настало время использовать Swift — не пропустите :)
Комментарии (33)
okla
24.05.2016 17:45+1Стабилизация ABI запланирована на версию 4.0
thread.gmane.org/gmane.comp.lang.swift.evolution/17276
phillennium
24.05.2016 18:06+1Ой, спасибо. Вступление к материалу готовил ещё до появления этой новости, а потом на официальный блог поглядывал, но там об изменении планов не сообщали. Отредактировал теперь текст.
phillennium
24.05.2016 18:31+2Ну и, кстати, запланирована не на 4.0, а просто на «после 3.0», так что может попасть уже в 3.x:
> Quite sad we could not get into ABI stability for Swift 3… but are we talking Swift 3.1 or 4.0?
We’ll start discussing post-3.0 releases in August. Until Swift 3 is really wound down, it is almost impossible to make forward looking plans.
AnatoliD
24.05.2016 18:35-7При прочтении статьи вспоминается собственный опыт разработки программно — аппаратных систем с 1973 года, в рамках лаборатории АСУ и АСУТП и не только…
вначале был аппаратно — ориентированный ассемблер (о коболе и фортране не упоминаю) C, потом Бейсик ориентированный на решение простейшего класса задач, Quasic, разработанный в Пущино — аппаратно — ориентированный бейсик, прошли стройными рядами Паскаль, DOS, первых XT and AT, с частотами процессоров 4.7 мгц, PHP, Java…
и, наконец, по проишествии 43 лет все вернулось к C#, а до этого к Паскалю — Delphi.
Ныне похоже начинается новый круг, по спирали вверх, как положено в диалектике, ASP.NET 5, потихоньку умершая с переходом к Core 1.0…
А ведь сколько шуму было, когда на сайте майкрософт я написал в середине 2015 статью «Почему я выбираю Windows 8.1 и WebForms?» где я доказывал, что пока ASP.NET 5 (тогда такое было название нового чуда) станет на ноги и обзаведется UI — элементами пройдет ну лет 5 минимум, вследствие чего остается только ориентироваться либо на MVC, либо на Web Forms…
Viacheslav01
24.05.2016 20:57+1Как не старался но не уловил связи между «43 года», «все вренулось», «C#», как вы умудрились их связать в одном предложении?
Andrey-072
24.05.2016 22:16-3Так это нисколько не удивляет! Многие люди до сих пор не понимают, какая существует связь между парадными и подъездами, бордюрами и поребриками. Про использование мягких знаков в рамках средней школы я лучше вообще промолчу. Это, ведь, не главное! Главное — инновации и свежий взгляд! А то, что этот свежий взгляд уже давно устарел — ерунда. Важнее, что пипл схавает.
AnatoliD
24.05.2016 23:03-5Если вы мне докажите, что свежий взгляд давно устарел буду очень рад. О себе — последняя должность на оборонном заводе — зам. генерального директора… ныне в США, где делал проекты в т.ч. для НАСА, многократно приглашался в Россию для руководства собственным проектом, по сложности много превосходящим гугл, фейсбук и пр.
AnatoliD
24.05.2016 23:01-5Поясняю, я работал на оборонном заводе, в отраслевой лаборатории АСУ и АСУТП, в далеком 1976 году спроектировал и реализовал в «железе» — на 580 серии, на ассемблере, интерполятор — систему управления станками с ЧПУ токарной и фрезерной группы… забавно, но с тех пор по проишествии 40 лет в России так никто и не реализовал ничего подобного — все что делается ныне, делается на контроллерах практически той же серии, но Сименс. Что формально изменилось за 40 лет в области ПО по обеспечению автоматизации процессов, а не генерации мегатонн макулатуры, какой завален интернет? да ничего!
Тогда же появились одноплатные эвм мс -1201, с вшитым бейсиком, с функциями в принципе во многом схожими с нынешним бейсиком, что нынешнюю публику безусловно устроило, но не тех кто занимался автоматизацией процессов, нужен был бейсик способный работать с железом, таковой появился — квейсик. Что формально изменилось? бейсик 1974 — 1976 в одноплатной эвм и нынешний отличаются только функциями…
С, Unix, паскаль — это все то время — им соотвествует C#, Delphi нынешнего времени…Viacheslav01
24.05.2016 23:32+5Сдается мне C и C# совершенно разные вещи и совершенно не соответствуют друг другу.
И опять же мне не понятно «так и не реализовал ничего дободного».AnatoliD
24.05.2016 23:50-5Посмотрите мое био, чтобы легче было понять друг друга…
Я не чистый программист, а разработчик программно — аппаратных комплексов, с соответствующими запросами к функциональности ПО… в настоящий момент реализую проект, вероятно, наиболее сложный в моей карьере… что из этого выйдет посмотрим… и откровенно говоря меня интересует только эта тематика — на интернете к сожалению пока не нашел никого с кем можно было поговорить на эту тему, за исключением коллег, занимающихся американской системой Сократ
AnatoliD
25.05.2016 00:45-4Относительно «так никто и не реализовал ничего подобного» в России… имеется ввиду создание полностью ПО и аппаратных средств на 580 серии — специализированные контроллеры Сименс, реализующие те же функции, как в части программных, так и аппаратных средств, созданы не в России.
Относительно простых языковых средств — С и C#, бейсика тех времен и нынешних принципиальных отличий не имеется — и тот и другой язык НЕСОВЕРШЕННЫ для реализации даже простых стендов… программно — аппаратный комплекс для НАСА мне пришлось реализовывать на Матлабе — C#, Delphi для этого не годятся…Viacheslav01
25.05.2016 16:18+2В 80-х годах у отца на заводе трудились ЧПУ полностью советской разработки на базе 16 битного МП 18хх серии, точнее не помню к сожалению. Т.к. создавали подобное, очень даже создавали.
Насчет программно аппаратного комплекса, уж если надо управлять железом в реальном времени, то C# там точно делать нечего, это людой разработчик скажет, а вот тому самому C очень даже место.AnatoliD
25.05.2016 17:29я прекрасно знаю, причем в деталях о чем вы говорите — об мс — 1201, позже их назвали «электроникой». Делали их на Кванте в Зеленограде, мы на них много чего делали. Где — то в 1980 на них появились первые системы управления станков токарной и фрезерной группы… с тех прошло достаточно много времени те одноплатки уже давно нигде не применяются
Я говорю о системе на базе к580 — вот они да — применяются везде, только не российская или ссср — кая разработка, а сименовская
AnatoliD
25.05.2016 17:35-1Относительно C# и C для управления программно — аппаратным комплексом… вы видимо не очень хорошо представляете реальные задачи и необходимые в связи с этим программные средства. К примеру средства Матлаба содержат прикладные пакеты, которые в C или C# пока не предполагаются в будущем…
AnatoliD
25.05.2016 17:43-1На ХабраХабре я видимо заканчиваю участие по нескольким причинам:
1. здесь очень странная система оценки, когда все что касается собственного опыта оценивается отрицательными оценками, притом что я действительный член одной из американских академий…
2. статья посланная мной в адрес редакции о системе, о которой в России вообще никто не знает, была редакцией отвергнута, притом что моя пояснительная записка об этой системе отправленная в адрес Админ. Президента была сразу переадресована в Мин. Обороны…Viacheslav01
25.05.2016 20:12-1Ув это так, с этим можно только смириться.
AnatoliD
25.05.2016 21:04-1Речь в статье идет об американской системе «Сократ», о которой есть очень краткое упоминание в английской версии Википедии — эта система проектируется с 1983 года под эгидой военной разведки США. Ныне третья версия системы позиционируется как Супер — Академия наук, обеспечивающая «генерацию» технологий.
Система прошла обкатку в крупнейших компаний США и положена в основу закона H.R. 516 Return Jobs in America Act от ноября 2011. Назначение системы — обеспечение технологического отрыва от России и Китая на поколения. В настоящее время система разворачивается по всей территории США.
С руководством этой системы я знаком лично… и лишь по одной причине — занимаюсь этими же вопросами — ре — индустриализации и т.п. в середине 2012 (до дела Сноудена) я выступил инициатором разворачивания системы Сократ и в России тоже. Полгода велись видеоконференции на уровне руководства системы Сократ, Деловой России с моим участием…
ну и т.д.
Забавным является то что охламонов из хабрахарбора это не заинтересовало…
ну да ладно… проблема в том, что по данной тематике не могу найти на интернете никого с кем бы можно было иногда поговорить по этой тематике…
AnatoliD
26.05.2016 03:58-1с трудом но вспоминаю, но на мс — 1201, первых одноплатных эвм (до электроники нц), использовались процессоры не 1801 — 1811, а другие, название не вспомню, к нам на завод вначале пришли все комплектующие, без фотошаблонов и печатных плат и я паял все вручную, возможно, до десятка тысяч проводов, наводки конечно были страшные…
Sergio_ml
25.05.2016 00:15«Новые языковые конструкции, такие, как дженерики, отсутствующие в Objective-C»
Видимо Максим не вкурсе, но вообще то дженерики есть в Obj-C
WisDooMer
25.05.2016 10:08+4В Obj-c нет compile-time дженериков, а есть только Lightweight Generic, которые мало что имеют общего со Swift'овыми. По сути это просто sintax sugar.
S_A
25.05.2016 04:14+2Хм. Игорь уже в Баду и на Свифте :) Молотком.
По теме. Свифт берет от всего понемногу, но слишком много всего берет, и часто из-за backward и legacy. То же управление памятью — явно костыль совместимости. Мне он напомнил C#, который обрастал костылями и фичами, но в его случае сложнее отличить одно от другого :)
Про себя могу сказать, что со Свифта ушел на Xamarin, как только последний стал бесплатным. Сейчас все языки уже обросли костылями (а Свифт в этом оказался очень быстр), даже любимый JavaScript, и если бы Telerik не был бы таким жадным, возможно и тот же Xamarin бы не был так популярен. В любом случае на мой взгляд C# и JavaScript наименьшее зло в плане баланса порога вхождения (не так уж он и низок у Свифта) и широты инструментария (речь о мобильных приложениях средней сложности).HeMet
25.05.2016 09:38+3То как в Свифте сделано управление памятью — не костыль, а сознательное решение, принятое после того, как взвесили все за и против. Тут комментарии от создателя языка: lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html
S_A
25.05.2016 13:29Может тогда поясните, почему во многих других языках его все же нет, и они популярны, и на них пишут?
Я сам на плюсах писал очень долго, и говорю не о том, что «GC хорошо», а «управление памятью плохо». Надеюсь что я не настолько примитивно понимаем. Memory Management скорее пример в случае Swift (хотя очень наглядный, так как без этой сознательной фичи много чего не сделать при создании UI), я писал о другом вобщем-то — о пороге вхождения больше.
Лично меня послушать — все языки с костылями (я когда-то свой делал, без них очень сложно что-то сделать), и даже ООП в моем понимании -«костыль», призванный в свое время упростить, убыстрить и переиспользовать, а по факту приведший к усложнению архитектур вместо микромодульности.HeMet
25.05.2016 19:56+1Я не специалист по тому, как развивались подходы к управлению памятью, но могу предположить, что так исторически сложилось. Английская Википедия упоминает, что первый сборщик мусора был применен в Lisp еще в 1959, а автоматический подсчет ссылок в схожих масштабах был использован Apple только в 2011. Т.е. к моменту появления той же Java в 1995 году, mark-sweep GC, видимо, были куда более проработанным вариантом. Хотя в том же году вышел Delphi 1, где подсчет ссылок использовался для управлением строками и динамическими массивами.
Можно еще рассмотреть ARC, как он реализован в Objective-C. Круговые зависимости разрываются с помощью слабых ссылок, т.е. с каждым объектом может быть связана своя таблица слабых ссылок, которые надо обнулить, когда объект помрет. Доступ к таблице должен быть синхронизирован, что делает слабые ссылки узким местом в мнопоточном коде. Это плохо для серверных приложений.
В Свифте эту проблему решили, изменив то, как сделаны слабые ссылки. Во-первых, счетчики слабых и сильных ссылок хранятся в старших разрядах указателя на объект, что позволяет использовать атомарные операции для их изменния. Во-вторых, больше нет никаких таблиц, потому что обнуление слабых ссылок — ленивое, в момент обращения к ним. Отсюда интересное следствие: объект на который есть слабые ссылки сначала превращается в «зомби», а окончательно осовбождает память только когда обнулится последняя слабая ссылка.S_A
26.05.2016 04:00Не слышал о серверных приложениях на Свифте или Objective-C. На C#/python/node.js слышал/видел/писал (и на С++ правда тоже). Не суть. Со времен появления коммерческого программирования сложилось так, что языки не для того делают в своём большинстве чтобы разные технологии в их основе применять.
Даже банально пример из сайтостроения — при проектировании информационной архитектуры подсчитывают, сколько шагов посетителю нужно сделать до достижения цели (а потом и качество того что получит, оценивают). Если сравнивать код на шарпе и на свифте… без Xamarin.Forms есть взять — то это практически те же фаберже, только без магии ссылок, по сути заботы о ЖЦ объектов. Забота о ЖЦ не есть плохо с точки зрения напряжения мозгов, это есть плохо с точки зрения поддерживаемости и расширяемости, переносимости на другие языки и читаемости кода в целом (у Макконнела есть понятие cohesion — связности), и, возвращаясь к примеру с сайтами — увеличение числа шагов по достижению цели, и конечная картина не столь ясная.
Конечно, начудить плохого кода можно где угодно. И конечно, тому кто владеет инструментом, всё ни по чем. Я же в своё время был разочарован Свифтом, хотя и возлагал на него очень большие надежды, и когда-то был рад анонсам портирования на другие платформы. Потом взвесил шашечки и ехать, и пришел к выводу для себя лично.
corristo
26.05.2016 12:59+1по сути заботы о ЖЦ объектов
я бы не назвал это заботой о GC, а назвал бы сознательным обдумыванием object graph программы и отношений владения, чтобы правильно расставить слабые ссылки. Это полезно даже при наличии GC.
fgrdn
25.05.2016 10:08+1с плюсами бы без obj-c прослойки начал работать — было бы замечательно. так в целом понравилось на нем программить.
Chake13
Крутая статья. Спасибо :)
А что делать тем же самым начинающим разработчикам, которые только начинают изучать программирование под ios? Имеет ли им смысл начинать сразу со свифта без «потери времени» на obj-c или нет?
Jecky
Obj-C даст понятие откуда ноги растут у всех NS-классов и системных API в iOS.
vsb
В самом начале можете ограничиться Swift. Но я настоятельно рекомендую изучить Objective C в какой-то момент. Никуда вы от него не денетесь, если сколь-нибудь серьёзно собираетесь заниматься разработкой под iOS. Миллионы примеров кода в интернете, миллионы существующих проектов, книги, учебные материалы, готовые библиотеки, это всё никуда не денется. Objective C не устарел, не отменяется и не выкидывается, Swift с ним будет сосуществовать ещё очень долго.
Makaveli
Язык не столь важен, его освоить можно быстро. Важно знать системные фреймворки и инструменты. На каком языке найдёте подходящий обучающий материал, на том и осваивайте.