Swift for TensorFlow Canceled

Disclaimer: I'm just an outside observer who's primarily in the .NET ecosystem.

This seemed foreseeable to me. Just like IBM abandoning Kitura, Google abandoned S4TF, for two main reasons I can see:

* Apple itself doesn't particularly care if Swift usage outside their platforms grows. I'm sure they'd like to see it be as popular as possible, but they don't seem very interested in investing in that themselves. Suppose Kitura or Vapor or whatever eventually becomes popular (I've never heard of any website using any of those): then, in turn, that would help Apple as it would flip the calculus of "I already know this language" around. People would go from writing the backend in Swift to, naturally, always wanting to write the frontend in Swift. This would compete nicely with the React Native + NodeJS "we already know JS" or Xamarin Forms + ASP.NET "we already know C#" arguments. Except, we aren't there. Not even close. (As for TF, I would guess Apple cares even less, or might even consider it a threat. They already have Core ML.)

* Google, as someone on Hacker News points out, seems organizationally poor at sustaining projects that aren't big money makers: "Nearly every Google project eventually gets abandoned because the engineers that made it get promoted and move on to their next promotable projects." S4TF existed in part because Chris Lattner worked there (and/or, Lattner wanted to work there in part to port TF to Swift), but he no longer does, and few others care, so it's dead.

And that's just the language or stack. The toolchain also isn't great. Companies like Microsoft or JetBrains so far aren't particularly interested in making a Swift IDE outside of the Mac.

TL;DR: someone needs to get the ball rolling, and Apple doesn't seem to want to be it.

And absolutely nobody was surprised.

It would be bigger news if a Google project went 3 years *without* being canceled.

I believe that Apple wants Swift to remain Apple only: it ensures a supply of captured programmers who do not wish to lose their expertise and investments of time learning Apple's platforms.

It was Chris Lattner who was pushing it. In his quote" There are no reason why you cant have single language that goes from System Level Programming like C to High Level like Javascript"

It was a tall order. And 5 years in so far it seems that decision is just wrong.

Ed: It wasn't *that* tall. That particular feat has been done before, at least a couple times. He's simply picked the wrong language for the job. We know what features and processes and interfaces are required for this goal, and Swift was not designed with them in mind.

I really don't know why he said that. It's not the sort of goal you can accomplish by fiat. He must have been smoking the Haskell kool-aid for too long.

Which languages are you thinking of Ted? Forth and Lisp?

Lattner: “There are no reason why you cant have single language that goes from System Level Programming like C to High Level like Javascript”

Sure, if you start from a Lisp and build all the way up.

Chris Lattner started from C++.

But hey… another day, another Lattner pet project. Good on Google for not fannying about. Rather wish Apple had punted Swift the same way. We’re now on—what—year 5? 10? of the Great Swift Transition, with another 5-10 still to come. None of which puts a dime on Apple’s bottom line nor on any of its App vendors’, while happily writing off the significant asset value of the 30 years of platform they already had. (Not that ObjC didn’t have its own issues, but.)

..

Programmers are very good at creating solutions to problems. Alas, the problem is usually that they’re bored.

@Old: Lisp is an obvious one. Forth, maybe. Objective-C. C++. Extensions of ALGOL and PL/I. More recently, Java and (extensions of) C#.

This all depends on your definition of high-level, but note that all of these (except possibly Forth) were used for applications programming in their day.

Even JS is being used today for tasks which would have been called "systems programming" and meant for C not long ago. Amazon's first web server was in C.

Thanks Ted.

>Lisp is an obvious one. Forth, maybe. Objective-C. C++. Extensions of ALGOL and PL/I. More recently, Java and (extensions of) C#.

Of those, only C++ IMO fits the criteria of *both* significant amount of software built *and* that software exists at the system or embedded level all the way to the front-end / UI level. C itself, too.

Swift could've conceivably been that, though I'm not sure this was a desirable goal. Some of Swift's design, IMO, makes it _less_ appealing for UI development. And at the other end of the spectrum, it doesn't seem as suitable for systems development as Rust.

FWIW, the reason I said is Forth is that one can use it in firmware even before you have DRAM initialised, by using the cache in write-back mode but being careful no actual write back is triggered. That makes it really low level. But one can also build high-level constructs in it, such as those in Haskell or Lisp, although it's strict. Also Forth is so simple that reimplementing it oneself is straight-forward.

At the low end, C++ at the very least requires functioning DRAM: I've never seen it used in firmware. Despite template abuse, it's still pretty low-level. If I hammer on the STL hard enough, I find myself rewriting specialised data-structures for speed. And one ends up with lots of boilerplate. It's kind of high level, but not really. Nothing like Haskell.

I like Rust. But it's a small community maintaining a complex compiler, which could disappear in a decade like so many other languages have. (Lindy effect).

I'm not sure where the requirement that lots of software was built in it comes from. Swift started with no software built in it.

>FWIW, the reason I said is Forth is that one can use it in firmware even before you have DRAM initialised, by using the cache in write-back mode but being careful no actual write back is triggered. That makes it really low level. But one can also build high-level constructs in it, such as those in Haskell or Lisp, although it's strict. Also Forth is so simple that reimplementing it oneself is straight-forward.

I really don't think Lattner was shooting for something as uncommon as Forth, though. (When was the last time you've heard of code written in Forth? One time I can think of is the ol' PowerPC OpenFirmware implementation.)

>At the low end, C++ at the very least requires functioning DRAM: I've never seen it used in firmware.

Right. I gave C++ as the answer only because Ted named it; C (non-++) is certainly not that uncommon both at the firmware level and at the UI level.

On the other end of the spectrum, while prototypes of C# as a systems language exist, actually doing this in production code isn't really a thing.

>I'm not sure where the requirement that lots of software was built in it comes from. Swift started with no software built in it.

It did, but presumably, Lattner would've regarded it as a failure if it had stayed that way. :-)