[HN Gopher] FastAI.jl: FastAI for Julia
       ___________________________________________________________________
        
       FastAI.jl: FastAI for Julia
        
       Author : dklend122
       Score  : 100 points
       Date   : 2021-07-27 18:03 UTC (4 hours ago)
        
 (HTM) web link (forums.fast.ai)
 (TXT) w3m dump (forums.fast.ai)
        
       | losvedir wrote:
       | Wasn't there a Swift version of FastAI, too? Are they trying to
       | have libraries in multiple ecosystems, or did that one peter out?
        
         | adamnemecek wrote:
         | Swift for Tensorflow was cancelled.
        
         | cbkeller wrote:
         | A bit of googling turns up [1][2], but [2] doesn't seem to have
         | much recent activity (presumably in turn due to Google ceasing
         | active development of S4TF [3]
         | 
         | [1] https://www.fast.ai/2019/03/06/fastai-swift/
         | 
         | [2] https://github.com/fastai/swiftai
         | 
         | [3] https://github.com/tensorflow/swift
        
       | ellisv wrote:
       | This is interesting to me but the motivation behind this is
       | unclear. Since FastAI.jl uses Flux, and not PyTorch,
       | functionality has to be reimplemented. FastAI.jl has vision
       | support but no text support yet.
       | 
       | What does this mean for the development of fastai?
       | 
       | What is the timeline for FastAI.jl to achieve parity?
       | 
       | When should I choose FastAI.jl vs fastai?
        
         | NegatioN wrote:
         | It does seem to actually be an unofficial implementation in
         | Julia. So it shouldnt have any impact on the actual
         | development?
         | 
         | Im kinda wondering if Jeremy Howard has ok'ed using their name
         | on a library that they're not in charge of? I didnt find a
         | clear answer to that. Particularly troubling since it seems
         | like the FluxML organization is behind this, not some random
         | dude
        
           | BadInformatics wrote:
           | From TFA:
           | 
           | > We'll also be hosting a Q&A session 02.08., 10PM UTC
           | (03.08., 12AM CEST | 8AM AEST). Jeremy will be there, too.
           | Meeting link will follow soon.
           | 
           | My understanding is that he's at least been aware of this
           | since early development (just over a year), so make of that
           | what you will.
        
             | NegatioN wrote:
             | Well, that's great then! :) Guess i should have actually
             | read the post instead of jumping to the github page...
        
         | BadInformatics wrote:
         | Having tried fastai for a "serious" research project and helped
         | (just a bit) towards FastAI.jl development, here's my take:
         | 
         | > motivation behind this is unclear.
         | 
         | Julia currently has two main DL libraries. Flux, which is
         | somewhere between PyTorch and (tf.)Keras abstraction wise, and
         | Knet, which is a little lower level (think just below
         | PyTorch/around where MXNet Gluon sits). Frameworks like fastai,
         | PyTorch Lightning and Keras demonstrate that there's a desire
         | for higher-level, more batteries included libraries. FastAI.jl
         | is looking to fill that gap in Julia.
         | 
         | > Since FastAI.jl uses Flux, and not PyTorch, functionality has
         | to be reimplemented. FastAI.jl has vision support but no text
         | support yet.
         | 
         | This is correct. That said, FastAI.jl is not and does not plan
         | to be a copy of the Python API (hence "inspired by"). One
         | consequence of this is that integration with other libraries is
         | much easier, e.g.
         | https://github.com/chengchingwen/Transformers.jl for NLP tasks.
         | 
         | > What is the timeline for FastAI.jl to achieve parity?
         | 
         | > When should I choose FastAI.jl vs fastai?
         | 
         | This depends on your use cases and how comfortable you are with
         | a) Julia b) having to roll some of your own code. For the
         | first, I'd recommend poking around with the language before as
         | well as using the linked dev channel in TFA to get an informed
         | opinion.
         | 
         | FastAI.jl itself is composed of multiple constituent packages
         | that can and are used independently, so there's also the option
         | of mixing and matching. For example,
         | https://github.com/lorenzoh/DataLoaders.jl is completely
         | library agnostic.
        
         | jstx1 wrote:
         | > When should I choose FastAI.jl vs fastai?
         | 
         | Unless you're following the course, you probably shouldn't use
         | either.
        
           | kyllo wrote:
           | Why not? Honest question--I haven't used fastai myself but my
           | understanding is it's just a high-level wrapper API for
           | PyTorch. Any particular reason why you wouldn't want to use
           | it outside of the course?
        
             | NegatioN wrote:
             | We use it for training some of the models we use in
             | production environments serving millions of requests per
             | day, so there's no reason to exclude it completely IMO. As
             | you say, it's a wrapper for Pytorch with a few extras
             | tacked on.
             | 
             | With Pytorch you would either use pure torch, FastAI or
             | something like Lightning most of the time. Unless you're
             | using completely mainstream models such as the ones you
             | could get from the Transformers library.
        
       | dklend122 wrote:
       | Note: This is a sanctioned port by the Julia community.
        
       | cbkeller wrote:
       | Looking forward to trying this out!
        
       ___________________________________________________________________
       (page generated 2021-07-27 23:00 UTC)