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

191–200 of 432 posts

Re: Swift for TensorFlow Shuts Down

#191

Post by zozbot234 »

skohan wrote: post #173
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…

Language aesthetics do matter. Broadly it seems like we've accepted that "c like" syntax - including brace-delimited blocks and zero-based indexing - should be the norm for programming languages. Any language which goes in a different direction should have a very strong reason to do so, because any deviation will be an obstacle for adoption. I share your frustration with the `end` keyword - it's just needlessly verbo…

snake_case is a lot more readable than CamelCase, which is a huge benefit ergonomically. The keyboard layout is no big deal, one can easily change it or use shortcut-based autocomplete. Rust does use CamelCase for type identifiers, trait identifiers and enum constructors, and the contrast with snake_case also aids readability.

Re: Swift for TensorFlow Shuts Down

#192

Post by aplummer »

ljm wrote: post #147
aplummer wrote: post #89

Earlier quoted context omitted.

To say that Swift is "nowhere near as simple" as Javascript or Kotlin is a very strange opinion to me, and I have experience with all 3. Simple as in syntax, memory management, or in what regard? I can't think of a single example where Swift is not equivalent or better. Do you have the same criticism of Scala?

I do. Scala is insanely complicated once you inherit a codebase full of implicits and custom operators.

If misuse of a language feature is a criticism of the language, I have bad news about javascript.

Re: Swift for TensorFlow Shuts Down

#193

Post by wsmoses »

PartiallyTyped wrote: post #49
xiphias2 wrote: post #40

Earlier quoted context omitted.

While I love using Julia for many things, I prefer having a Python monoculture for AI to be able to mix and match different algorithms. At the end the engine that compiles the mathematical expression to hardware is what matters, and I don't think that LLVM IR that uses is the best IR for the optimizations.

> I prefer having a Python monoculture for AI to be able to mix and match different algorithms. I do not. Unfortunately, high performance and python do not go hand in hand. Yes, I know the heavy lifting is done by C/C++/Rust/Cuda/Blas/Numba and so on, but, when you run simulations for millions of steps, you end up with billions of python function calls. Afaik only Jax actually performs any optimizations because it co…

The name of the LLVM AD tool is actually Enzyme [http://enzyme.mit.edu/] (Zygote is a Julia tool)

Re: Swift for TensorFlow Shuts Down

#194

Post by chc »

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

If you're rewriting everything to get the behavior rather than just hooking together preexisting pieces, that's not what's generally meant by composition.

Re: Swift for TensorFlow Shuts Down

#195

Post by flipgimble »

Another sad lesson why no open source developer should trust Google with their time and effort.

Swift is a gem of a language with an unfortunately Apple-centric ecosystem, but at least you know Apple won't abandon the effort.

Re: Swift for TensorFlow Shuts Down

#196

Post by SatvikBeri »

ZeroCool2u wrote: post #155
nextos wrote: post #60

Earlier quoted context omitted.

I love all languages in the ML/Haskell tradition, but I think Julia would have been a better fit because it's dynamic yet efficient, and because it has a really decent probability/statistics/ML ecosystem already. Long term, I think it's the best replacement we have for Python in the ML world. Python has exceptional libraries but, as a language, it's a bit dated on several fronts. This has an impact on library design.…

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.

Re: Swift for TensorFlow Shuts Down

#197

Post by qaq »

skohan wrote: post #26

It's a shame. I had high hopes at the beginning that S4TF - and the investment in Swift from Google - would help Swift break out of the iOS ghetto and cement it as a mainstream language. Swift's a delightful language to use. It has a lot of the nice things about Rust's type system, but is a heck of a lot easier to use at the expense of a bit of performance. For a lot of use cases, I think this is a great value propos…

I think given how fast the actor concurrency stuff is progressing it should be fairly good platform for web apps in a few years.

Re: Swift for TensorFlow Shuts Down

#199

Post by skohan »

zozbot234 wrote: post #191
skohan wrote: post #173

Earlier quoted context omitted.

Language aesthetics do matter. Broadly it seems like we've accepted that "c like" syntax - including brace-delimited blocks and zero-based indexing - should be the norm for programming languages. Any language which goes in a different direction should have a very strong reason to do so, because any deviation will be an obstacle for adoption. I share your frustration with the `end` keyword - it's just needlessly verbo…

snake_case is a lot more readable than CamelCase, which is a huge benefit ergonomically. The keyboard layout is no big deal, one can easily change it or use shortcut-based autocomplete. Rust does use CamelCase for type identifiers, trait identifiers and enum constructors, and the contrast with snake_case also aids readability.

I disagree that it's "a lot" more readable. I have read a lot of camelCase code in my lifetime, and I can count on zero hands the number of times I ever had an issue parsing code due to the use of camelCase.

Keyboard remapping seems like an extreme solution, and I don't want to train my fingers in such a way that when I sit down at a different workstation that doesn't have my .vimrc I can't type rust anymore.

You don't need snake_case for contrast. You can use lowerCamel and UpperCamel to denote the same levels of significance. SCREAMING_SNAKE is fine for constants because they don't get used all that often, but rust maps the hardest-to-type case to the most-frequently-used, which in my opinion is an ergonomic failure.

Re: Swift for TensorFlow Shuts Down

#200

Post by tokipin »

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.
Post reply on HN