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

361–370 of 432 posts

Re: Swift for TensorFlow Shuts Down

#361

Post by stadia42 »

My reading of the discussion at https://forums.swift.org/t/swift-concurrency-roadmap/41611: the Google Swift team members expressed hope for a bit more community involvement in the Swift language planning, and Apple folks very politely told them to shove it where the sun don't shine.

My guess: Google concluded that investing in a language developed behind closed doors of another company is a bad deal.

I don't blame Apple, it may be a good business decision for them, and of course it is completely within their rights.

Re: Swift for TensorFlow Shuts Down

#362

Post by improbable22 »

ZephyrBlu wrote: post #346
adgjlsfhk1 wrote: post #321

Earlier quoted context omitted.

IMO, Julia is good enough that you might not notice. you can use constructions like `for i in axes(V)` that will automatically give you the indexes, or `V[begin:begin+2]` to get the first 2 elements. Also higher order functions eg. `map` (and broadcasting) mean that you will rarely be manually working with indexes.

You still need to access indexes if you're working with arrays though, which is a very common data structure.

That's not so obvious, the abstractions for multi-dimensional indexing are better than (I think) you're imagining.

Here's a nice recent example: a new reverse!(A; dims) function, which is fast and works on arrays with any number of dimensions. And is completely indifferent to where the indices start:

https://github.com/JuliaLang/julia/pull/37367/files#diff-eb9...

Re: Swift for TensorFlow Shuts Down

#363

Post by ZephyrBlu »

improbable22 wrote: post #362
ZephyrBlu wrote: post #346

Earlier quoted context omitted.

You still need to access indexes if you're working with arrays though, which is a very common data structure.

That's not so obvious, the abstractions for multi-dimensional indexing are better than (I think) you're imagining. Here's a nice recent example: a new reverse!(A; dims) function, which is fast and works on arrays with any number of dimensions. And is completely indifferent to where the indices start: https://github.com/JuliaLang/julia/pull/37367/files#diff-eb9...

I'm not 100% sure what I'm looking at, but that seems to be related to reversing arrays/matrices, not accessing arrays through indexes.

Re: Swift for TensorFlow Shuts Down

#364

Post by [deleted] »

gurkendoktor wrote: post #356
mrtksn wrote: post #175

Earlier quoted context omitted.

I used to work with web technologies but I got overwhelmed with the complexity of the tooling. For example, TypeScript is nice but it's not a "real" language in a sense that you can write something in it and expect it to work when it's fed into the compiler or interpreter. To use it, you need to set up an environment where all the moving parts are working in harmony and the code you write in Typescript is transcribed…

I agree about TypeScript, however this paragraph also describes Swift to a T: > Sometime you have a library where someone a few years back tried to do something similar to your idea but never had a complete solution and stopped working on it and when you try to benefit from this work to build on top of it, you find out that you need to modify you working environment to support some spacial case of legacy code. You do…

[deleted]

Re: Swift for TensorFlow Shuts Down

#365

Post by improbable22 »

ZephyrBlu wrote: post #363
improbable22 wrote: post #362

Earlier quoted context omitted.

That's not so obvious, the abstractions for multi-dimensional indexing are better than (I think) you're imagining. Here's a nice recent example: a new reverse!(A; dims) function, which is fast and works on arrays with any number of dimensions. And is completely indifferent to where the indices start: https://github.com/JuliaLang/julia/pull/37367/files#diff-eb9...

I'm not 100% sure what I'm looking at, but that seems to be related to reversing arrays/matrices, not accessing arrays through indexes.

Maybe less readable than I remembered, sorry! But these `CartesianIndex` things are how you index multi-dimensional arrays.

If by indexing you only mean adding offsets to pointers with your bare hands, this is possible but discouraged. Because you'll produce a buggier and less general version of exactly what already exists. In this case, reversing an N-dimensional array, along any M of its axes, with arbitrary offsets -- there are a lot of ways to get that wrong.

Re: Swift for TensorFlow Shuts Down

#366

Post by mirekrusin »

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

They key concept that allows for this high degree of composability is multiple dispatch; it’s like if you were able to define trait for any function on any parameter type or to overwrite any existing function to specialise/generalise on one or more parameter types. Ie instead of wrapping different libraries to glue them together to work on your data, you update existing functions to accept your data, ie you blend your thing into existing things instead of wrapping. And once blended your data works not only with that library but also with libraries that use this library without extra effort and with very terse final code.

Re: Swift for TensorFlow Shuts Down

#367

Post by ZephyrBlu »

improbable22 wrote: post #365
ZephyrBlu wrote: post #363

Earlier quoted context omitted.

I'm not 100% sure what I'm looking at, but that seems to be related to reversing arrays/matrices, not accessing arrays through indexes.

Maybe less readable than I remembered, sorry! But these `CartesianIndex` things are how you index multi-dimensional arrays. If by indexing you only mean adding offsets to pointers with your bare hands, this is possible but discouraged. Because you'll produce a buggier and less general version of exactly what already exists. In this case, reversing an N-dimensional array, along any M of its axes, with arbitrary offset…

What I mean is something like this:

    # one dimensional
    a = [1, 2, 3]
    # prints the number 1 @ index 0
    print(a[0])
    
    # multi-dimensional
    b = [[1, 2, 3], [4, 5, 6]]
    # prints the number 4 @ index (1, 0)
    print(b[1][0])
In Julia these indexes would start from 1. It doesn't seem like `CartesianIndex` solves this, since looking at some examples you still have to specify array indexes (Which start from 1): https://docs.julialang.org/en/v1/base/arrays/#Base.Iterators...

Re: Swift for TensorFlow Shuts Down

#368

Post by sanderjd »

pjmlp wrote: post #335
sanderjd wrote: post #305

Earlier quoted context omitted.

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…

Scala already has a foothold on the same research domain due to large data frameworks like Hadoop and Spark, with NVidia caring for polyglot support on CUDA, including JVM based languages.

That is true, and certainly relevant, but I believe it is also true that Scala does not meet the criteria for what that were trying to do, because it is not easy (perhaps not possible) to do the kind of static analysis necessary to achieve their goals.

For a generic "what language with a good type system should we use with ML?" project, I would totally agree with you that Scala is an obvious choice. But this project was attempting a more specific thing, for which Scala is a less good fit.

Re: Swift for TensorFlow Shuts Down

#369

Post by kortex »

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…

I use an ergodox keyboard with a custom Dvorak based layout. Underscore is pretty prominent, analogous to the 4 key with no modifiers.

It makes a huge difference, so much so that using camelCase feels like a huge drag.

Qwerty is frankly awful for programming. I encourage everybody to look into alternate layouts.

Re: Swift for TensorFlow Shuts Down

#370

Post by GregarianChild »

lmm wrote: post #355
bsaul wrote: post #322

Earlier quoted context omitted.

Those are really minor syntax details (except maybe the regex stuff, that’s more a library issue than a language one). Swift is safe (no null pointer exception), has predictable garbage collection performance through ARC, has a familiar C-style syntax (easier to get on-board), has compile-time type checking, good-enough generic programming support, algebraic data types with pattern matching, and will very soon get ac…

Swift just seemed like yet another OCaml-like language to me; there are certainly far worse languages to borrow from, but I don't see any compelling reason why I'd use it over OCaml. ARC has the same worst cases as mark/sweep GC AIUI; exiting any scope might cause an arbitrarily large amount of cleanup work in the general case, and it doesn't solve the memory fragmentation problem which is the main reason you still n…

I agree from a technical POV, but there is a social reason (network effect): Swift has Apple-backing, OCaml is not currently supported by any of the big, influential software companies. OCaml's main backer now is Jane Street who do a lot, but is too small, and Facebook's support (via ReasonML) is too half-hearted to be compelling. As a former OCaml programmer, I would not currently bank a career or startup on OCaml. Indeed I've been doing OCaml programming over the last few weeks (and seen the shortcomings of OCaml's current library eco-system vis-a-vis more mainstream languages) in order to interface with a big existing OCaml development, and they told me they decided to move to Rust for all future new developments.

I say this with a heavy heart, as somebody who spent his first decade as a programmer with OCaml.

Interestingly, even in Feb 2021, there is no compelling mainstream alternative to OCaml (in the sense that e.g. Jane Street are using OCaml): Haskell's being lazy, Java/Scala etc as well as F#/C# being JIT'ed make performance predictability difficult. Rust does not have this problem, but for many tasks where software engineering agility is a more important consideration that extreme performance (which might be most in-house business software?), a GC'ed language would appear to be more suitable.

(No language war please ...)

Post reply on HN