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

281–290 of 432 posts

Re: Swift for TensorFlow Shuts Down

#281

Post by eigenspace »

skohan wrote: post #272
eigenspace wrote: post #252

Earlier quoted context omitted.

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

What's the difference to you for using {} vs ?

are comparison operators for checking if something is less than or greater than something else.

This is okay in a static language where there are special slots for a type where only a restricted subset of things can happen. You'd know at the parser level that the are referring to the type meaning or the operator meaning.

In julia, types are values and values can live in types, and arbtrary operations can happen in a type.

E.g. I can write Tuple{1 < 2} which just becomes the type Tuple{true}, i.e. a Tuple Type with paramemter True.

Re: Swift for TensorFlow Shuts Down

#282

Post by jiofih »

mrtksn wrote: post #267
jiofih wrote: post #260

Earlier quoted context omitted.

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

I use VSCode, it’s helpful but It’s not remotely the same. With TS it’s better when the devs included documentation.

It will use typescript type definitions when available, even if you’re writing plain JS. Auto complete works perfectly, what’s not remotely the same?

Re: Swift for TensorFlow Shuts Down

#283

Post by ec109685 »

chris_st wrote: post #58
wrinkl3 wrote: post #33

Earlier quoted context omitted.

> I think Serverless would be another ideal use-case for Swift, where the productivity, clarity and correctness tools it offers would be a huge benefit. I agree, but sadly none of the big cloud providers has any interest in pushing it - Google's got Go, AWS and Azure seem focused on Typescript.

I know AWS lets you just deploy a docker container, so you can use whatever tools you want -- anyone know about Azure and Google cloud?

Google’s CloudRun has been based on docker containers and simple http interface for a while for their serverless approach.

Re: Swift for TensorFlow Shuts Down

#284

Post by PostThisTooFast »

bsaul wrote: post #6

Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development. I love this language, but i'm eager to see it handled by a proper found…

Wait, what? How does not using it for TensorFlow mean it's all Apple-controlled again suddenly?

Also, it's not 100% mobile, since you can also write Mac apps in it.

It is a shame that Swift hasn't been more widely adopted. The proliferation of languages over the last few years has gotten pretty annoying. And what of Kotlin? That's even more niche at this point.

Re: Swift for TensorFlow Shuts Down

#285

Post by cbkeller »

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?

Linear algebra is the most practically consequential one - and suffice it to say, it’s not a coincidence that BLAS, LINPACK, and LAPACK were all written in one-based languages. Matrix indexing is one-based, and beyond the issue of translating notation from equations, IIRC there is even a slight performance difference in some cases.

I believe what it really comes down to is that, just as zero-based really is more natural for offsets (zero offset means the first position, great for pointers), one based really is more natural for counting [and _sets_] (when your index is n that means you have counted n elements up until now).

Re: Swift for TensorFlow Shuts Down

#286

Post by ddragon »

Waterluvian wrote: post #178

Stupid question. Why is it not "TensorFlow for Swift"?

In this case it's not just a library like the wrappers for tensorflow already present in many languages (including python), it's something like a Swift language fork in which the language constructs are analyzed by the forked compiler during compilation in order to directly generate an equivalent tensorflow execution graph (without manually creating a tape through library calls). Thus it's a Swift (compiler plugin) for tensorflow.

The intention was to merge the fork into the main language making Swift differentiation tools first class within the language.

Re: Swift for TensorFlow Shuts Down

#287

Post by timClicks »

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.

Sorry to be pedantic, but PascalCase is different from camelCase.

Re: Swift for TensorFlow Shuts Down

#288

Post by microtherion »

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...

It's kind of odd. Chris had a huge impact at Apple with LLVM and Swift still going strong and forming the backbone of the developer tools. But I'm not sure he has anything of lasting value to show for his jobs since then. Maybe evidence that for great engineers, just like other great people, fortuitous timing and circumstances are a big part of the story.

Re: Swift for TensorFlow Shuts Down

#289

Post by Waterluvian »

ddragon wrote: post #286
Waterluvian wrote: post #178

Stupid question. Why is it not "TensorFlow for Swift"?

In this case it's not just a library like the wrappers for tensorflow already present in many languages (including python), it's something like a Swift language fork in which the language constructs are analyzed by the forked compiler during compilation in order to directly generate an equivalent tensorflow execution graph (without manually creating a tape through library calls). Thus it's a Swift (compiler plugin) f…

That cleared it up. Thanks.

Re: Swift for TensorFlow Shuts Down

#290

Post by [deleted] »

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…

[deleted]
Post reply on HN