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

411–420 of 432 posts

Re: Swift for TensorFlow Shuts Down

#411

Post by Grustaf »

jamil7 wrote: post #157
iujjkfjdkkdkf wrote: post #73

Earlier quoted context omitted.

> Are you nervous about a language that is designed and supported by the largest and most successful company in the world? Yes, I am. The concentration of power between facebook and google for ML frameworks is worrying enough, but to their credit, they have so far been very open and collaborative and are giving a lot back to the ML community in terms of research Apple on the other hand is the dictionary definition of…

I think there is too much focus on Swift as a general purpose language. I really enjoy working in it and it’s great at what it does, does it have to be deployed in every domain?

That was Chris Lattner's original dream at least, but I suppose it can remain viable even if it is "only" used on Apple's billion+ devices.

Re: Swift for TensorFlow Shuts Down

#412

Post by toyg »

simias wrote: post #70
superbcarrot wrote: post #57

Earlier quoted context omitted.

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

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…

> it baffles me that they accepted to get these

The chorus of people asking for increased typesafety had become too loud to ignore. Type hints gave them enough support to cover 95% of their needs, which were/are largely organizational rather than technical: developers must feel sure they are using the right classes in their code, pulled from the right places in their project, and don’t have to look up docs at every step (because the IDE will autocomplete stuff). What happens later, the low-level implementation, it doesn’t really matter; what matters is the information about types is surfaced somewhere, so that IDEs and tooling can use it to document projects and help developers.

That’s what type hints do, and yeah, they are basically glorified docs, but integrating docs into syntax is one of Python’s many traditional strengths (see docstrings, doctests, etc). That’s also why they are optional, thank goodness, so people who don’t have big-org / big-project needs can still be productive.

Re: Swift for TensorFlow Shuts Down

#413

Post by lmm »

6gvONxR4sf7o wrote: post #402
lmm wrote: post #351

Earlier quoted context omitted.

> You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]). The difference between these two cases is that a function that returns [a] will always return [a] and if you convert it to `NonEmptyList n a` you will be nudged towards han…

I was unclear. I meant the other way around. In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list. A third party author in even a language like Haskell won’t necessarily use the bells and whistles of giving very specific types. And by the List[str] bit, I mean you can annotate it as doing whatever it in fact does. You aren’t prote…

> In the case that the third party code does in fact always return no empty lists of positive numbers, the author might just type it as a list.

Yes - but as I said, you can be confident that the list type is accurate, and if you want to convert that list to a specific-length list type then you're nudged towards doing it in a way where you handle the case where the list isn't actually the length you specified.

> And by the List[str] bit, I mean you can annotate it as doing whatever it in fact does. You aren’t protected if you get that wrong, of course

Not "of course"; the whole point of a type system is that it's automatically checked and therefore you can have reasonable confidence in the types you're given.

Re: Swift for TensorFlow Shuts Down

#414

Post by amkkma »

The_rationalist wrote: post #385
dd82 wrote: post #372

Earlier quoted context omitted.

yes, and if you go to that link, you can see its experimental, for TF 2.4 _and_ the notebook on github was created Aug 3, 2020. So that is relatively new and most likely has a ways to go before further adoption. Its good that option exists, but doesn't seem very backwards compatible. That doesn't negate the points made in the parent.

It will mature before the Julia ecosystem mature so the value proposition of Julia is out weighted by it's lack of ecosystem. Had they transparant interoperability with Python like Kotlin is for Java, I would consider it. They could at least rewrite their vm to use the truffle framework from graalvm so that they would become interoperable with Python on graal which in a few years will mature.

What do you know about the Julia ecosystem?

Re: Swift for TensorFlow Shuts Down

#415

Post by int_19h »

ambicapter wrote: post #302
skohan wrote: post #199

Earlier quoted context omitted.

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 do…

CamelCase is terrible as soon as you have an abbreviation in your function (like "DB"). I run into this extremely frequently at my place of work.

It really depends on your naming conventions. If you consistently treat acronyms in the same way as regular words (i.e. "XmlReader", "IoStream" etc), then there's no practical difference with "xml_reader" and "io_stream".

Re: Swift for TensorFlow Shuts Down

#416

Post by int_19h »

jodrellblank wrote: post #406
socialdemocrat wrote: post #232

Earlier quoted context omitted.

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…

That's not a particularly convincing blogpost - for example you don't need square brackets for indexing, one of Ken Iverson's changes going from APL to J was to see indexing as just another function application and remove square bracket syntax from it. Grouping arithmetic expression is worsened by complex precedence rules, APL always evaluating right-to-left and all operators having the same precendence changes how t…

Because it doesn't really help as soon as you get repeated nesting, which isn't all that uncommon.

Re: Swift for TensorFlow Shuts Down

#417

Post by int_19h »

SatvikBeri wrote: post #25
MrPowers wrote: post #18

Earlier quoted context omitted.

It seemed like Swift looked like a promising language for data science a few years ago. I'm not familiar with Swift. Can anyone provide additional context as to why the language seemed promising for data?

I disagree with the pitch, but the pitch I heard when this was announced was: * Swift lets you write code that's as concise as Python while still being fast, and therefore allows you to get away from the problem of having to write ML code in multiple languages (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.) * That the lack of static typing is a major pain point in Python…

> TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.

I'm curious if you've seen https://docs.microsoft.com/en-us/visualstudio/python/debuggi..., and if so, to what extent it helps with C++/Python interop in TensorFlow context?

Re: Swift for TensorFlow Shuts Down

#418

Post by astrange »

lostmsu wrote: post #314
astrange wrote: post #266

Earlier quoted context omitted.

> Swift was a weird choice for statically typed TensorFlow, being only popular on the platform, that does not have GPU/TPU support in TensorFlow, which is, basically, a requirement for any serious work. The fact, that they had to fork the compiler did not help either. This is available now (not sure if it's in mainline). https://blog.tensorflow.org/2020/11/accelerating-tensorflow-...

M1 is not a good replacement for Nvidia GPU, especially a professional one.

This is Metal support for Tensorflow, not M1 support. It works on AMD, and it'd work on Nvidia if they updated their drivers.

Re: Swift for TensorFlow Shuts Down

#419

Post by eigenspace »

jodrellblank wrote: post #408
eigenspace wrote: post #280

Earlier quoted context omitted.

Maybe it's just my julia indoctrination speaking but I find that rather ugly. In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter. We just write Type{paramemer}

> " We just write Type{paramemer} " It seems odd to say "we just write" for some arbitrary choice with its own tradeoffs; {} mean a set in Python or a literal array initialiser in C# or a scriptblock in PowerShell or a dfn in Dyalog APL or a JSON dictionary, etc. With only a limited set of whatever symbols happened to end up on a US ASCII keyboard 40+ years ago, there is heavy competition for them, it's why J broke t…

I never said it was objectively better.

My point was just that we find Type{parameter} to be nice pleasing syntax, and so reserved the curly braces for that.

Of course it’s not objectively better, that’s a dumb attitude towards syntax.

Re: Swift for TensorFlow Shuts Down

#420

Post by dagmx »

dragonwriter wrote: post #409
dagmx wrote: post #400

Earlier quoted context omitted.

There's multiple aspects to what a type system can entail. There's dynamic/static typing which is what most of the thread is about. Python is dynamically typed , which makes it really easy to pickup and make stuff in, but you get issues like runtime errors/bugs since there's no inherent type checking other than attribute access failure, or explicit isinstance calls. To the best of my knowledge, there's no advancement…

> Type annotation helps partially here since you can statically check the types notated post facto but this is not the type system.hatever a static type checker enforces is exactly a type system (and the only thing that is), in the standard CS sense. The fact that the type checker isn't integrated with the compiler/interpreter is a different design choice from other systems, but it doesn't change what it is. Effectiv…

It's not a non standard definition of what a type system is. If anything, yours is the non standard one that is more commonly called type checking.

Either way, you've devolved this into condescension and I refuse to engage further with such petulant discord.

Post reply on HN