LINUX.ORG.RU

Apple открыла исходный код Swift

 apache license, , , ,


1

5

Стал доступен исходный код языка программирования Swift от Apple. Теперь сторонние разработчики могут присылать багфиксы, улучшения и приносить Swift на другие платформы.

Исходный код доступен под лицензией Apache License 2.0.

Репозиторий на GitHub

>>> Подробности

★★★★★

Проверено: beastie ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от anonymous

D мертворожденный, нет смысла обсуждать, считай что его не существует.

Rust хороший, но мне очень не нравятся его сигнатуры функций, в Swift они сделаны значительно лучше, ARC впилили очень органично, type inference лучше чем в Rust.

Важно, что сделали package manager так же как в Rust в первом «опен сорс» релизе - я считаю, что язык/платформа который выходят сейчас должны иметь батарейки для правильного развития на старте.

Но вообще главное преимущество не в этом, а в том что миллионы людей пишут на Swift продакшен за деньги, в то время как на Rust их человек наверное 50? :)

umren ★★★★★
()
Ответ на: комментарий от umren

миллионы людей пишут на Swift

Для миллионов заднеприводных пользователей. Может и хорошо, то эта каша кипит где-то в стороне от свободных проектов )

makoven ★★★★★
()
Ответ на: комментарий от umren

Чем же сигнатуры в штифт лучше rust? Вообще этот ваш штифт годится для системного программирования? Там можно работать с указателями?

anonymous
()
Ответ на: комментарий от anonymous

С D некорректно сравнивать, весовая категория не та. А Rust - прямой конкуррент, и проигрывает Swift начисто. Главная причина - над Swift работают люди, которые пишут LLVM, а над Rust - нет. Оба языка генерят код для LLVM, но разработчики Swift имеют возможность делать вот такие например штуки (http://llvm.org/devmtg/2015-10/slides/GroffLattner-SILHighLevelIR.pdf), а разработчики Rust - нет.

В итоге уровень поддержки рантайма у них примерно как поддержка у Java и Scala для JVM. Оба языка генерят байткод JVM, но уровень поддержки этих языков внутри JVM - небо и земля. Поэтому Swift - это мейнстрим в списке убивцев С++, а Rust претендует лишь на «не такой как все с хитрыми фичами, медленным компилером и неродным рантаймом».

Apple могла подпортить ситуацию открыв Swift под какой-нибудь анальной лицензией. Но мы имеем Apache + contributions without CLA (у всех контрибуторов права на язык точно такие же как у Apple) - это победа.

anonymous
()
Ответ на: комментарий от umren

но мне очень не нравятся его сигнатуры функций, в Swift они сделаны значительно лучше

Может я куда-то не туда смотрю, но в чём принципиальная разница?

func f(x: Int, y: Int) -> Int
fn f(x: i32, y: i32) -> i32

type inference лучше чем в Rust.

Можно несколько примеров?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Может я куда-то не туда смотрю, но в чём принципиальная разница?

Добавь сюда лайфтаймы, лайфтаймы в структах и прочее, потом сравни.

Можно несколько примеров?

Посмотри объявление сложных или вложенных структур, сравни.

umren ★★★★★
()
Ответ на: комментарий от anonymous

которые пишут LLVM

А оно кроме аппла и FreeBSD применяется где-то? Куда не сунься везде заточка под gcc(mingw)/VS. 90% десктопов - это оффтопик, сервера - онтопик. Что, реально кто-то в здравом уме кинется писать под винду, например, на свифте? тащить ллвм вместе со всем геморроем, если можно взять MSSDK бесплатно и без смс или отточенный и вылизанный годами мингв?

А потом после написания поделки, вдруг, кто-то решит «э, а чоб не взять и не написать ее снова, но на свифте, а?».

так что под оффтопик писать на свифте будут только в том случае, если что-то тащить с макоси будут. а такие случаи достаточно редки, обычно картина обратная. Даже игрульки и те на крестах под iOS пишут, лол.

anonymous
()
Ответ на: комментарий от anonymous

если что-то тащить с макси будут

или с ios.

anonymous
()
Ответ на: комментарий от anonymous

Речь шла о сравнении с Rust, который очень похож на Swift в части использования LLVM.

О самом LLVM - его еще например официальный (не ксамаринный) C# использует под онтопиком.

Про вылизанный мингв - я надеюсь что ты траллируешь. Все большие проекты (Python, Postgres, OpenJDK) плачут, но едят кактус MSVC под оффтопик, потому что мингв - это багодром.

anonymous
()
Ответ на: комментарий от anonymous

А что не так? В Расте тоже есть референс-каунтеры, чеки с большой вероятностью будут elided ниже по стеку (на уровне кодогенерации), в Расте компилер тоже шибко умный и например решает передавать объект по значению или по ссылке.

Разумеется соответствие не 1-в-1, языки то разные, но наркоманства тут не видно.

anonymous
()
Ответ на: комментарий от anonymous

Про вылизанный мингв - я надеюсь что ты траллируешь.

По сравнению в llvm на оффтопике он вылизан. llvm вообще только на никсах и производных нормально работает, да и то кто-то может не согласиться.

Все большие проекты ... Postgres,

Давай ты мне расскажешь больше об этом.

anonymous
()
Ответ на: комментарий от anonymous

В Расте тоже есть референс-каунтеры

Как отдельный тип данных, а не на уровне рантайма.

чеки с большой вероятностью будут elided

Как? Тем более, overflow check?

В Расте компилер тоже шибко умный и например решает передавать объект по значению или по ссылке

Ну так гони пример, я такого не видел.

anonymous
()
Ответ на: комментарий от umren

наверное он намекает, что руст более низкоуровневый и заменяет сишечку.

Именно.

anonymous
()
Ответ на: комментарий от anonymous

А как у свифт с многопоточностью, что актуально в свете новых реалий? В го есть простая и производительная многопоточность, в раст детект race conditions на стадии компиляции, а свифт что?

goingUp ★★★★★
()
Ответ на: комментарий от anonymous

llvm же.

Не понял. Как в си (clang), который на llvm? От языка много зависит.

goingUp ★★★★★
()
Ответ на: комментарий от anonymous

По сравнению в llvm на оффтопике

Эскобар.txt

Давай ты мне расскажешь больше об этом.

Давай, я правда Postgres на офтопике несколько лет не смотрел, неужели они перелезли на мингв? Или ты сомневаешься что Postgres - большой проект?

А про Python и OpenJDK что тебе рассказать? Как в OpenJDK всю сборку VM под оффтопик написали в свое время на NMake и от этого куча проблем? Или что в top-level configure скрипте там оче много логики специально под MSVC и он все равно работает с MSVC через пень-колоду (precompiled headers, ccache и прочие грабли).

anonymous
()
Ответ на: комментарий от anonymous

чеки с большой вероятностью будут elided

Как? Тем более, overflow check?

Computer science в помощь, в JVM вон элайдят даже небо, даже аллаха, значит и в LLVM смогут, рантайм то их собственный, добавить фичу специально для свифта не будет проблемой.

В Расте компилер тоже шибко умный и например решает передавать объект по значению или по ссылке

Ну так гони пример, я такого не видел.

Не пишу на расте, нет готовых сниппетов, читал где то в простынях Клабника на реддите, причем неоднократно.

anonymous
()
Ответ на: комментарий от anonymous

Не пишу на расте, нет готовых сниппетов, читал где то в простынях Клабника на реддите, причем неоднократно.

Я пишу хелворды на расте и читаю Клабника на реддите. Нет там такого.

Короче, на системный язык свифт не тянет -> прямым конкурентом расту не является. Будешь спорить?

anonymous
()
Ответ на: комментарий от umren

Добавь сюда лайфтаймы, лайфтаймы в структах и прочее, потом сравни.

Лайфтаймы - это понятно. А прочее - это что?

Посмотри объявление сложных или вложенных структур, сравни.

Дык, я Swift не знаю, думал у тебя есть примеры. Речь же о выводе типов.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

М, вот это разве не оно: «Rust apparently already uses pass-by-reference behind the scenes for non-floating point, larger than pointer types» (https://internals.rust-lang.org/t/why-do-i-have-to-indicate-pass-by-simple-re...), я в детали описанного не лез, но сложилось впечатление что в некоторых случаях компилер в расте сам решает, как параметры в функцию передать (если это логику кода не меняет).

Про конкурренцию и низкоуровневость - интересно, можешь привести пример чего-то полезного, что легко делается в расте и сложно/никак в свифте, интересно попробовать примеры.

anonymous
()
Ответ на: комментарий от anonymous

можешь привести пример чего-то полезного, что легко делается в расте и сложно/никак в свифте

Ядра ОС и прошивки для микроконтроллеров. Правда, насчёт легко это преувеличение, для МК чувствуется недостаток инфраструктуры, да и компиляется он пока только под ARM, надеюсь, это изменится. Суть в том, что раст позволяет явно контролировать выделение памяти и при желании писать код, юзая только стек. Ну и плюс «тонкий» рантайм.

Rust apparently already uses pass-by-reference behind the scenes for non-floating point, larger than pointer types

И правильно делает. Это простая оптимизация, в бол-ве случаев ускорит код и не требует никаких фич рантайма.

anonymous
()
Ответ на: комментарий от anonymous

но разработчики Swift имеют возможность делать вот такие например штуки (http://llvm.org/devmtg/2015-10/slides/GroffLattner-SILHighLevelIR.pdf), а разработчики Rust - нет.

Это ещё почему? Pазработчики раста свой IR тоже пилят.

Поэтому Swift - это мейнстрим в списке убивцев С++

Мейнстрим - да, убийца С++ - нет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Норм должно быть. llvm же.

Чего? Если брейнфак реализовать на ллвм, то там автоматически станет хорошая многопоточноcть?

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Rust - прямой конкуррент, и проигрывает Swift начисто. Главная причина - над Swift работают люди, которые пишут LLVM, а над Rust - нет.

Ну, если это главная причина, то Swift беспокоиться не о чем.

tailgunner ★★★★★
()
Ответ на: комментарий от mix_mix

Возможно, он имеет в виде нечто подобное: Vec<Rc<RefCell<Box<Trait>>>>

Это к сигнатурам функций или к выводу типов? Претензии ведь к этим вещам были.

Ну и такую фигню на любом языке написать можно. В расте с этим, опять же, бороться можно как и везде - при помощи тайпдефов. Раст тут «хуже» разве что тем, что про вещи типа RefCell приходится задумываться. Впрочем, по ссылке как раз выясняется, что автору достаточно Vec<Box<Trait>>.

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.