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

241–250 of 432 posts

Re: Swift for TensorFlow Shuts Down

#241

Post by cambalache »

SatvikBeri wrote: post #196
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 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.

> you turn off a lot of non-engineering scientific programmers.

I think you mean "non-CS engineers". CS is a minuscule branch of engineering. Plenty of chemical, mechanical, civil (and so on) engineers had their whole education doing maths and programming with 1-indexing.

> I'm a weirdo in that I don't seem to mind either one though.

You are not, as an outsider this is one of the less appealing parts of practical CS, endless bickering about non-substantive issues which most of the time boil down to a matter of personal preference (see also tabs vs spaces, vim vs emacs, react vs vue, golang vs rust and on and on and on...)

Re: Swift for TensorFlow Shuts Down

#242

Post by swagonomixxx »

anon_tor_12345 wrote: post #222
swagonomixxx wrote: post #145

Earlier quoted context omitted.

I'm fairly certain everything you said is possible except for custom CUDA kernels in pure Python. You'd have to write the kernel in C++ and use it in your TensorFlow/PyTorch code. [0][1] [0]: https://www.tensorflow.org/guide/create_op [1]: https://pytorch.org/tutorials/advanced/cpp_extension.html

It is possible https://numba.pydata.org/numba-doc/latest/cuda-reference/ker... which basically calls NVPTX https://github.com/numba/numba/blob/ec6fa07c12c3703a52c2b4ac... which is exactly what CUDA does anyway; CUDA code is actually a frontend for an ISA https://llvm.org/docs/NVPTXUsage.html

Thanks, I wasn't aware this existed!

Re: Swift for TensorFlow Shuts Down

#243

Post by ergocoder »

xenihn wrote: post #187
BadInformatics wrote: post #5

Looks like @throw6606 was right: https://news.ycombinator.com/item?id=24533937 . Does anyone know the status of https://ai.facebook.com/blog/paving-the-way-for-software-20- ...?

Reading that thread, I'm always so confused by HN posters who ask for evidence that would be impossible to provide without self-incriminating. Are they asking disingenuously, or are they just clueless?

They aren't clueless.

This kind of tactics has been used since the beginning of time.

There was no way to produce a hard evidence, and everyone knew that.

Re: Swift for TensorFlow Shuts Down

#244

Post by freedomben »

socialdemocrat wrote: post #240

Back when I was doing a lot of Swift programming, this seemed like such a great idea. Since then I moved on to Julia. And when I looked at the ML code for Swift and compared it to Julia, I was thinking "How on earth could anyone think this was ever a good idea?" Doing machine learning stuff in Julia is simply much more user friendly than doing the same in Swift. Swift is nice for iOS development, but I think in data…

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.

Re: Swift for TensorFlow Shuts Down

#245

Post by ddragon »

renerthr wrote: post #221
Karrot_Kream wrote: post #101

Earlier quoted context omitted.

> In Julia, things are really small and composable. For example, you have a probabilistic programming library like Turing and a differentiable programming one like Flux, and it's trivial to implement some Bayesian neural networks. I was taken aback when looking at Turing for Bayesian modelling that the distributions were just the standard distributions found in the Distributions package! In Python, every Bayesian fra…

> but it all composes in Julia. You mean that, in Julia, we the users have to "compose" our own implementations of models (e.g. log probabilities), as opposed to using the already-made ones in Python?

If they weren't already-made in Julia yes (and a library didn't do the work of composing it and presenting as a monolith, since pretty much all large frameworks like Flux and DiffEq are also made this way). Although you're maybe trying to imply that everything that anyone needs is already made in python, I occasionally end up finding small issues between my use case and what's immediately available and I have to twist my problem into a stitch of "kinda what I need" pieces (like having to change my problem into a vectorization problem, a long chain of corrections using pandas to fit an interface and then some weird logic to transform the table into a CSV in memory to use postgres' COPY or UPSERT because pandas to_sql is not flexible enough and iterating and inserting is too slow). Sure I always achieve the result using already-made stuff, but the glue logic ends up taking more time and honestly ends up quite hard to maintain for other people (or even myself after a few months) after all it isn't my algorithm logic but some adhoc puzzle I just solved.

In Julia, if the DataFrame library is missing something I can just loop like an array and have a method that works just as well as if the library provided it, the CSV, DB and table processing libraries all use the same conventions so if library "A" solves my issue I'm not forced to use the same library "A" serialization method. Basically instead of twisting the logic to what I'm given, I just fill in the blanks. Sure Julia has way more blanks, but Julia also has half of the age of some of the Python's library I use, it's more about the maturity of the community than anything to do with the design choices of the language and I can only hope it gets better and better with time.

Re: Swift for TensorFlow Shuts Down

#246

Post by swagonomixxx »

socialdemocrat wrote: post #223
swagonomixxx wrote: post #181

Earlier quoted context omitted.

> 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 :)

Admittedly it is a bit hard to see why Julia is so different in this area if you have not spent some with it. It took me a bit time as well to see. But there really is a profound difference. The thing is that Python is really just a language to rearrange networks of nodes written in C++. A node written for one ML framework will be incompatible with a node written in another language. If you want them to work together…

> A regular syntax graph of regular Julia code gets manipulated to do autodiff. You are not organizing C++ nodes in a network.

That does sound very different than Python. Admittedly, I haven't used Julia, because I never had to for professional purposes. For personal projects, I use PyTorch, because I find it easy to use, intuitive, and I have a lot of experience with it. Maybe one day I will be forced to use Julia and will appreciate what it brings :)

Re: Swift for TensorFlow Shuts Down

#247

Post by socialdemocrat »

tokipin wrote: post #200

I think people are deceived by Swift's syntax. It looks simple by syntactic sugar, but it's not actually any more approachable than other systems languages like C# or Java. Given that a lot of work in ML is exploratory, it doesn't seem like a good fit compared to a hackable scripting language like Python. I would bet against SwiftUI for similar reasons.

The syntax makes sense in an Objective-C setting because it was matching Smalltalk. It is a very nice syntax for object-oriented programming. But for functional programming it is a terrible syntax, and I think Swift kind of missed the boat on this. I think they should have pushed the replacement to Objective-C into a far more Smalltalk oriented direction as that is what the ecosystem and syntax was really tailored towards.

I do a lot of functional style programming in Julia today, but I also love how Smalltalk works. There is a place for both styles. Swift IMHO is the worst of both worlds. This very OO style syntax mixed in with functional programming makes everything kind of messy. I easily get confused when looking at Swift code for this reason.

When you use anonymous functions, you don't want named arguments. That is an idiotic idea. However if you want to pass a message to a random object, then named arguments is quite nice.

I feel Chris Lattner is not a guy who could really appreciate the Smalltalk heritage of Objective-C.

Re: Swift for TensorFlow Shuts Down

#248

Post by mjcohen »

SatvikBeri wrote: post #196
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 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.

I don't understand why Julia didn't do like Fortran and Ada and allow any starting index. E.g., a(-5:5, 0:3).

Re: Swift for TensorFlow Shuts Down

#249

Post by dnautics »

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 :)

Let's say you write some code that handles numbers differently, say a library that implements quaternion math. For doing graphics manipulations. Then you try to use it with tensorflow maybe for some ai-driven optimization. Is it going to work? Probably not out of the box. You will have to do some munging of quaternion data type to shove them into tensorflow tensors. Do the same thing in Julia with Julia's flux, it probably will, and maybe even with the gpu That's the difference.

Re: Swift for TensorFlow Shuts Down

#250

Post by SatvikBeri »

mjcohen wrote: post #248
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.

I don't understand why Julia didn't do like Fortran and Ada and allow any starting index. E.g., a(-5:5, 0:3).

I mean, Julia is flexible enough that it's pretty easy to implement arrays with different indexing schemes that have the same performance as built-in arrays: https://github.com/JuliaArrays/OffsetArrays.jl
Post reply on HN