31–40 of 402 posts
I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.) Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.) Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.
Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.
I really should have started using Long Bets years ago. Ten years ago a “Tanya” told me she would never use an ebook to read literature. I’m pretty sure if I went to her house today I’d find 2. In fact I may be the only person I know who doesn’t own one (not wanting one and being fundamentally against them are two different things). That’s the most memorable but I’ve had these sorts of “over my dead body” conversatio…
I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.) Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
> my impression is that the support on Linux within the Foundation is not complete It is not, but it's like 95% of the way there in my experience - most things that are missing are relatively recent additions that have some complex OS interactions, like filesystem I/O with language-level concurrency features. > Does this change imply better (eventual) support on non-Darwin systems? Yes. The non-Darwin Foundation vers…
I'd call that a language feature. Or maybe with Swift there is a blurry line between the two?
me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster?
offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :)
always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end
Earlier quoted context omitted.
Things will get even slower.
Just to explain why Objective C code, in practice, is not especially fast: You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time. Swift makes it easier to eliminate things l…
In my experience, old-school ObjC iOS and Mac apps generally tended to be quite snappy.
On the other hand, the new Swift hotness of Messages and Settings on macOS are noticably slower than what they're replacing.
Of course I haven't done a comprehensive inventory, but I certainly don't have the general impression of things getting faster with Swift. (Are there examples of this?)
My guess is any theoretical gains are generally swamped by the language culture of complex abstractions.
It's probably another big step towards "Swift everywhere," without worrying about bridging to C.
I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im]maturity of the system. This will help with that.
I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.
I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.
I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.
How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.