It warms my heart to see people don't read TFA. Like at all.
From TFA:
> But it was important to clean the air of any possible misunderstanding before getting started. I don’t believe Rust will replace Python as the language of choice for ML - it just isn’t happening, it’s not a thing, neither today or tomorrow.
Your parent wrote detailed reasoning that's not present in the article.
Also this type of uncharitable comment is against Hacker News guidelines: "Please don't comment on whether someone read an article".
There is no expanding on topics barely mentioned in the article. As far as GGP is concerned there was just a headline and they Kanye'd with "Julia is the best". As far as I care, mods can delete the comment and subtree.
But your week-end project you need to write a bit of code for and want to practice a new language with/just want to code as quick as possible? Sure, the languages will come and go.
Likewise with Rust. Maybe not for iterative design phases, but I can certainly see it being used in production, especially if robustness/speed are needed.
Because the core is so brilliant at what it does I am sure that Julia will get there eventually, but it will be a painful way.
For crying out loud, we still don't have a sory for people to save their data...
Can you elaborate on what you mean by this? Does Julia not support writing files?
Beyond that there is a bewildering array of packages, and not really a clear consensus for which to use:
https://discourse.julialang.org/t/what-is-the-preferred-way-...
JLD2, which for a while seemed like an emerging consensus option has caused massive dataloss for a number of people:
https://github.com/JuliaIO/JLD2.jl/issues/55
The issue is also that Julia packages often use their own container types for convenient analysis. For example the solution type of DiffEq has a number of important features like interpolation built in. If I want to reliably save the data I got from the numerical integration, and don't want to rely on brittle/broken serialization packages, I have to extract the underlying arrays though. That would be fine if not for the fact that there is no documented way (that I've found) to initialize the solution objects from this raw data, so now I have lost access to the convenience functions.
Don't get me wrong, this is all growing pains. I am sure this will be sorted out eventually. But it's important to point out how the intersection of features that enable Julia to do things that are unheard of in other languages (e.g. DiffEqFlux, Zygote) also mean there are some things that still need to be figured out for this language (serialization, useful error messages, interfaces).
The only workaround is to use an undocumented alternative interface for working on the files. A pull request to at least inform people about the issue has been lying around for almost two years.
I am happy that activity has picked up again, but don't intend to recommend the use of JLD2 for expensive data for the foreseeable future...
[0] https://juliacomputing.com/blog/2019/04/12/Supercomputing-ju... [1] https://www.youtube.com/watch?time_continue=188&v=9KBaRS2gy-... [2] https://www.youtube.com/watch?v=kc9HwsxE1OY&t=130s
Many researchers work on Windows, Swift has zero support there and when asked about it, they just kind of invite the Swift community to provide support.
So zero interest from either Apple or Google to make it work on Windows.
This is the latest status of Swift on Windows,
https://www.youtube.com/watch?v=Zjlxa1NIfJc
Then on Linux, Foundation support is still flaky, for basic stuff one still needs to do conditional compilation and directly import either Darwin or GLibc modules.
Swift is just like Objective-C, yes you can kind of use it outside Apple's ecosytem, but at expense of productivity and lack of adequate tooling.
Really I don't expect Tensorflow for Swift to ever reach mainstream adoption, maybe Google can sell it as Mac only and thus announce the project has having been a success.
I think the future is Julia, as it's as easy to write as Python, is interactive, and can be compiled for fast speeds!
It will just takes time for Julia to have as many libraries, but at some point the tipping point will be reached, and Julia will just eat Python's lunch.
Python was dying before the latest wave of data science and machine learning craze saved it anyway. There are pretty good reasons to believe Python (and Ruby) will slowly wither away. I am careful not to savy that they will die out, because they won't as some computing problems do not require so much speed and hence Python and the like can still pass mustard. But in a post-Moore's-law-world, data is getting bigger, the demand for computing is larger, but programs aren't getting faster, and there is a limit to how much you can optimise Python. Eventually, a crop of speedy and easy to write programming languages will rise up and eat Python's lunch. The early signs are there with tools like Julia.