Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Ну вы хотя бы постарались собрать побольше информации.
— О планах 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
— О планах 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
— О том, что они включили всю историю, включая первый коммит 2010 годаАга, с копирайтом 2014-2015 гг.
Ага, с копирайтом 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.
Кажется пришла пора наконец попробовать его в деле. Круто, что наконец новое поколение системных языков вылезает из пеленок.
Попробуйте, будете удивлены. Этот *** язык не может сам даже 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'
Вероятно в таком контроле типов есть особый дзен, но меня это бесит.
В rust точно также. А особенно хорошо в нём, что нельзя так просто signed и unsigned сравнивать.
Это все соответствует принципу наименьшего удивления. Лучше уж явно кастануть целое или округлить флота, чем потом удивляться.
Это все соответствует принципу наименьшего удивления. Лучше уж явно кастануть целое или округлить флота, чем потом удивляться.
Я понимаю, но ведь раздражает же :) Особенно в примере как выше, здесь вполне было бы достаточно явно указать тип результата
let priceTotal:Float = price*quantity
чтобы дать компилятору понять, что я знаю что делаю (не пробовал, возможно можно переопределить operator '*' для Int и Float но это уже костыль).
let priceTotal:Float = price*quantity
чтобы дать компилятору понять, что я знаю что делаю (не пробовал, возможно можно переопределить operator '*' для Int и Float но это уже костыль).
Ну такое может и неплохой компромис, но вообще это несколько снижает единообразие. Тут по видимому и разрабы раста и разрабы свифта одними и теми же научными работами руководствовались. Даже синтаксически они похожи.
А вы какой вариант вычисления хотите сделать автоматическим/неявным в таком, например, случае?
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.
А зачем тут что-то особое придумывать? Существуют правила Type casting из языка «С», которые 20 лет уже существуют, и неоднозначностей там вроде нет.
Если говорить о частном примере, который я привел выше, то с точки зрения и здравого смысла, и школьного курса математики, все вполне логично: если мы берем некое вещественное число N раз (что эквивалентно умножению), то и результат будет вещественным. Если мы делим вещественное число на целое N, то и результат тоже будет вещественным. Это курс математики за 2й класс.
Если говорить о частном примере, который я привел выше, то с точки зрения и здравого смысла, и школьного курса математики, все вполне логично: если мы берем некое вещественное число N раз (что эквивалентно умножению), то и результат будет вещественным. Если мы делим вещественное число на целое N, то и результат тоже будет вещественным. Это курс математики за 2й класс.
Если принимать как данное, что в «С» все идеально, то незачем создавать что-то новое. Вопрос «принимать или не принимать» оставим за скобкой.
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
А в чем проблема сравнивать signed и unsigned, если компилятор знает, что этот аргумент signed, а тот unsigned?
Да, там код сравнения должен сгенерироваться немного другой чем для двух signed или двух unsigned, но для компилятора-то в чем проблема?
Да, там код сравнения должен сгенерироваться немного другой чем для двух signed или двух unsigned, но для компилятора-то в чем проблема?
Попробуйте в ObjC
NSInteger i = -1;
NSUInteger x = 1;
NSLog(@"%d", MIN(i, x));
NSLog(@"%d", MAX(i, x));
В C++ тоже странный результат. Но это проблема компилятора, и то что ее до сих пор не пофиксили, можно объяснить лишь тем что разработчики трясутся над обратной совместимостью с терабайтами древнего кода, который никто не будет переписывать:)
Сравнивать числа разных диапазонов нужно не так, как одного диапазона.
В частности, выражение
должно превращаться в
Можно вывести общую формулу для чисел любых диапазонов. Имплементировать это в компиляторах элементарно, все типы и диапазоны известны.
Сравнивать числа разных диапазонов нужно не так, как одного диапазона.
В частности, выражение
i < xдолжно превращаться в
i < 0 || x > INT_MAX || i<xМожно вывести общую формулу для чисел любых диапазонов. Имплементировать это в компиляторах элементарно, все типы и диапазоны известны.
Можешь спать спокойно, производительность на уровне плюсов, потому что llvm, и сравнивать корректнее с Rust'ом.
С точки зрения соотношения производительности и соответствующих рисков у каждого окружения есть свои особенности.
Я сейчас потиху перебираюсь в 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, и это печалит.
Я сейчас потиху перебираюсь в 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, и это печалит.
Для веба на swift есть perfect.org
хрен его знает когда она будет стабильной
Хм, если вопрос только про стабильность, то стабильной она стала начиная с версии 1.0. Ломающих изменений в рамках 1.0 там быть не должно (исключая soundness-фиксы).
> я видел over 100500 которые слазили с node/ruby/python/php на golang из-за его производительности
С Руби логичней слезать на что-нибудь вроде Crystal github.com/manastech/crystal:
— синтаксис похож на руби
— использует LLVM для генерации кода, производительность выше чем у Go
— легкая интеграция с C библиотеками
С Руби логичней слезать на что-нибудь вроде Crystal github.com/manastech/crystal:
— синтаксис похож на руби
— использует LLVM для генерации кода, производительность выше чем у Go
— легкая интеграция с C библиотеками
Отличный подарок к Новому Году.
Спасибо Apple.
Спасибо Apple.
Плохой подарок: ABI и libdispatch отваливается местами, стабильность под Linux'ом стремится к нулю.
Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.
Пока юзабельно только для яблок :|
Пока будут переписывать стандартную библиотеку, чинить всё… в надежде что хомячков набежит за яблочками, но, как оказалось, хомячкам их придётся самостоятельно спавнить, что собственно не тортъ, и качество яблок канет в лету.
Пока юзабельно только для яблок :|
Можете сказать что именно не работает? Мне не понятна фраза «ABI отваливается местами». Можете написать здесь или сразу на swift-users@swift.org.
Есть ошибки в реализации интерфейса с glibc и pthread'ами, под нагрузкой течёт конкретно.
Можно конкретный пример кода?
Нельзя.
Тогда я не могу воспроизвести вашу проблему. У нас в тестах используются pthread, причём под достаточной нагрузкой, что мне кажется, мы бы заметили, если эти тесты текут. Например, один из тестов на модель памяти и атомарные операции github.com/apple/swift/blob/master/validation-test/stdlib/AtomicInt.swift Все тесты проходят как на OS X, так и на Linux.
Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
Если сможете, запостите, пожалуйста, нам в баг-трекер код, который течёт.
Я немного не понял, если они к Swift 3 всё перепишут, уберут NS и прочее – можно хоронить ObjC?
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 накладно, но проект развивать или хотя бы поддерживать надо.
Concurrency как фичи языка нет, и в версии 3.0 не планируется. Расходимся.
А это что тогда?
github.com/apple/swift-corelibs-libdispatch
github.com/apple/swift-corelibs-libdispatch
github.com/apple/swift-corelibs-libdispatch
github.com/apple/swift-evolution/blob/master/README.md
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.
Тогда можно пока учить Rust, после него Swift выглядит как упрощенное подмножество. А уж фреймворки как-то можно освоить в процессе.
А уж фреймворки как-то можно освоить в процессе.
Изучить синтаксис можно за несколько дней/недель, все остальное — изучение тех самых фреймворков и их подводных камней. Так что соыершенно неясно, чем Rust может помочь в будущем изучении Swift-а.
На самом деле все эти концепции, пришедшие из мира computer science, чуть более базовые, чем подводные камни и баги фреймворков. Скажем так, знание всех особенностей конкретного фреймворка не поднимет тебя на качественно новый уровень. В отличии, скажем, от осознания новых для себя абстракций.
Скажем так, если ты знаешь, что такое типы суммы или типы произведения, то сможешь их различить и использовать даже в сишком коде. А если просто используешь ключевое слово enum, не задумываясь что это такое, то никогда.
Скажем так, если ты знаешь, что такое типы суммы или типы произведения, то сможешь их различить и использовать даже в сишком коде. А если просто используешь ключевое слово enum, не задумываясь что это такое, то никогда.
Grebenshikov опубликовало о том, что Apple опубликовало — так себе звучит, да? :)
кто хочет поиграться, то есть песочница от ibm swiftlang.ng.bluemix.net/#/repl
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apple опубликовала исходный код Swift