4 ms·

The charitable way of looking at that is Chris Lattner is leading this project because the project requires certain things Lattner has experience with, and ther

by cwyers 7y ago

The charitable way of looking at that is Chris Lattner is leading this project because the project requires certain things Lattner has experience with, and therefore the language he designed is one that meets all their criteria. Now, it's possible that they were less objective about the language choice than they believe themselves to be, but they certainly have thought about it an awful lot, and they deserve some benefit of the doubt, unless you can demonstrate what of this justification is untrue.

newen 7y ago
Julia is clearly a better choice. No one in the ML world even knew what Swift was before this.
- deleted 7y ago
  [deleted]
FridgeSeal 7y ago
They full on brushed off Julia with hardly a justification. It’s the strongest contender and got hardy a mention. They just dismiss it on the grounds of “oh uuuh there are...aren’t many libraries or something”, nevermind the fact that Julia’s data science and ML ecosystem is far more developed than Swift’s is. Moving TF to Julia would have killed 2 birds with one stone: community size and outright number of packages would have both been fixed as a community grew up around TF in Julia.
- pjmlp 7y ago
  And at least I can enjoy Julia as pure Windows programming language.
- orbifold 7y ago
  Julia compares very unfavourably to both Python and Swift: Slow startup time (unpredictable JIT compiler lag), terrible error messages and stack traces, duck typing misrepresented as type checking. I've tried using it for what it is meant for (numerical code / ODE solving etc.) multiple times now. It performs admirably in that domain. But no ten horses would make me use it for anything else. Machine learning needs to be fully integrated into the larger language ecosystem. You can easily imagine developing a large scale software product in Swift, not so much in Julia (even less so than in Python). Julia is probably a Nightmare to develop in once you have more than 10 people working on the project. The internal structure of Julia's compiler is also a mess compared to the Swift compiler. You could easily imagine building a compile service / large scale build system / tooling for swift, not so much for Julia. Plus they were able to easily extend the Swift intermediate language in the way they wanted to, while there is no comparable abstraction in Julia. The Swift compiler also fits neatly into the C++ based ecosystem that Google has.
  - cwyers 7y ago
    It's possible that it's less effort for a top notch compiler developer to come in and fix Julia's compiler than it is to give Swift the data science ecosystem that Julia is building. I have little experience with it, but it's a question of tradeoffs.
    - orbifold 7y ago
      Well from my point of view, the largest advantage that Swift has over Julia is that it has a pretty nice static type system. If you look at what they did with the Differentiable protocol, then this is precisely what you want from a type system perspective without going all in on dependent types. Historically there are very few examples where a dynamically typed language was retrofitted with a static type system successfully (Typescript and Javascript being one example). Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work, then that a company invests significant resources in Julia to make it suitable for large scale machine learning in a non scientific "blue collar" setting.
      - FridgeSeal 7y ago
        > Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. What? I have had no trouble with the errors produced from multiple dispatch! More often than not they've helped me get straight to the fix, which is more than I can ever say for Python. > There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work I would rather claw my eyes out than do significant data work in .Net. C# is our language of choice at work, and it's pretty great for them, but my god is it the most verbose, confusing and convoluted language I've ever had to deal with. F# isn't too bad, but once again, lacks any serious data science community and package support. They're also not terribly fast languages, which is a pretty important factor in ML stuff.
  - byt143 7y ago
- timholy 7y ago
  One reason for the choice may be encoded in the date of that post: April 2018. That was before the release of Julia 1.0. Were they making that choice today, I can't help but think the economics might be rather different.

by cwyers 7y ago

newen 7y ago

Julia is clearly a better choice. No one in the ML world even knew what Swift was before this.

deleted 7y ago
[deleted]

FridgeSeal 7y ago

They full on brushed off Julia with hardly a justification. It’s the strongest contender and got hardy a mention. They just dismiss it on the grounds of “oh uuuh there are...aren’t many libraries or something”, nevermind the fact that Julia’s data science and ML ecosystem is far more developed than Swift’s is. Moving TF to Julia would have killed 2 birds with one stone: community size and outright number of packages would have both been fixed as a community grew up around TF in Julia.

pjmlp 7y ago
And at least I can enjoy Julia as pure Windows programming language.
orbifold 7y ago
Julia compares very unfavourably to both Python and Swift: Slow startup time (unpredictable JIT compiler lag), terrible error messages and stack traces, duck typing misrepresented as type checking. I've tried using it for what it is meant for (numerical code / ODE solving etc.) multiple times now. It performs admirably in that domain. But no ten horses would make me use it for anything else. Machine learning needs to be fully integrated into the larger language ecosystem. You can easily imagine developing a large scale software product in Swift, not so much in Julia (even less so than in Python). Julia is probably a Nightmare to develop in once you have more than 10 people working on the project. The internal structure of Julia's compiler is also a mess compared to the Swift compiler. You could easily imagine building a compile service / large scale build system / tooling for swift, not so much for Julia. Plus they were able to easily extend the Swift intermediate language in the way they wanted to, while there is no comparable abstraction in Julia. The Swift compiler also fits neatly into the C++ based ecosystem that Google has.
- cwyers 7y ago
  It's possible that it's less effort for a top notch compiler developer to come in and fix Julia's compiler than it is to give Swift the data science ecosystem that Julia is building. I have little experience with it, but it's a question of tradeoffs.
  - orbifold 7y ago
    Well from my point of view, the largest advantage that Swift has over Julia is that it has a pretty nice static type system. If you look at what they did with the Differentiable protocol, then this is precisely what you want from a type system perspective without going all in on dependent types. Historically there are very few examples where a dynamically typed language was retrofitted with a static type system successfully (Typescript and Javascript being one example). Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work, then that a company invests significant resources in Julia to make it suitable for large scale machine learning in a non scientific "blue collar" setting.
    - FridgeSeal 7y ago
      > Julia's multi methods are really nice but produce horrible errors when they fail at runtime, I don't see an obvious way to fix that. What? I have had no trouble with the errors produced from multiple dispatch! More often than not they've helped me get straight to the fix, which is more than I can ever say for Python. > There is a bigger chance that another contender arises within the C#/F# ecosystem as an evolution of the ML.Net work I would rather claw my eyes out than do significant data work in .Net. C# is our language of choice at work, and it's pretty great for them, but my god is it the most verbose, confusing and convoluted language I've ever had to deal with. F# isn't too bad, but once again, lacks any serious data science community and package support. They're also not terribly fast languages, which is a pretty important factor in ML stuff.
- byt143 7y ago
timholy 7y ago
One reason for the choice may be encoded in the date of that post: April 2018. That was before the release of Julia 1.0. Were they making that choice today, I can't help but think the economics might be rather different.