0,0
рейтинг
3 декабря 2015 в 22:10

Разработка → Apple опубликовала исходный код Swift

image

Язык Swift был представлен сообществу чуть больше года назад, что вызвало достаточно большой резонанс в среде разработчиков, при том не только iOS и OS X.

Но еще больший резонанс вызвал тот факт, что Apple пообещала открыть код компилятора и анонсировала возможность поддержки языка для операционных систем на базе linux.

Сегодня Apple представило исходный код Swift, а также библиотек Foundation, в своем репозитории на github.

Также, был запущен сайт swift.org (который, по понятным причинам, сейчас по большей части не доступен), на котором можно более подробно ознакомиться с языком.

В дополнение к этому, в репозитории Apple на github и на сайте swift.org можно ознакомиться с процессом разработки swift 3 и, возможно, поучаствовать в его совершенствовании.
Александр Гребенщиков @Grebenshikov
карма
41,5
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (55)

  • +19
    Ну вы хотя бы постарались собрать побольше информации.
    — О планах 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
    • 0
      — О том, что они включили всю историю, включая первый коммит 2010 года
      Ага, с копирайтом 2014-2015 гг.
      • –1
        Причем сам Крис Латнер работает в Эппл с сентября 2011 -))
        Видимо даты действительно фальшивые)

        Вот и верь после этого людям ((
        • +2
          А сам он говорит, что с 2005 — http://nondot.org/sabre/ И про то, что к Сфифту подключился в 2010 там тоже есть. Вряд ли он себе ещё и фейковую страничку запилил.
      • +6
        Ага, с копирайтом 2014-2015 гг.

        В комментариях к коммиту имеется возможное объяснение:

        Using git filter-branch (or similar) to run a script across all files and all revisions, to ensure that copyright notices and the like are applied consistently across the project.

        This «breaks» the repository in the sense that object hashes are all going to change, but, since this is the first time this repo's been exposed to external contributors (and their internal repository where Apple actually does work is almost certainly different), that's not that big a deal.
  • +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

    • 0
      Ещё б под винды сделали официальную поддержку. А то странно как-то получается.
  • +3
    Кажется пришла пора наконец попробовать его в деле. Круто, что наконец новое поколение системных языков вылезает из пеленок.
    • –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'
      


      Вероятно в таком контроле типов есть особый дзен, но меня это бесит.
      • +6
        В rust точно также. А особенно хорошо в нём, что нельзя так просто signed и unsigned сравнивать.
        Это все соответствует принципу наименьшего удивления. Лучше уж явно кастануть целое или округлить флота, чем потом удивляться.
        • 0
          Я понимаю, но ведь раздражает же :) Особенно в примере как выше, здесь вполне было бы достаточно явно указать тип результата
          let priceTotal:Float = price*quantity

          чтобы дать компилятору понять, что я знаю что делаю (не пробовал, возможно можно переопределить operator '*' для Int и Float но это уже костыль).
          • 0
            Ну такое может и неплохой компромис, но вообще это несколько снижает единообразие. Тут по видимому и разрабы раста и разрабы свифта одними и теми же научными работами руководствовались. Даже синтаксически они похожи.
          • +2
            А вы какой вариант вычисления хотите сделать автоматическим/неявным в таком, например, случае?
            let priceTotal:Int = (Int) (price * quantity)
            или
            let priceTotal:Int = ((Int) price) * quantity
            да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.
            • +2
              А зачем тут что-то особое придумывать? Существуют правила Type casting из языка «С», которые 20 лет уже существуют, и неоднозначностей там вроде нет.

              Если говорить о частном примере, который я привел выше, то с точки зрения и здравого смысла, и школьного курса математики, все вполне логично: если мы берем некое вещественное число N раз (что эквивалентно умножению), то и результат будет вещественным. Если мы делим вещественное число на целое N, то и результат тоже будет вещественным. Это курс математики за 2й класс.
              • +2
                Если принимать как данное, что в «С» все идеально, то незачем создавать что-то новое. Вопрос «принимать или не принимать» оставим за скобкой.
                Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
                • –2
                  А чем плохо перемножение целого и строки?
                  • +1
                    Я обычно хэшмапы на сокеты делю.
                    • 0
                      Ну в умножении логика более-менее очевидна. Не читая ничего про язык я сразу понял что оно делает и почему используется.
                    • 0
                      Ровно так устроен дефолтный конструктор оператора хвостовой рекурсии в лиспе.
              • 0
                Эти правила в C++ периодически в моих вычислительных экспериментах заставляют меня жалеть, что для конкретного эксперимента я выбрал не хаскель, где вообще никаких приведений нет. Их очень трудно отлаживать.
        • +1
          А в чем проблема сравнивать signed и unsigned, если компилятор знает, что этот аргумент signed, а тот unsigned?
          Да, там код сравнения должен сгенерироваться немного другой чем для двух signed или двух unsigned, но для компилятора-то в чем проблема?
          • 0
            Попробуйте в ObjC
            NSInteger i = -1;
            NSUInteger x = 1;
            NSLog(@"%d", MIN(i, x));
            NSLog(@"%d", MAX(i, x));
            
            • +2
              В C++ тоже странный результат. Но это проблема компилятора, и то что ее до сих пор не пофиксили, можно объяснить лишь тем что разработчики трясутся над обратной совместимостью с терабайтами древнего кода, который никто не будет переписывать:)
              Сравнивать числа разных диапазонов нужно не так, как одного диапазона.
              В частности, выражение
              i < x

              должно превращаться в
              i < 0 || x > INT_MAX || i<x
              .
              Можно вывести общую формулу для чисел любых диапазонов. Имплементировать это в компиляторах элементарно, все типы и диапазоны известны.
  • 0
    Хотелось бы увидеть сравнение производительности с Go.
    • +5
      Можешь спать спокойно, производительность на уровне плюсов, потому что llvm, и сравнивать корректнее с Rust'ом.
      • –2
        Я спокойно сплю, мне интересна фактология и что лучше изучать, поскольку Go пиарят сейчас нещадно все кому не лень.
        • 0
          С точки зрения соотношения производительности и соответствующих рисков у каждого окружения есть свои особенности.
          Я сейчас потиху перебираюсь в 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, и это печалит.
          • 0
            Для веба на swift есть perfect.org
            • 0
              Да, сегодня смотрел.
              Из-за FastCGI есть накладные расходы на коммуникацию и производительность не ахти.
              Выглядит юзабельно, но некоторые вещи морально устарели.
          • 0
            хрен его знает когда она будет стабильной

            Хм, если вопрос только про стабильность, то стабильной она стала начиная с версии 1.0. Ломающих изменений в рамках 1.0 там быть не должно (исключая soundness-фиксы).
          • 0
            > я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности

            С Руби логичней слезать на что-нибудь вроде Crystal github.com/manastech/crystal:
            — синтаксис похож на руби
            — использует LLVM для генерации кода, производительность выше чем у Go
            — легкая интеграция с C библиотеками
            • –1
              Нестабильно.
  • +3
    Отличный подарок к Новому Году.
    Спасибо Apple.
    • –12
      Плохой подарок: ABI и libdispatch отваливается местами, стабильность под Linux'ом стремится к нулю.
      Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.

      Пока юзабельно только для яблок :|
      • +3
        Можете сказать что именно не работает? Мне не понятна фраза «ABI отваливается местами». Можете написать здесь или сразу на swift-users@swift.org.
        • –8
          Есть ошибки в реализации интерфейса с glibc и pthread'ами, под нагрузкой течёт конкретно.
          • +5
            Можно конкретный пример кода?
            • –28
              Нельзя.
              • +9
                Тогда я не могу воспроизвести вашу проблему. У нас в тестах используются pthread, причём под достаточной нагрузкой, что мне кажется, мы бы заметили, если эти тесты текут. Например, один из тестов на модель памяти и атомарные операции github.com/apple/swift/blob/master/validation-test/stdlib/AtomicInt.swift Все тесты проходят как на OS X, так и на Linux.

                Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
                • +3
                  Не хотите написать немного про разработку Swift?) Думаю, тут многим это интересно )
  • 0
    Я немного не понял, если они к Swift 3 всё перепишут, уберут NS и прочее – можно хоронить ObjC?
    • 0
      I don’t think anyone should have to fear for the future of Objective C
      сказал Craig Federighi (Apple’s senior vice president of software)

      А вот когда запилят всё что хотят — вполне возможно, но жить он будет ещё очень и очень долго. Полно проектов, которым переписывать всё на Swift накладно, но проект развивать или хотя бы поддерживать надо.
      • 0
        Спасибо, успокоили.
        • 0
          Ну а в чем будет сложность перейти на swift целиком, когда он подрастет и переболеет детскими болезнями? Совместимость с objC кодом оставят и не придется старый код переделывать, а новый уже на swiftе можно будет писать.
          Не так уж это и сложно — выучить новый ЯП.
          • 0
            Нет, речь не про выучить новый ЯП. Оригинальный вопрос был в стиле «Надо ли переписывать работающие ObjC-проекты на Swift уже сейчас».
  • 0
    Concurrency как фичи языка нет, и в версии 3.0 не планируется. Расходимся.
    • 0
      А это что тогда?
      github.com/apple/swift-corelibs-libdispatch
      • +1
        github.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.
        • –3
          Тогда можно пока учить Rust, после него Swift выглядит как упрощенное подмножество. А уж фреймворки как-то можно освоить в процессе.
          • 0
            А уж фреймворки как-то можно освоить в процессе.

            Изучить синтаксис можно за несколько дней/недель, все остальное — изучение тех самых фреймворков и их подводных камней. Так что соыершенно неясно, чем Rust может помочь в будущем изучении Swift-а.
            • 0
              На самом деле все эти концепции, пришедшие из мира computer science, чуть более базовые, чем подводные камни и баги фреймворков. Скажем так, знание всех особенностей конкретного фреймворка не поднимет тебя на качественно новый уровень. В отличии, скажем, от осознания новых для себя абстракций.
              Скажем так, если ты знаешь, что такое типы суммы или типы произведения, то сможешь их различить и использовать даже в сишком коде. А если просто используешь ключевое слово enum, не задумываясь что это такое, то никогда.
  • 0
    Grebenshikov опубликовало о том, что Apple опубликовало — так себе звучит, да? :)
    • 0
      Даже странно, что никто раньше не написал об этом, поправил
  • 0
    кто хочет поиграться, то есть песочница от ibm swiftlang.ng.bluemix.net/#/repl

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.