Hacker News new | past | comments | ask | show | jobs | submit login
Chris Lattner on the Origins of Swift (oleb.net)
120 points by ingve 32 days ago | hide | past | web | favorite | 43 comments



If you want to hear more from Chris re:swift they talk about it on ATP #205 [0] in the only (that I know of) interview they have ever done. It's a good episode and before when I started listening to ATP but they mentioned it in a later episode and I went back to listen to it and it hold up.

[0] http://atp.fm/205


Latter shows up every week in the Swift Community Podcast.


The “only” refers to the hosts of ATP, not to clattner. It is the only interview in the history of ATP.


@50m in they discuss the problems of using Swift on non-iOS platforms. How far is Swift from being a good cross-platform language?


We wrote the Swift Talk backend in it. It’s mostly fine, but some parts are still buggy on Linux. For us, there were two or three bugs that took a few hours each (over the course of a few months of development). Apart from that, I loved Swift on the server: it’s the language I know, so it makes things really fast to build for me. The performance is amazing (both in terms of execution time as well as memory usage).


As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC.

There is some support on GNU/Linux, almost non-existant in other platforms.

However what makes a programming language is not only syntax and semantics, but libraries, IDE, tooling in general, and those are pretty much only available on Apple platforms.

There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.


> As much as Objective-C gets used outside Apple platforms, in spite of 20+ years of support on GCC.

Swift is already more widely used than Objective-C outside of Apple platforms. The main difference is that the Objective-C runtime (which is required to make Objective-C useful in any meaningful way) is closed-source and not available on non-apple platforms. The Swift runtime is available and officially supported on Ubuntu.

> There is nothing like CoreData, CoreAudio, SceneKit, Cocoa,.... outside Apple platforms for Swift.

Most of those examples are proprietary frameworks for interfacing with the Apple platforms directly. Most major platforms include proprietary frameworks, and their existence as value-adds on that platform don't speak to a detriment of the language as a whole. Your statement is like saying C++ is not useful outside of Windows because there is no DirectX.

There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.


> The Swift runtime is available and officially supported on Ubuntu.

Which is actually the only OS outside Apple platforms that has any kind of proper support for Swift.

> Your statement is like saying C++ is not useful outside of Windows because there is no DirectX.

C++ is usefull outside Windows, because it is an ISO standard in no means bound to Windows, with several OS vendors and OEM contributing for multiple implementations of the said standard.

> There is already a large body of open source libraries for Swift for a variety of tasks, and moreover Swift's excellent C interoperability makes it very reasonable to make serious platform-agnostic software with Swift.

Quantity does not mean usefulness.

Great interoperability with C isn't exclusive to Swift, and is also available in languages with a bigger markeshare, with implementations across several OSes.

Swift is great as replacement for Objective-C, improving the safety on Apple's platforms and making FP mainstream on those platforms, as cross platform language it still has quite a lot to improve.


With all due respect, you’re moving the goalposts quite a bit. Your initial statement was that Swift has no community or adoption outside of iOS, and no library support outside of Apple platforms. I never made the claim that Swift is the only language with C interop, or that it’s the best most successful cross platform language, I am simply refuting your claims that it is useless outside the Apple ecosystem.

I agree with you that Swift has a way to go before it can be considered a truly platform agnostic general purpose programming language, but it is making strides in that direction. Recently Windows nightly builds have been introduced, and work has started on Language Server Portocl support, which should aid usability on 3rd part IDE’s. Also it’s somewhat perplexing to me that Swift for Tensorflow is often viewed as a strange move under the assumption that Swift is only for iOS, rather than being viewed in terms of Swift’s adoption for a new category of use-cases with the backing of a tech giant in Google.

It remains to be seen whether Swift will find wide adoption, but I think it’s a mistake to assume it won’t only because of its origins.


The Apple Objective-C runtime is right there on Apple Opensource https://opensource.apple.com/source/objc4/objc4-750.1/


If it is now, that has not always been the case. Also I invite you to build and link the runtime on a non-apple platform and compare that experience to building a working binary with the Swift Package Manager.


You mean Swift packages that depend on macOS and iOS APIs?


No I mean it is relatively painless to build a Swift executable using the package manager on Ubuntu. Doing the same with an Objective-C executable which relies on the runtime is probably several days of work.


It was pretty painless with GNUStep/GCC Objective-C runtime, not that it helped fostering adoption outside NeXT and Apple platforms, since the late 90's.

Naturally GNUStep kind of runned out of steam by Pather, but still.


GNUstep was far from painless. I had the pleasure of trying to use it to port some Objective C code maybe 8 years ago and it was an absolute pain to deal with, not to mention that there were some implementation details which varied from the Apple implementation so your code would not behave consistently between platforms.

Not to mention that it’s very different to have cross platform support as part of the core development process. With a 3rd party implementation like GNUStep,(especially one with a relatively small user base) there is no guarantee that it would keep pace with Apple’s implementation.

Swift is a much smoother, modern experience. I am not saying it is perfect, and other languages have much better support across platforms, but to compare Swift and Objective-C is just not accurate.


It’s not great, but it’s not bad in Linux. In other platforms it’s going to be a pain.


It is curious to me that Swift was chosen as a target language for Tensorflow [1]. It sounds like a really well-designed language but has almost no community outside the iOS platform.

[1] https://www.tensorflow.org/swift


> almost no community outside the iOS platform.

I would not say that's exactly true. There are a number of projects shipping server-side swift, and there is some nice tooling for using Swift where you might otherwise use a scripting language. Personally I reach for it more and more for projects outside of mobile, and find that the non-iOS ecosystem has grown to feel very functional in the past couple years.

iOS is undoubtedly still the main use-case for Swift, but plenty of people are using it for other things.


To the original point, yes, you're right. I see there's a nascent community, still fairly small outside the iOS community but it exists.

But to add to my point... unfortunately, none of those are in the realm of numerical computation or anything remotely connected to the Tensorflow domain.

If a Tensorflow user needed to interact with the ecosystem, it would seem that there's not much in place because the folks currently in the Swift community don't work in those fields, whereas Julia folks do. It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc.

Now that is not to say that with Google's backing, the community won't shift, but that will take time and uptake is uncertain, whereas with Julia that community alignment already exists.

And the Julia community didn't start out being platform-centric, so it has a broader base. I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary.

Again, not to put Swift down. It's just a very curious choice for Tensorflow is all.


> It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc.

Actually I think thst's something which is very strong about the TensorFlow for Swift effort: it allows you to call Python out of the box, so all the Python tooling which is currently available to data scientists is immediately available. It seems the goal of the project is to allow users to immediately take advantage of the convenience of swift (especially the type system) in an incremental way, leaving most of their workflow intact.

They're also already bringing a lot of numerical computing utilities into the language itself. It already has native linear algebraic operators like dot product built in, and automatic differentiation is coming.

> I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary.

So I currently experiment with it using Docker, which you could do on Windows. I know that's not as good as official support, but it is possible.

Anyway, I haven't worked with Julia beyond playing with the REPL a bit, and maybe it would have also been a great choice for TensorFlow. At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language.

I find it very nice to work with and I would be happy to use it in more places where Python is currently the main option. Also the TensorFlow team seems to be doing some very interesting things with it.


Thanks for your thoughts and for the additional info.

> At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language.

I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family.

The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were.

But it's just a feeling. I will leave it at that.


> The community vibe alignment isn't quite there with Swift -- it had no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and depth as it were.

It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic.

To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal.

But that's just my biased opinion.


To use your analogy:

A good saw is spec'ed by a woodworker and made by a metalworker.

A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software.

At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.


> A good saw is spec'ed by a woodworker and made by a metalworker.

So this is what I see in the TensorFlow for Swift project. If you look at the core contributors, you have a team of ML experts, as well as the original creator of the language. It still remains to be seen how it will go, but it seems like the right group of people to go about this effort.

> Python has some really high-quality DS/ML tooling built by people who know software and the problem domain.

See that's where you lose me a bit. There is a lot of really exceptional work done in Python, but in my view that's in spite of the language.

Python strikes me as as a language which has been adopted in the scientific community because it's low barrier to entry makes it approachable to non-expert programmers, but comes up lacking when compared to modern programming languages. Between the version fragmentation, environment management, type system and the nature of runtime errors there are a lot of pain points which are already solved problems in other languages. When I have to work in Python, I am not particularly happy to do so.

Maybe Julia solves these problems. But I also wonder whether the scientific/ML community really knows what they're missing.


Those Swift server side projects, while nice, aren't something that matches up against Spring, JEE, ASP.NET, Yesod, Play, DropWizard, Actix, Revel,....

IBM helps with Kitura, but I am yet to see some real project worthy of news headlines deployed with Kitura.


To be fair, it's still relatively early days. If your test for whether a new technology is useful in a domain is that there is already a large, headline-making example use-case that exists, you will never adopt a new technology because someone has to be the first mover.

The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it. It's inaccurate to say that Swift is only useful for iOS projects.

It remains to be seen whether Swift will find wide adoption, and a lot of that hinges on tooling support which needs a lot of work outside Apple platforms, but I think there is also too much of a tendency in the Software community to under-estimate Swift's potential usefulness as a general-purpose language because of its origins in iOS. I see that frequently in the tepid reaction to Swift for TensorFlow.


> The point is it is possible to deploy serious server-side software written in Swift, and people are already doing it.

Examples that you would care to share with us?

Really serious examples, not the typical blogs and ToDo's done with Kitura I have seen at some conferences.

For me, Tensorflow would be better served with Julia, given the target demographics.

However if it helps Swift ever to be usable on Windows, then more the better.


Well there is one example in this thread.

Also a few links I was able to find with a quick search:

ING is using it:

https://m.youtube.com/watch?v=zJUMr0OkX2M

And also this startup

https://medium.com/@FlorianPfi/lessons-learned-using-server-...

So again not huge examples by any measure, but it’a not nobody.


Thanks for sharing.


There's a pretty solid overview of the decision making process (including pros and cons compared to other options) here: https://github.com/tensorflow/swift/blob/master/docs/WhySwif...


Yes there was an HN discussion on it a few days ago, and this was the final justification:

"In the end, we narrowed the list based on technical merits down to Swift, Rust, C++, and potentially Julia. We next excluded C++ and Rust due to usability concerns, and picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster."

However, the Swift community is larger only because it is used on iOS for non-numerical computation applications completely unrelated to Tensorflow. If we draw the lines of community around people who are in Tensorflow-related fields (i.e. numerical computation), I suspect the size of the Julia community is actually larger than Swift's.

I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined.

The last point is valid though. Still, as someone with a numerical computation background, Swift remains a curious choice.


> I've been a Pythonista for a decade and a half, but in this case, Julia seems to me to be the more logical pick, given that it is designed for numerical computation (it is the modern successor to Fortran). Julia is syntactically closer to Matlab, which is a language familiar to many grad students, a pool from which many future Tensorflow users are mined.

It's an interesting point, but it reminds me of the reasoning Ryan Dahl used to choose Javascript as the language for Node.js: JS had a massive community, and everyone doing web development should have some familiarity with it, so it seemed like a natural choice for that domain. However while it might have aided adoption, the weaknesses of Javascript as a language are undoubtedly the worst part of what is otherwise a useful and well-implemented server-side framework.

I'm not very familiar with Julia, but my impression of Matlab from university is that it was a pragmatic tool which was useful in its domain because of library support, but not that it was a well-designed language that I wish I could use everywhere. If Julia has aped Matlab's conventions because they are familiar to the community, I would worry that it may have also learned from Matlab's bad habits. I would be more trusting of the software engineering community to produce tools which are optimized for usability and creating robust software.


I don't think Julia has aped Matlab's conventions as such [1]. There are languages that have done this (Scilab, Octave) but those were developed as Matlab clones. Julia isn't a Matlab clone.

No, it's more like Julia has taken "Matlab: The Good Parts" as well as practices from modern languages and created a new language with them that is morphologically familiar to Matlab users, yet is an entirely new design.

[1] Except for 1-indexing, but that was a carryover from Fortran, which in turn adopted it from linear algebra convention and it seriously isn't that bad. I wrote production Matlab for 12-years and 1-indexing was the least of my troubles. It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue.


> It's a theoretical polarizing issue like Python's use of whitespace, but in practice it's not an issue.

I think that it really depends on the use case, if you're using only Julia it won't be an issue, if you use Lua as an extension languages of C++ and you have to work on both side at the same time like I had to do.. Well, let's just say that I wasn't exactly having nice thoughts towards Lua creators ..


Yeah that is my worry reading that: interoperability is going to be a headache.


I wouldn't call it solid. On first glance it seems like someone trying to backwards-rationalize an emotional decision.


It makes sense to me... They wanted to solve issues that come from Python, and lots of languages were no-go. They were left with Swift, Rust, or C++. The determination was that C++ and Rust have unacceptable learning curves, so they went with Swift.


IMO the choice of reference counting for memory management means Swift is going to lose out to garbage collected languages for most problem domains. It makes sense for UIKit but not for most backend work.


Could you, at least, provide something to substantiate your opinion? There's ups and downs to both approaches. But you should note that reference counting, for the most part, is handled for you at compile time.


My iOS code is loaded with manual weak ref handling. It’s easy to get wrong. It’s an extra cognitive load and source of bugs. I’d say on pretty much every iOS project I’ve been on there’s been at least one client visible bug caused by forgetting to use a weak ref somewhere.


What would you say is the problem with Reference Counting for back-end work?

Maybe it's because I come from a C/C++ background, but declaring a few weak references here and there never felt like much of a hindrance to me.


On the flipside though:

* You're always thinking of whether you might need to use weak refs, right? That's a cognitive load that you would otherwise be spared.

* What are the consequences when you get it wrong?

* How probable is a mistake, particularly when working with a large complex codebase that you didn't create, and don't fully understand?

* How probable is it that you might fail to detect a mistake, for a long time?


“I’ve seen so many systems where you build a thing and then you try to explain it afterwards.[...] If you can close that feedback loop and include the documentation, include the explaining-it-to-people part into the design process, you get something that’s so much better.”

I’ve really found this to be the case with every app I’ve made. I used to make the app, then start working on marketing, and then realize in trying to frame the app for its target audience that there were a bunch of things I’d want to change in the app. By constantly working on the marketing aspect, you’re able to get those things in early. Launching the initial prototype to a group of trusted testers and then iterating constantly is a really effective way of doing this, at least in my experience.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: