Well, this is one more step toward a fully Swift-only platform. Very soon it will not be possible to publish an app on iOS not built with the house language. For those who don’t know, using C/C++ and opengl was easily done on iOS for many years, as llvm/clang was the official compiler.
Happily Swift has interop with C, and they're working on actual C++[1], which would be a lot of wasted effort. The question is very simple: Swift is meant to be a safe language, how feasible is that if a large chunk of the core types and runtime are implemented in C, C++, and Objective-C/C++? Migrating to Swift is the obvious and sensible step, unless you propose re-implementing them in yet another language? [1] http…
Apple is rewriting Foundation in Swift
241–250 of 263 posts
Re: Apple is rewriting Foundation in Swift
#242Earlier quoted context omitted.
I won’t teach Swift here, but Google is your friend. You can start by studying all the languages differences with regards to extending existing protocols, and how optional protocol conformance and methods are handled. Swift in many ways (not just with protocols) is like a fix for many headaches that objc provided in these areas. It’s partly why Apple encourages “protocol oriented” programming in swift over “object or…
Which are basically another way to mix protocols and categories from Objective-C. No need for Google, as mentioned, I know both languages. As for protocols not being encouraged in Objective-C, I migth own the wrong NeXTSTEP manuals.
(as a sibling comment pointed out, swift protocols are typically used for things that in objc you would use inheritance)
Re: Apple is rewriting Foundation in Swift
#243Earlier quoted context omitted.
If they had waited a little bit Rust would have been a great option. That's a shame.
No, that's not possible. Just one example -- In Rust/C++, developer is responsible for managing the memory, while in Java/Swift etc the language does most of the work for you. This alone can fundamentally change many aspects of language design and mean completely different experience for developers
EDIT: wait, I'm reading that swift does not have a garbage collector. I guess I don't see how it differs from Rust then.
EDIT2: ah I see, everything's a smart pointer basically and memory's released at the end (RAII-style), whereas Rust has the borrow checker (but it's still RAII-style). I guess both implement RAII ideas, but Rust seems to do it at compile time and Swift at run time.
Re: Apple is rewriting Foundation in Swift
#244Earlier quoted context omitted.
> And? I was answering a question asking what it was. Are you saying my answer was wrong? > Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. Well that's just false. Firefox has 7.7% marketshare. Brave comes in at less than 1 tenth of a percent. Edge, does better after all it is the _default_ browser on the most popula…
Everyone knew IE was going away. Chrome is not, from what we can see, and is not going away any time soon. If anything, Chrome/Chromium-based browsers are eating other browsers' lunch, just look at the numbers. I absolutely hate Chrome doing their own non-standard things, but you live in a special bubble.
No. That's an exciting fictional world in which you live, and was not the case. Even in the last years preceding Google's chrome release and massive marketing push, when Firefox and Safari were taking "significant" marketshare, it was assumed IE would be forever, and IE-only sites were still common (and the norm in "enterprise" software).
There is literally no difference between a developer that says everyone uses/should use chrome, and a developer a decade ago saying the same thing about IE.
Re: Apple is rewriting Foundation in Swift
#245Earlier quoted context omitted.
Which are basically another way to mix protocols and categories from Objective-C. No need for Google, as mentioned, I know both languages. As for protocols not being encouraged in Objective-C, I migth own the wrong NeXTSTEP manuals.
It does indeed sound like you have some very old documentation. (as a sibling comment pointed out, swift protocols are typically used for things that in objc you would use inheritance)
The kind of documentation that inspired Java authors.
https://cs.gmu.edu/~sean/stuff/java-objc.html
https://en.wikipedia.org/wiki/Portable_Distributed_Objects
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
Re: Apple is rewriting Foundation in Swift
#246Re: Apple is rewriting Foundation in Swift
#247Earlier quoted context omitted.
There was a lot of excitement when it first came out. I tried Swift for Linux, and soon realized it was a meh experience (NS this, NS that... NextStep is still there) and switched back to Rust. It could have been a strong Rust alternative.
That is partly what this article is about - a swift-native set of foundation modules.
Re: Apple is rewriting Foundation in Swift
#248Earlier quoted context omitted.
> it always comes down to type inference on polymorphic types which causes these issues Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times? I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, t…
Fast (and principled) inference for not-too-complicated polymorphic types is an explicit design goal for OCaml and Haskell languages. And this design goal constraint quite a lot the type system. Typically, there are many type system features that break this property and where OCaml and Haskell requires type annotations (for instance polymorphic functions that takes polymorphic functions as arguments and use them in a…
Does the up to 60% figure include programs that make heavy use of GADTs, or are those even worse in terms of the proportion of compilation time spent type checking?
I had no idea Swift's type checking algorithm is exponential. How easy is it to run into those conditions?
Re: Apple is rewriting Foundation in Swift
#249I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want…
While it’s true that the language is really only useful on just Apple platforms, it is still quite an amazing language. I have professionally used about half a dozen languages over the last many years, written hundreds of thousands of lines each in all those languages, and swift is a true breath of fresh air. It checks all the boxes for me, very concise and elegant to write, yet very strictly statically typed. A nice…
Re: Apple is rewriting Foundation in Swift
#250Earlier quoted context omitted.
Apple’s problem has never been the “barrier to entry”. They know developers will make apps for their platform no matter what. If Swift becomes more universal it makes it easier for Apple developers to also develop for Android (etc) which Apple would see as a bad thing.
Wouldn't developers also develop for Android no matter what?