Здравствуйте, vdimas, Вы писали:
V>В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.
У тебя только один вариант сохранить лицо — показать код.
Здравствуйте, AlexRK, Вы писали:
ARK>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины.
Здравствуйте, D. Mon, Вы писали:
ARK>>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины. DM>Ну так человек в будущее смотрит, а не в прошлое.
Дык тут бабуля надвое сказала, за кем будущее.
Несколько десятков лет назад поклоннники Lisp, Forth и APL тоже, вероятно, смотрели в будущее.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
I>>>И запускать эти тесты надо полагать, придется на боевой системе ?
A>>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".
I>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
I>>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
A>>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
I>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем:
1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет?
Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
I>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
Здравствуйте, D. Mon, Вы писали:
DM>А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary
Ну так можно запускать его как front-end на билд сервере маковском (или виртуалке ). А потом уже у себя делать нормальные бинарники. Но опять же это в случае, если Apple будет против кроссплатформенности, а в этом случае не будет ещё и разработанных удобных библиотек (в смысле уже на Swift'e, даже если там внутри и обращение к C или OS API) под соответствующие платформы и надо будет обращаться напрямую к разным C библиотекам или OS API. А это практически убивает один из главных плюсов.
DM>Я просто увидел вот это: DM>http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/ DM>Там говорилось, что у массивов есть map, filter, reduce и все.
Видимо имелось в виду "всё что есть из функциональщины". )
DM>Мне он тоже в целом понравился, особенно null-safety, но на фоне Dивной интроспекции и МП — слабовато.
О, да, точно, про интроспекцию времени компиляции я забыл. Кстати, очень странно что её нет в Swift'e. Тем более, что там есть атрибуты и т.п. Может снова где-то в документации потерялось? Но без неё реально печально будет со многими моментами. Уже даже в C++ планируют добавить её, а тут...
DM>Вот тут правильно сказал человек: http://justy-tylor.livejournal.com/221988.html
Не воспринимаю подобные высказывания, если автор не указывает предлагаемую им лучшую альтернативу. В данном случае ничего конкретного не указано...
Здравствуйте, andyag, Вы писали:
I>>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.
A>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут.
Вместо тестов проще держать под рукой вещи навроде LINQPad
I>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
A>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем: A>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
A>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет? A>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
Репл помогает собирать информацию о текущем состоянии процесса.
I>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
A>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение
Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, andyag, Вы писали:
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. C>Это Apple. Они могут — Carbon API они таки запретили, хотя им пользовались такие гиганты как Photoshop.
А давайте попробуем дать оценку количества кода, который зависел от Carbon API и количества кода, написанного на Objective C. Я плохо даю оценки, но наверное "в 10 раз" — это сильное занижение.
A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии. C>То есть? Рефлексию несложно добавить — это же LLVM. Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.
Да какая разница-то? На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год. Просто потому что.
Здравствуйте, Ikemefula, Вы писали:
I>У тебя только один вариант сохранить лицо — показать код.
Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
Кстати, документация вообще кривая. Облазил всё описание языка и не увидел ничего про указатели вообще. Естественно подумал что и нет их. А в другом, совершенно "левом" месте (типа про доступ к Cocoa и т.п.) вижу работу с указателеми (представленными соответствующими классами), причём в коде видна инициализация такого указателя адресом разных структур языка (кстати, вот оно преимущество отсутствия GC типа jvm/.net!). Т.е. в языке есть операция взятия указателя "&", но нигде в описание языка про неё не сказано...
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
A>>Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.
I>И что с того ?
У любого программиста, прочитавшего больше десятка книжек и написавшего больше несколько сотен килострок кода есть свои ценности, переживания и убеждения по поводу "что такое хорошо и что такое плохо". Ценности эти далеко не всегда относятся к любимому языку или любимой библиотеке, часто ценности находятся на более высоком уровне и описывают уже не любовь к инструментам, подходома и знаниям, а любовь к множествам инструментов, подходов и знаний. Все эти множества определяются через "что такое хорошо". А есть ещё "что такое плохо". Через этот критерий определяются всякие штуки, к которым не то что любви нет, а прямо порвать на куски хочется. Эти "хорошо" и "плохо" ни разу не объективны.
Теперь, отвечая на ваш вопрос: "сильно тошнит".
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
I>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.
А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти. Так и будут продолжаться все эти глобальные синглтоно-сервис-локаторы и сериализация руками в NSDictionary — вместо IoC-контейнеров и сериализации из коробки. Так и будут эти люди писать костыли, чтобы проинициализировать ленивые синглтоны в правильном порядке, потому что язык (и рантайм, и сторонние решения) не дают ему вообще никакого намёка, что возможно что-то не так, и можно сделать как-то иначе. Это только абстрактные программисты знают ООП, признают штуки "dependency injection — это по умолчанию" и понимают, что вообще прочитать объект из JSON — это не 2 дня работы, а что-то нечаянно написанное между двумя глотками кофе. А неабстрактные программисты — это молодые коллеги, которые начали свой путь с Objective C. И существование этих самых ребят — это то самое, что мне не нравится в том, что делает Apple.
I>Рефлексию легко добавить, и лучше если это будет чуть попозжа. Как вариант, всунуть компайл-тайм рефлексию, шоб сильнее отличиться от дотнета и джавы
Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.
Здравствуйте, Ikemefula, Вы писали:
A>>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.
I>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут. I>Вместо тестов проще держать под рукой вещи навроде LINQPad
Как так — ничего? Если контекст проблемы более-менее понятен, намного проще этот самый контекст накидать в виде теста и несколько раз прокрутить в разных вариациях, чем методом тыка сначала этот контекст ловить во время выполнения кода в продакшне, а потом судорожно писать в реальном времени какие-то команды с вероятностью написать не то, или тупо забыть что ж вы там такое написали в итоге, когда вроде всё уже понятно.
I>>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию I>>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"
A>>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем: A>>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
I>Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".
A>>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет? A>>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.
I>Репл помогает собирать информацию о текущем состоянии процесса.
Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?
I>>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
A>>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
I>Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение
I>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()
I>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.
Здравствуйте, andyag, Вы писали:
A>Теперь, отвечая на ваш вопрос: "сильно тошнит".
Хы, вы кажется первый, кого я вижу с такой реакцией на Swift. А можно тогда развернуть поподробнее? )))
Просто лично у меня были исключительно положительные эмоции при прочтение описания языка. И это при том, что я довольно привередливый в этом смысле, знаю много разных современных языков и являюсь нелюбителем продукции компании Apple.
A>Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.
Вообще то как раз только интроспекция времени компиляции (как в том же D) и имеет смысл для статически типизированных компилируемых языков. А убогие интроспекции времени исполнения, как в Java/C# — это только от недостатка умения. Ну и я вообще то очень удивлён, что в Swift'e нет нормальной интроспекции (а может всё же есть, просто снова не разглядели в документации?). Это серьёзный минус.
Да, и насчёт факториалов во время компиляции... Я бы сказал, что полное отсутствие метапрограммирования — это для меня как раз основной минус Swift'a, который не позволяет представить его основным языком для меня.
Здравствуйте, andyag, Вы писали:
I>>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут. I>>Вместо тестов проще держать под рукой вещи навроде LINQPad
A>Как так — ничего? Если контекст проблемы более-менее понятен,
Часто он даже неизвестен. Во когда через репл локализуется, будет понятным, тогда результатом становятся тесты
> намного проще этот самый контекст накидать в виде теста и несколько раз прокрутить в разных вариациях, чем методом тыка сначала этот контекст ловить во время выполнения кода в продакшне, а потом судорожно писать в реальном времени какие-то команды с вероятностью написать не то, или тупо забыть что ж вы там такое написали в итоге, когда вроде всё уже понятно.
Ну вот проблема, покажи как ты будешь решать тестом. Вызываешь нативную функцию файловой системы, она асинхронная, создает фолдер. Отваливается по ошибке 12, это значит что объект уже существует. На всех остальных девайсах такого пока не заметно.
Нужно установить, что за проблема и как ее пофиксить. Задавай вопросы, Говори, какие будешь писать тесты, а я скажу тебе результаты. Т.е. Я показал тебе ровно то, что увидел в отладчике — место откуда летит исключение.
I>>Как будто отладчик вот так вот просто даст ссылку на мертвый ресурс. Я, для начала, даже не знаю где проблема. Мне нужно из отладчика локализовать.
A>А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".
См проблему выше, никаких падений с мертвым ресурсом там нет.
Вот еще вещь — вызываешь функцию, асинхронную, три раза с разными праметрами, не дожидаясь завершения. Функция нативная. Далее надо дождаться пока все колбеки завершатся и продолжить кое какие действия. Время от времени эта часть зависает.
I>>Репл помогает собирать информацию о текущем состоянии процесса.
A>Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?
Я про ресурсы ничего не говорил. Смотри мои примеры
I>>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()
I>>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
A>Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.
Я не знаю заранее, какаяя информация мне нужна. Может это наборы данных по воркерам, их тоже в логи пихать?
Я боюсь девайс не выдержит такой мониторинг
Здравствуйте, andyag, Вы писали:
I>>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.
A>А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти.
Культура растет не из за языка, а из за решаемых задач. Платформа все таки набирает вес и сообщество разработчиков пополняется, что очевидно. И так же очевидно, что пополняется не только студентами.
Здравствуйте, andyag, Вы писали:
A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
А вы что предлагаете взамен?
Конечно, не ошибается тот кто ничего не делает. Можно не изобретать ничего нового, юзать старые уродливые языки еще сотни лет и не пытаться ничего улучшить.
Здравствуйте, NeoCode, Вы писали:
NC>Здравствуйте, andyag, Вы писали:
A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два. A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых. A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
NC>А вы что предлагаете взамен? NC>Конечно, не ошибается тот кто ничего не делает. Можно не изобретать ничего нового, юзать старые уродливые языки еще сотни лет и не пытаться ничего улучшить.
У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:
1. Организовать на кухне музей альтернативного искусства
2. Убрать
3. Посыпать сахаром и оставить на потом
Здравствуйте, andyag, Вы писали:
A>На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год.
Здравствуйте, andyag, Вы писали:
A>У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:
A>1. Организовать на кухне музей альтернативного искусства A>2. Убрать A>3. Посыпать сахаром и оставить на потом
A>Ваши действия?
Указать оппоненту на то, что сравнение нового языка программирования с продуктом жизнедеятельности кошки как минимум нужно еще обосновать, и весьма серьезно обосновать.
). А потом уже у себя делать нормальные бинарники. Но опять же это в случае, если Apple будет против кроссплатформенности, а в этом случае не будет ещё и разработанных удобных библиотек (в смысле уже на Swift'e, даже если там внутри и обращение к C или OS API) под соответствующие платформы и надо будет обращаться напрямую к разным C библиотекам или OS API. А это практически убивает один из главных плюсов.
