9 ms·

Embracing Swift for Deep Learning

127 points by zeristor 8y ago

maxaf 8y ago
> But Python is not designed to be fast, and it is not designed to be safe. When decisions made by an algorithm can result in real monetary costs, one must always err on the side of caution. Only an irresponsible person would choose Python or other unsafe, dynamically typed language when implementing a crucial piece of business logic.
- ToBeBannedSoon 8y ago
  Python 3.6+ does have type annotations and multiple static analysis tools for type checking. Only an ignorant or biased person would yell at Python for flaws it doesn't have. For crucial business logic, one also writes unit tests.
  - petilon 8y ago
    Unit tests are not an adequate replacement for compile-time checks performed by a compiler. The former is lax and expensive, the latter is thorough and inexpensive.
    - soVeryTired 8y ago
      Language flamewars are silly. Sometimes python is appropriate for production code, weak type system or no. Sometimes it isn't. As a project gets larger, more complex, and more interconnected with other things, static type systems become more useful. End of story, surely? Didn't we all know that already?
    - rahulrrixe 8y ago
      But you loose so much flexibility. When you start working on a problem, you want your language should give you as little headache as it can with minimum rules and constraints. Then on iteration you can improve like having type annotation, unit tests etc. You can write perfectly fine production level code in Python. It like lego block. Start with simple and then add on. Adding compile type checks comes with its own demerits. I guess here Swift is trying to offer more tool chain on compiler level for model building rather than just being type safe.
  - beepy 8y ago
    From the link: > recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide.
  - woadwarrior01 8y ago
    I’ve used mypy and pyre on large Python 3.6 codebases and they aren’t even close to type systems in conventional imperative languages (C++, Java, etc) let alone the type systems in the ML family of languages where type system innovations are usually born. I’m sure they’ll get better with time, to an extent. Currently, programmers are forced to pepper the code with lots of ignore annotation comments and redundant union types, just because the type checkers aren’t smart enough.
- petilon 8y ago
  Python is a fine, accessible language for small programs. ML applications need to be written by data scientists, who are often trained in statistics or math, not software development. For this reason Python is suitable. ML applications built using tensorflow and other ML libs tend to be small -- hundreds of lines, not tens of thousands.
- ilikehurdles 8y ago
  When you start seeing comments like these, you know the whole static typing thing has gone peak cargo cult.
  - rimliu 8y ago
    I am curious what do you think when you see some JavaScript developers moving to Typescript or talks about Ruby 3 having types?
    - mr_toad 8y ago
      Types errors represent such a small class of errors. It’s just puzzling to see what all the hype is about.
      - adamnemecek 8y ago
        Nope, all computation is representable in terms of types. https://en.wikipedia.org/wiki/Curry–Howard_correspondence https://en.wikipedia.org/wiki/Curry–Howard_correspondence
        coldtea 8y ago
        Which is neither here nor there, as a contrived case. In actual languages people us e(e.g. that have more than 2% of the job market), type errors caught by the compiler don't catch "all computation" errors. Not even in Haskell...
      - sytelus 8y ago
        In large sized projects, one of the most frequent activities you do is refactoring. For every refactoring, type errors often constitutes the largest class of errors by volume during initial development phases.
        coldtea 8y ago
        Then again, a language like Python keeps projects smaller, by not taking 100 lines to do what you can do in 10.
amimetic 8y ago
There is a proper explanation of why Swift makes sense for TensorFlow at https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
- lordnaikon 8y ago
  Which is in part written by the author and creator of Swift. Keep this in mind while reading this. Not to sound judgmental but I would be curious while Bill Gates explains to me why windows makes sense for X.
  - yodon 8y ago
    Given that he explains his thinking and reasoning in that post, one can either accept or challenge his logic and discuss it accordingly. There is no need for unprovoked attacks on his credibility. Doing so just suggests you don't feel qualified to evaluate the arguments he makes, in which case it's probably better to ask questions than attack.
    - shard 8y ago
      It does not seem like an attack to me, rather informing readers of possible blindspots or conscious/unconscious bias in the author's point of view. I think it's only human nature to cheerlead something that one has put a significant amount of effort into making. I, as someone who does not know Swift and who its author is, would be more inclined to seek out alternate points of view after knowing that the author of this article is also the author of Swift. Just as one would take any marketing/promotional material for why a company's products are better than competitors with a grain of salt, and would want such material to be clearly marked as marketing material, I think bringing to light the author's relationship to the Swift helps, and does not hinder, further discussion.
      - yodon 8y ago
        If presented in the context of a substantive comment about the assertions, I'd agree with you. Without any such substantive comments it's simply assuming the worst about others. The HN guidelines [0] are actually pretty darn good guidance for encouraging intelligent discussion of complex topics, and by my read advocate for more thoughtful approaches to commenting on multiple fronts here, including not posting shallow dismissals or assumptions about astroturfing and shillage. Again, if there is a concrete objection to the logic the author took time to detail in their post, by all means that's a great topic for discussion, and that's where we would all actually learn something positive instead of just insinuating something negative. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
mark_l_watson 8y ago
When this article came out in March, I tried Swift and TensorFlow on both macOS and Linux - no problems but it seemed like early days, something to check in on occasionally. EDIT: there is a new drop for macOS from April 18 which I am now downloading. I really like modeling with TensorFlow but I have a like-sometimes/hate relationship with Python. If Swift support gets stable and well supported then that would float my boat.
- ahurmazda 8y ago
  Likewise, I tried _swift_ back when it was first announced. I had trouble finding tools in standard library to handle simple FILE operations. There are many resources on using PythonInterops to get the job done. But kinda defeats the purpose. Maybe these are early days. That said, I remain optimistic given Jeremy's involvement — he/Rachael/fastai's been nothing but a source of good for ML in general.
  - saagarjha 8y ago
    You have access to all of libc and Foundation; was this not enough for you?
    - ahurmazda 8y ago
      I am familiar with libc (I will have to look up Foundation). My opinions were based on cursory browsing at best. To be clear, coming from mostly python/c++, I was looking for something like `import pathlib` or `#include <filesystem>`. Lot of modeling work I do involves boring things like moving files around, plotting them etc. Again, its likely that I did not look around enough.
      - saagarjha 8y ago
        Yeah, you are probably looking for Foundation.
rahulrrixe 8y ago
Swift large projects takes huge time to compile whether as interpreter wins here. Though there are model building layer on compiler level which Swift offers in Tensorflow which is unique but apart from that I don’t think it is going to hit nail on Python community.
zeristor 8y ago
If I'm correct the key issue is the need for a deeper level of control, and that Python as as scripting language gluing things together doesn't afford that. They talked about using Swift for differentiable programming, is there something unique in Swift that enables that? From what research I've done it seems the techniques of Deep Learning are much more adaptable than the standard sklearn fit/predict template. I was a bit surprised since fast.ai seemed to be big on PyTorch, it seems a paradigm switch to TensorFlow, but that's what research is all about. In addition to the TensorFlow / Pytorch dichtomy there seems to be Julia's Zygote, still in early stages. Deep Learning is like The Thing, you look away from it for a few minutes and it's sprouted legs out of its head and walked off into a different room: https://en.wikipedia.org/wiki/Differentiable_programming https://en.wikipedia.org/wiki/Differentiable_programming "Some day this Singularity's goin' end..."
- solidasparagus 8y ago
  PyTorch and Tensorflow are not that different, particularly with TF eager.
cs702 8y ago
Question for Jeremy: See links below. Did you look at or consider Julia? -- https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler https://arxiv.org/abs/1810.07951 https://arxiv.org/abs/1810.07951
- Abishek_Muthian 8y ago
  Google Brain team said it considered Julia as well for TensorFlow but -"since its compilation approach is based on type specialization, it may have enough of a representation and infrastructure to host the Graph Program Extraction techniques `they` rely on"[1]. [1]:https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
  - celrod 8y ago
    It sounds like they're saying they think it can be used, but "The Julia community shares many common values as with our project, which they published in a very like-minded blog post[1] after our project was well underway." I think the key point is "after our project was well underway" -- that if they were starting now, they'd likely be consider Julia much more seriously than they did at that time, which was before projects like Zygote got started. Later on from your link: "[We] picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster." [1]: https://julialang.org/blog/2017/12/ml&pl https://julialang.org/blog/2017/12/ml&pl
    - ninjin 8y ago
      As always, a disclaimer, I am deeply involved in the Julia community so beware of my biases. Honestly, I think the best argument (and the only one I buy) for Swift is the latter part: “…we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster.” – just like I said about a year ago [1]. If you are sitting on a team deeply familiar and passionate about a language – Swift – what kind of managerial fool would not let them take a stab at it? Especially with Lattner’s excellent track record. [1]: https://news.ycombinator.com/item?id=16939525 https://news.ycombinator.com/item?id=16939525 The ideas behind Zygote dates to somewhere around spring 2017, but I think it took about a year to hammer out compiler internals and find time to hack, so you are still right that nothing was public when Google settled on Swift – I think there been at least one Mountain View visit though over XLA.jl, but do not quote me on that one. The race is still on and I am looking forward to seeing what all the camps bring to this budding field. I have worked with an excellent student on SPMD auto batching for his thesis project and we now have some things to show [2]. This is still a great time to be a machine learning practitioner and endlessly exciting if you care about the intersection between Machine Learning and programming languages. [2]: https://github.com/FluxML/Hydra.jl https://github.com/FluxML/Hydra.jl My only request would be for Jeremy to explain “Swift for TensorFlow is the first serious effort I’ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance.” to me. Is it the “serious” and/or “widely used” subset where the Julia camp is disjoint? =)
m0zg 8y ago
I just hope Fast.ai adopts some kind of style guide for Swift at least. Python version of fast.ai is an unreadable mess, and it doesn't need to be.
- fredguth 8y ago
  It has a style. It is ok if you don't like it. But it is not ok saying it hasn't. By the way, Jeremy Howard spends several minutes on one of his videos explaining the style and why despite seeming strange it is the right choice for fast.ai. I just can't remember which video, but I would guess it is in dl 2 2019 first video.
pjmlp 8y ago
At least Python and Julia embrace Windows.
echelon 8y ago
We should NOT do this. Swift is not cross-platform! As nice a language as it is, Swift support for Linux and Windows seriously lags behind Mac. If we choose to elect Swift as an ML language, we're handing keys to a certain platform vendor. I don't want to be tied down like that. Keep using Swift for app development--it's great at that. But keep it far away from research and development.
- jkirsteins 8y ago
  > we're handing keys to a certain platform vendor Swift is open source
- bsaul 8y ago
  I don’t think google has any interest in letting swift remain mac only, so in the long run i think we’re safe. Not to mention the fact that mac doesn’t have any technology on the server, so if any code is supposed to reach production one day, it’ll have to at least run on linux.
- mark_l_watson 8y ago
  Just one data point: trying Swift + TensorFlow was as easy using Ubuntu Linux as it was for macOS.
- pharaohgeek 8y ago
  Swift on Linux is great! I use it for a ton of projects, both standalone as well as for microservices development. Aside from cryptographic operations (provided by CommonCrypto on the Mac) I haven't really encountered any scenarios where it can't get the job done. And, for those, I could theoretically make use of OpenSSL (if I felt like going through that exercise).
- willio58 8y ago
  Swift is completely supported by Linux iirc, not considering max or iOS specific UI libraries. Windows support is probably not a priority because.. why would it be?
bertomartin 8y ago
Sounds really interesting, but it seems like this is all due to the graph extraction algorithm needing to use static analysis. Is this such an important requirement that it requires switching languages? I'm not too familiar with how PyTorch works under the hood, but I suspect it doesn't builds a graph (correct me if I'm wrong) and they seem to get good perf. I'm all for new tech, but just wanna get a sense of how impactful this change would be.

127 points by zeristor 8y ago

> But Python is not designed to be fast, and it is not designed to be safe. When decisions made by an algorithm can result in real monetary costs, one must always err on the side of caution. Only an irresponsible person would choose Python or other unsafe, dynamically typed language when implementing a crucial piece of business logic.

ToBeBannedSoon 8y ago
Python 3.6+ does have type annotations and multiple static analysis tools for type checking. Only an ignorant or biased person would yell at Python for flaws it doesn't have. For crucial business logic, one also writes unit tests.
- petilon 8y ago
  Unit tests are not an adequate replacement for compile-time checks performed by a compiler. The former is lax and expensive, the latter is thorough and inexpensive.
  - soVeryTired 8y ago
    Language flamewars are silly. Sometimes python is appropriate for production code, weak type system or no. Sometimes it isn't. As a project gets larger, more complex, and more interconnected with other things, static type systems become more useful. End of story, surely? Didn't we all know that already?
  - rahulrrixe 8y ago
    But you loose so much flexibility. When you start working on a problem, you want your language should give you as little headache as it can with minimum rules and constraints. Then on iteration you can improve like having type annotation, unit tests etc. You can write perfectly fine production level code in Python. It like lego block. Start with simple and then add on. Adding compile type checks comes with its own demerits. I guess here Swift is trying to offer more tool chain on compiler level for model building rather than just being type safe.
- beepy 8y ago
  From the link: > recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide.
- woadwarrior01 8y ago
  I’ve used mypy and pyre on large Python 3.6 codebases and they aren’t even close to type systems in conventional imperative languages (C++, Java, etc) let alone the type systems in the ML family of languages where type system innovations are usually born. I’m sure they’ll get better with time, to an extent. Currently, programmers are forced to pepper the code with lots of ignore annotation comments and redundant union types, just because the type checkers aren’t smart enough.
petilon 8y ago
Python is a fine, accessible language for small programs. ML applications need to be written by data scientists, who are often trained in statistics or math, not software development. For this reason Python is suitable. ML applications built using tensorflow and other ML libs tend to be small -- hundreds of lines, not tens of thousands.
ilikehurdles 8y ago
When you start seeing comments like these, you know the whole static typing thing has gone peak cargo cult.
- rimliu 8y ago
  I am curious what do you think when you see some JavaScript developers moving to Typescript or talks about Ruby 3 having types?
  - mr_toad 8y ago
    Types errors represent such a small class of errors. It’s just puzzling to see what all the hype is about.
    - adamnemecek 8y ago
      Nope, all computation is representable in terms of types. https://en.wikipedia.org/wiki/Curry–Howard_correspondence https://en.wikipedia.org/wiki/Curry–Howard_correspondence
      - coldtea 8y ago
        Which is neither here nor there, as a contrived case. In actual languages people us e(e.g. that have more than 2% of the job market), type errors caught by the compiler don't catch "all computation" errors. Not even in Haskell...
    - sytelus 8y ago
      In large sized projects, one of the most frequent activities you do is refactoring. For every refactoring, type errors often constitutes the largest class of errors by volume during initial development phases.
      - coldtea 8y ago
        Then again, a language like Python keeps projects smaller, by not taking 100 lines to do what you can do in 10.

amimetic 8y ago

There is a proper explanation of why Swift makes sense for TensorFlow at https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

lordnaikon 8y ago
Which is in part written by the author and creator of Swift. Keep this in mind while reading this. Not to sound judgmental but I would be curious while Bill Gates explains to me why windows makes sense for X.
- yodon 8y ago
  Given that he explains his thinking and reasoning in that post, one can either accept or challenge his logic and discuss it accordingly. There is no need for unprovoked attacks on his credibility. Doing so just suggests you don't feel qualified to evaluate the arguments he makes, in which case it's probably better to ask questions than attack.
  - shard 8y ago
    It does not seem like an attack to me, rather informing readers of possible blindspots or conscious/unconscious bias in the author's point of view. I think it's only human nature to cheerlead something that one has put a significant amount of effort into making. I, as someone who does not know Swift and who its author is, would be more inclined to seek out alternate points of view after knowing that the author of this article is also the author of Swift. Just as one would take any marketing/promotional material for why a company's products are better than competitors with a grain of salt, and would want such material to be clearly marked as marketing material, I think bringing to light the author's relationship to the Swift helps, and does not hinder, further discussion.
    - yodon 8y ago
      If presented in the context of a substantive comment about the assertions, I'd agree with you. Without any such substantive comments it's simply assuming the worst about others. The HN guidelines [0] are actually pretty darn good guidance for encouraging intelligent discussion of complex topics, and by my read advocate for more thoughtful approaches to commenting on multiple fronts here, including not posting shallow dismissals or assumptions about astroturfing and shillage. Again, if there is a concrete objection to the logic the author took time to detail in their post, by all means that's a great topic for discussion, and that's where we would all actually learn something positive instead of just insinuating something negative. [0] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

mark_l_watson 8y ago

When this article came out in March, I tried Swift and TensorFlow on both macOS and Linux - no problems but it seemed like early days, something to check in on occasionally. EDIT: there is a new drop for macOS from April 18 which I am now downloading. I really like modeling with TensorFlow but I have a like-sometimes/hate relationship with Python. If Swift support gets stable and well supported then that would float my boat.

ahurmazda 8y ago
Likewise, I tried _swift_ back when it was first announced. I had trouble finding tools in standard library to handle simple FILE operations. There are many resources on using PythonInterops to get the job done. But kinda defeats the purpose. Maybe these are early days. That said, I remain optimistic given Jeremy's involvement — he/Rachael/fastai's been nothing but a source of good for ML in general.
- saagarjha 8y ago
  You have access to all of libc and Foundation; was this not enough for you?
  - ahurmazda 8y ago
    I am familiar with libc (I will have to look up Foundation). My opinions were based on cursory browsing at best. To be clear, coming from mostly python/c++, I was looking for something like `import pathlib` or `#include <filesystem>`. Lot of modeling work I do involves boring things like moving files around, plotting them etc. Again, its likely that I did not look around enough.
    - saagarjha 8y ago
      Yeah, you are probably looking for Foundation.

rahulrrixe 8y ago

Swift large projects takes huge time to compile whether as interpreter wins here. Though there are model building layer on compiler level which Swift offers in Tensorflow which is unique but apart from that I don’t think it is going to hit nail on Python community.

zeristor 8y ago

If I'm correct the key issue is the need for a deeper level of control, and that Python as as scripting language gluing things together doesn't afford that. They talked about using Swift for differentiable programming, is there something unique in Swift that enables that? From what research I've done it seems the techniques of Deep Learning are much more adaptable than the standard sklearn fit/predict template. I was a bit surprised since fast.ai seemed to be big on PyTorch, it seems a paradigm switch to TensorFlow, but that's what research is all about. In addition to the TensorFlow / Pytorch dichtomy there seems to be Julia's Zygote, still in early stages. Deep Learning is like The Thing, you look away from it for a few minutes and it's sprouted legs out of its head and walked off into a different room: https://en.wikipedia.org/wiki/Differentiable_programming https://en.wikipedia.org/wiki/Differentiable_programming "Some day this Singularity's goin' end..."

solidasparagus 8y ago
PyTorch and Tensorflow are not that different, particularly with TF eager.

cs702 8y ago

Question for Jeremy: See links below. Did you look at or consider Julia? -- https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler https://arxiv.org/abs/1810.07951 https://arxiv.org/abs/1810.07951

Abishek_Muthian 8y ago
Google Brain team said it considered Julia as well for TensorFlow but -"since its compilation approach is based on type specialization, it may have enough of a representation and infrastructure to host the Graph Program Extraction techniques `they` rely on"[1]. [1]:https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
- celrod 8y ago
  It sounds like they're saying they think it can be used, but "The Julia community shares many common values as with our project, which they published in a very like-minded blog post[1] after our project was well underway." I think the key point is "after our project was well underway" -- that if they were starting now, they'd likely be consider Julia much more seriously than they did at that time, which was before projects like Zygote got started. Later on from your link: "[We] picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster." [1]: https://julialang.org/blog/2017/12/ml&pl https://julialang.org/blog/2017/12/ml&pl
  - ninjin 8y ago
    As always, a disclaimer, I am deeply involved in the Julia community so beware of my biases. Honestly, I think the best argument (and the only one I buy) for Swift is the latter part: “…we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster.” – just like I said about a year ago [1]. If you are sitting on a team deeply familiar and passionate about a language – Swift – what kind of managerial fool would not let them take a stab at it? Especially with Lattner’s excellent track record. [1]: https://news.ycombinator.com/item?id=16939525 https://news.ycombinator.com/item?id=16939525 The ideas behind Zygote dates to somewhere around spring 2017, but I think it took about a year to hammer out compiler internals and find time to hack, so you are still right that nothing was public when Google settled on Swift – I think there been at least one Mountain View visit though over XLA.jl, but do not quote me on that one. The race is still on and I am looking forward to seeing what all the camps bring to this budding field. I have worked with an excellent student on SPMD auto batching for his thesis project and we now have some things to show [2]. This is still a great time to be a machine learning practitioner and endlessly exciting if you care about the intersection between Machine Learning and programming languages. [2]: https://github.com/FluxML/Hydra.jl https://github.com/FluxML/Hydra.jl My only request would be for Jeremy to explain “Swift for TensorFlow is the first serious effort I’ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance.” to me. Is it the “serious” and/or “widely used” subset where the Julia camp is disjoint? =)

m0zg 8y ago

I just hope Fast.ai adopts some kind of style guide for Swift at least. Python version of fast.ai is an unreadable mess, and it doesn't need to be.

fredguth 8y ago
It has a style. It is ok if you don't like it. But it is not ok saying it hasn't. By the way, Jeremy Howard spends several minutes on one of his videos explaining the style and why despite seeming strange it is the right choice for fast.ai. I just can't remember which video, but I would guess it is in dl 2 2019 first video.

pjmlp 8y ago

At least Python and Julia embrace Windows.

echelon 8y ago

We should NOT do this. Swift is not cross-platform! As nice a language as it is, Swift support for Linux and Windows seriously lags behind Mac. If we choose to elect Swift as an ML language, we're handing keys to a certain platform vendor. I don't want to be tied down like that. Keep using Swift for app development--it's great at that. But keep it far away from research and development.

jkirsteins 8y ago
> we're handing keys to a certain platform vendor Swift is open source
bsaul 8y ago
I don’t think google has any interest in letting swift remain mac only, so in the long run i think we’re safe. Not to mention the fact that mac doesn’t have any technology on the server, so if any code is supposed to reach production one day, it’ll have to at least run on linux.
mark_l_watson 8y ago
Just one data point: trying Swift + TensorFlow was as easy using Ubuntu Linux as it was for macOS.
pharaohgeek 8y ago
Swift on Linux is great! I use it for a ton of projects, both standalone as well as for microservices development. Aside from cryptographic operations (provided by CommonCrypto on the Mac) I haven't really encountered any scenarios where it can't get the job done. And, for those, I could theoretically make use of OpenSSL (if I felt like going through that exercise).
willio58 8y ago
Swift is completely supported by Linux iirc, not considering max or iOS specific UI libraries. Windows support is probably not a priority because.. why would it be?

bertomartin 8y ago

Sounds really interesting, but it seems like this is all due to the graph extraction algorithm needing to use static analysis. Is this such an important requirement that it requires switching languages? I'm not too familiar with how PyTorch works under the hood, but I suspect it doesn't builds a graph (correct me if I'm wrong) and they seem to get good perf. I'm all for new tech, but just wanna get a sense of how impactful this change would be.