FWIW, there is a long and really great blog post that came out today that talks about the shortcomings the Swift language, stdlib, and ecosystem have for numeric programming. It's worth a read if you're interested in this, lots of these problems can be solved with small effort (e.g. improving the libm functions to be generic).
-Chris
This is an excellent post. I would really love to see these problems solved and am happy to see that the post has core team attention! These are some of the shortcomings I would most like to see addressed as well (including moving beyond the Objective-C legacy as much as possible).
(Only commenting on behalf of whether this code can compile) Yes it is.
public var p: MutPtrT {
get {
return UnsafeMutablePointer(mutating: self)
}
}
is the same as
public var p: MutPtrT {
return UnsafeMutablePointer(mutating: self)
}
it's just a get only computed property. (Although I don't see MutPtrT defined anywhere, but I assume there's a typealias somewhere)
but it’s (ab)using the subtyping relationship between UnsafePointer and Array. i always thought it’s assumed that the recipient of the decayed Array pointer isn’t going to hang on to it. UnsafeMutablePointer.init(mutating:) hangs on to it — by returning it
someCFunction(array)
is supposed to be shorthand for
array.withUnsafeBufferPointer
{
return someCFunction($0.baseAddress)
}
Thanks for the link Chris, that was a great (and lengthy!) read.
For those who may be more time-constrained the author of the post describes his first experience with Swift, facilitated by Chris Lattner introducing him to Swift for TensorFlow, and compares the performance of Swift and C for certain numerics tasks.
He also critiques and compares several languages on a variety of aspects, concluding that overall Swift may be the best compromise he has seen between performance and usability.
The major deficiencies he identifies in Swift primarily revolve around its ecosystem. He calls out the Swift Package Manager as woefully insufficient, lambastes the Foundation framework for (among other things) behaving differently on Mac and Linux, and laments the lack of support for interfacing directly with C++.
His ultimate conclusion is, “Overall, the Swift language itself looks to be exactly what we need, but much of the ecosystem needs to be replaced or at least dramatically leveled-up.”
@taylorswift I’m fairly certain you’re right and that’s undefined behaviour, but it will happen to work provided the array is given no reason to modify/reallocate its underlying storage and there are live references to it. Using withUnsafeBufferPointer would be a much better idea, though.
For instance, Swift’s standard library doesn’t provide a builtin way to format floats with fixed precision
would it be worth a proposal to get this into the standard library? i’ve been asking for this for ages now
Perhaps as some form of formatted String Interpolation? I feel it’d strengthen the use of formatting a lot more compared to other places.
It is legal (in that it parses) but invalid code, because it doesn't guarantee the lifetime of the array.
I'd love to see the issues with the numerics APIs (sqrt etc) sorted out, would love to see some of the basic API issues sorted out (e.g. @taylorswift's comment up thread) and would love to know what people think about Conda for Swift.
That was a great read and really hits on some core issues. Thanks to Jeremy Howard for putting the time in to write it!
It did make me pause when he mentioned that the community wasn't great, but after reading further and seeing his reasoning behind the comment I can totally see where he is coming from. We are quite blinkered as a community and concentrate primarily on iOS/macOS with a limited influence from people outside this ecosystem and I think that does need to change. Its not really our fault as Swift was originally introduced as a language for the iOS/macOS ecosystem so it naturally went that way, but moving into other platforms it would make sense to broaden our understanding of what else is out there and how we can improve the usability of swift on those other platforms. I do worry that this may never get the required push it needs due to Swift needing to primarily facilitate the iOS/macOS platforms, but I guess time will tell.
Personally I would love to see the numerical enhancements to swift, but I think I saw somewhere before that it was recommended to break it out into a separate Math library (this was a while ago so I could be wrong). What is the recommendation here, and would this be something that Apple would be able to facilitate supporting as an official support library?
I know @xwu has a Numerical Annex library.
I’ve written some pure-Swift linear algebra types (Matrix, Vector, etc.) for personal use, but I didn’t optimize them for speed.
Presumably a general-purpose Swift math library would leverage Apple’s Accelerate framework on the Mac, though I’m not sure what the equivalent is for other platforms. Probably something built around FFTW.
I, for one, would be interested in helping to develop and implement such a library, when the time comes.
I'm not sure if he's able to comment but @scanon is a renowned numerics expert involved with Swift development.
Jeremy has a new post about random distributions which may be interesting to folks on this thread.
I would go a bit further and point out that we're, at least by reputation, so focused on iOS development that he apparently didn't even realize that Swift has run on macOS since its initial release: "But wait, isn’t Swift just what iOS programmers use for building apps? Not any more! Nowadays Swift runs on Linux and Mac [...]" (emphasis mine).
At least as best as I can recall, most of the stuff that's been done to make Swift work better on iOS/macOS can be roughly summed up as "making the C/Obj-C interop layer better". Obj-C interop could reasonably be viewed as catering to iOS/macOS, but C is pretty universal. Is this the time start thinking about how to interop with C++?
As a special-case thing like the string(: Int) -> String function Jeremy showed or as a general solution for printing objects without their default formatting?
I haven't used Conda. Are it and SPM complimentary, or would we just be setting ourselves up for a package manager war?
While I would love to see some C++ interop in the future its not a small task and will take a lot of work to get there. We are getting closer to being able to start those discussions with ABI stability in Swift 5 being one massive milestone towards that, but I also feel like there are certain things that are higher priority like the ownership model and getting generics completed, plus other bits and pieces like filling in the holes in the standard library.
It will be interesting to hear what the core team's priorities are for Swift 6, but it's too early to start talking about that when Swift 5 is still in active development. I do think that posts like Jeremys are useful to highlight areas of concerns outside of the the standard Apple ecosystem though. Smoothing out those areas of concerns will help forge the direction of the language so that it becomes more and more useful outside of our little bubble.
Personally I can't wait for the day where we have the ownership model in place and can compile Swift to Wasm, but I think I might be waiting a few more years for that 
Since we're talking Math library again, I'd add to Jeremy's perspective that a Math library should also have,
I played around with these ideas in the MathTypes library here, but there are several friction points in Swift that make this difficult. Check out the readme.md there for a slightly more complete summary.
The scientific community that I'm involved in is rapidly moving from Matlab to Python, and not just for data analysis. Despite the performance issues with python, there are now lots of numerical models and modeling frameworks, e.g., project dedalus, that will probably continue to help shift that community toward python because performance is good enough.
I would love to see a Math framework on Swift (and help shift momentum), but I think it will take putting together people from a number of different communities to really make a good library/environment. To echo some of Jeremey's concern, the current community built up around Swift is (understandably) pretty narrowly focused on app development, etc. I think the real challenge here is going to be getting help from these other communities before Swift is actually useful in those communities.
Many of these issues with Swift can be worked around by adding support for direct interop with C++. Some might argue the idea that not having direct interop support for C++ will accelerate the equivalent native replacements to be implemented in Swift. But in practice I haven't seen that, and Swift has been around for almost 5 years.
Again as I have discussed previously, if I use the history of Objective-C as a basis for determining if these shortcomings will ever be addressed, the answer is no. There are many shortcomings with Objective-C that were never solved in the 17 years of its lifetime between 1984 and 2001 before Objective-C added support for direct interop with C++ and thereafter became known as Objective-C++.
The history is significant here as these languages are both developed by the same company. The same culture applies, the same priorities. Maybe even a few of the same developers are working on Swift that worked on Objective-C. Taking a lesson from history I argue the focus should be on adding support in Swift for direct interop with C++, hopefully before Swift turns 17 years old. I am somewhat lamenting my C++ skills in the interim.
I greatly look forward to whatever gaps that can be closed, not as 3rd party libraries, but as what is directly integrated into the Swift standard core and 1st party Swift standard library. I agree I think Swift is the answer even with its current limitations.
This is (to me) a strange perspective, since C++ is not a great numerical programming language. It's been slowly improving in recent years, but historically it hasn't really been the focus of the language at all.
My experience is that in as much as Obj-C didn't "solve" these problems it's because they were either already solved in C (and hence already solved in Obj-C by simply using C) or the broader C-family language community still hasn't really solved them, but Obj-C had reasonable interoperability with Fortran (at least on the mac) which did, so there was no real push to do more.