Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

Post reply on HN
Print view View original

251–260 of 432 posts

Re: Swift for TensorFlow Shuts Down

#251

Post by oivey »

selectodude wrote: post #146
amkkma wrote: post #129

Earlier quoted context omitted.

>there's nothing stopping you from composing things in Python. In Julia you can compose a custom distribution, with a bayesian model with an ODE with a neural network with unit number types with custom Julia written CUDA kernels and multithreading. Edit: That are not designed specifically to work with each other Can python even hope to do a fraction of that, still be fast and differentiate through everything?

The outcome is more important than the code. While that sounds very elegant, what does it actually add?

From the point of view of a DL researcher, you’re able to easily implement your own custom layers. From the point of view of a framework developer, you get much faster development time. From the point of a more normal user, you hopefully get more features faster because the jobs of the framework developer and DL researcher have been made easier.

Re: Swift for TensorFlow Shuts Down

#252

Post by eigenspace »

socialdemocrat wrote: post #232
ZeroCool2u wrote: post #155

Earlier quoted context omitted.

function julia_blues(bummers...) I largely agree, Julia is such a cool language and had so much potential. It definitely surprised me when they went with Swift instead, but realizing that Chris Lattner worked at Google at the time explained a lot. Unfortunately, every time I try to get into Julia, it just feels awkward coming from Python and a bit like stepping back in time. The stupidest, (stupidest in the sense tha…

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for othe…

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of in static languages.

Re: Swift for TensorFlow Shuts Down

#253

Post by uryga »

mumblemumble wrote: post #109
simias wrote: post #70

Earlier quoted context omitted.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

> 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 generics: if it's a builtin, you have to traverse the whole structure and check every element. and for user-defined collections, the programmer has to to manually instantiate every generic like:

  CoolSequence[int]([1,2,3])
(which sucks) and every method call/property access needs to be checked

- if your function takes a callback, there's no way to typecheck that callback at runtime (without calling it, at which point it's not terribly useful. which extends to all functions i guess)

- not much you can do with iterators/generators. can't check if something really is an `Iterator[int]` without exhausting it, and e.g. type-erroring after processing 20 elements because it yielded not-an-int isn't very useful

so in the end, even if you wrap Every Damn Thing in a type assertion, you still get the errors very late, not much sooner than your usual "AttributeError: object None has no property named 'foobar'". kind of a worst-of-both-worlds situation

Re: Swift for TensorFlow Shuts Down

#254

Post by FridgeSeal »

skohan wrote: post #202
SatvikBeri wrote: post #196

Earlier quoted context omitted.

I love Julia in general, but yeah, I hate `end`. Re: 0-indexing vs 1-indexing. If you use 0-indexing, you turn off a lot of non-engineering scientific programmers. My personal experience is that 0-indexing is better for more engineering applications, while 1-indexing is better for math. I'm a weirdo in that I don't seem to mind either one though.

Is there an example of where 1 is better for math, or is it just a familiarity thing?

Zero based indexing came from early requirements to address things in arrays using offsets.

Subsequent languages don’t have this issue, and when you think about it, it causes a weird disconnect: 1-based indexing corresponds exactly with how you think about and see elements in a collection. 0 based indexing-despite how comfortable one gets with it requires additional arithmetic.

It’s a relic from the past, and unless you’re doing the very specific thing of indexing via offset instead of position, there’s no reason to hang onto this anachronism.

Re: Swift for TensorFlow Shuts Down

#256

Post by rezahussain »

chrisaiv wrote: post #96

Is if safe to assume that this is the main driver for this event? https://www.businessinsider.com/chris-lattner-former-apple-g...

I think its the issues they are seeing here https://forums.swift.org/t/differentiable-programming-for-gr...

Until the video of the last meeting is posted im guessing maybe its bc the execs set a deadline and it got passed

Re: Swift for TensorFlow Shuts Down

#257

Post by [deleted] »

lostmsu wrote: post #206
cs702 wrote: post #119

S4TF lost out, not to Python, but to Python's AI/ML ecosystem -- people, projects, libraries, frameworks. Despite its many shortcomings, Python has become the lingua franca of AI and ML, to the point that whenever I come across a newly published AI or ML paper that I find interesting, I expect to be able to find code implementing it in Python. For example, yesterday I saw a post on HN about approximating self-attenti…

Nystromformer attention layer is actually pretty simple. You can reimplement it in a few minutes.

[deleted]

Re: Swift for TensorFlow Shuts Down

#258

Post by lostmsu »

cs702 wrote: post #211
lostmsu wrote: post #206

Earlier quoted context omitted.

Nystromformer attention layer is actually pretty simple. You can reimplement it in a few minutes.

Sure, but isn't it nice that you don't even have to read the paper to play with the full model, to see if the claims hold up, using the same Python tools you and everyone else uses?

Fair, but I would not call that "ecosystem".

Re: Swift for TensorFlow Shuts Down

#259

Post by coldtea »

swagonomixxx wrote: post #181
amkkma wrote: post #161

Earlier quoted context omitted.

It's definitely not possible. These have to be rewritten with the specific autodiff /ML framework in mind. Even then, you're not going to have fast custom types to be used on the GPU without dropping into C++

> It's definitely not possible. These have to be rewritten with the specific autodiff /ML framework in mind. I don't understand why it's not possible. You're asking if it's possible in the language. I don't see anything stopping you from, as you say, writing your own framework, or simply doing it in TF. Perhaps my ignorance of Julia is showing :)

>I don't understand why it's not possible. You're asking if it's possible in the language. I don't see anything stopping you from, as you say, writing your own framework, or simply doing it in TF. Perhaps my ignorance of Julia is showing :)

It's not that it's not possible. Yeah, you could always "write your own framework".

It's that it's not readily available by the language, ready-made to compose, without resorting to external libs on C/C++/Fortran, and so on.

So, "not possible" not in the sense that "it's not possible to write a program that solves the halting problem". More like "it's not possible to write a web app in assembly". Which means, yeah, it's possible, technically, but you wouldn't like it, it would be full of holes, a pain to maintain, and not a good time investment.

Re: Swift for TensorFlow Shuts Down

#260

Post by jiofih »

mrtksn wrote: post #177
jiofih wrote: post #168

Earlier quoted context omitted.

Swift and UIKit are already a much larger API than any node framework in existence.

They have good defaults and Xcode is a good IDE with full support of these frameworks, Swift is a good language with sensible conventions so you don't really need to learn that much. When you don't know something you can start typing keywords and see what Xcode autocompletes for and read the explanation about that function from the documentation that is provided to you right there. It's not perfect, sometimes there's…

You get the same with JavaScript if you use any mainstream editor with TS support (you don’t need to be using TS yourself).
Post reply on HN