Swift for TensorFlow Shuts Down

Post by pjmlp » Sat, Feb 13, 2021, 8:35 AM UTC

raydev wrote: post #82

ChrisMarshallNY wrote: post #64

Earlier quoted context omitted.

I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both). I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems. That said, I have not done system programming for a…

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

Post by pjmlp » Sat, Feb 13, 2021, 8:40 AM UTC

geoffpado wrote: post #72

grey-area wrote: post #45

Earlier quoted context omitted.

Don't worry, in a few years Apple will rewrite all their SDKs again in a different language. The churn may not be a deliberate strategy but it is certainly very effective in locking developers in.

Apple churns languages every few years? They kept Objective-C around for 13 years before introducing Swift, and that was a language that was widely disliked by people from outside the Apple ecosystem. You can still use it for the vast majority of OS features today[0], nearly 20 years after it was first used on Apple platforms. Heck, Obj-C is used for Mac/iOS development because that was the preferred language for Mac…

Post by pjmlp » Sat, Feb 13, 2021, 8:50 AM UTC

sanderjd wrote: post #305

johnnycerberus wrote: post #276

Earlier quoted context omitted.

You can't be serious. Rust would just replace C++ in the current formula, you can't use Rust as if it was Python. ML people don't need to waste time proving memory properties at compile time, cmon! Indeed, there were alternatives. Two already come to my mind, one is Scala (which syntax-wise is strikingly similar to Python) and Julia. Both having features like type-safety, macros, JIT, FFIs, etc.

None of this is less true for swift. The whole idea is that there may be an advantage to better static analysis that overcomes the perceived downside of using a language with a strict compiler and lots of rules. That idea may or may not be worthwhile, but it is equally applicable to swift and rust. Julia I agree but Scala strikes me as a bit of a non sequitur. It is much more complex and foot-gunny (and thus difficul…

Post by viktorcode » Sat, Feb 13, 2021, 9:30 AM UTC

sida wrote: post #316

freedomben wrote: post #244

Earlier quoted context omitted.

Julia is fascinating to me, and I don't do any ML (currently). Julia seems like such a well designed language. I'm excited to see where it goes.

As weird as it sounds, the only thing that stops me from trying Julia is 1 indexing

Post by pjmlp » Sat, Feb 13, 2021, 9:39 AM UTC

uryga wrote: post #253

mumblemumble wrote: post #109

Earlier quoted context omitted.

> the fact that they are completely ignored by the standard implementation. They're glorified comments. Not quite. You can reflect on and interact with them at run-time, too. This does make it possible to implement run-time checking as a library solution. I can't speak to why run-time checking wasn't built into the language as a default behavior, and the PEP doesn't explain why (though perhaps the answer is in the ma…

> I can't speak to why run-time checking wasn't built into the language as a default behavior tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful --- there's a bunch of libraries that do this, and they're all fundamentally limited [though i guess some of these may just be failures of imagination on my part]: - hard to check ge…