5 ms·

Rust will never work except in niche areas because it doesn't allow for easy experimentation and does not provide an iterative workflow like Python, R, or Julia

Rust will never work except in niche areas because it doesn't allow for easy experimentation and does not provide an iterative workflow like Python, R, or Julia. 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.

Ygg2 7y ago
> Rust will never work except in niche because 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.
- hu3 7y ago
  What's wrong in expanding on a topic that was barely mentioned in the article? 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". http://news.ycombinator.com/newsguidelines.html http://news.ycombinator.com/newsguidelines.html
  - fnord123 7y ago
    There can be no discussion with GGP since he obviously didn't read the article. They think the article will claim Rust supplants Python. They think there is a performance advantage in using Julia instead of Python (but the Python code is just calling C, C++, and Rust as described in the article). GGP thinks there will be a tipping point where Julia has more libraries than Python but this is also addressed in the 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.
MayeulC 7y ago
That may be true in data science, but the tradeoffs are not necessarily the same in other fields. I do not see Python fading away in mine, for instance. If anything, it looks more and more encroached, and even if the Python code becomes legacy code, interfaces will have to be maintained. I still use TCL quite often in design automation. Python is and will still be used to script Blender, Kodi, Inkscape, Klayout, sigrok, and countless others, for instance. 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.
mirekrusin 7y ago
Yes, Julia makes some impressive stunts - supercomputing [0], ml where code is very close to mathematical description [1], code reuse [2] etc. [0] https://juliacomputing.com/blog/2019/04/12/Supercomputing-julia.html https://juliacomputing.com/blog/2019/04/12/Supercomputing-ju... [1] https://www.youtube.com/watch?time_continue=188&v=9KBaRS2gy-U&feature=emb_logo https://www.youtube.com/watch?time_continue=188&v=9KBaRS2gy-... [2] https://www.youtube.com/watch?v=kc9HwsxE1OY&t=130s https://www.youtube.com/watch?v=kc9HwsxE1OY&t=130s
deleted 7y ago
[deleted]
pjmlp 7y ago
I am also betting on Julia.
- ilteris 7y ago
  What do you think about Swift
  - pjmlp 7y ago
    It won't go anywhere, Tensorflow for Swift only exists because of Chris Lattner. 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 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.
  - xiaodai 7y ago
    Too verbose. Does not even support Windows. Too closely related to iOS at least in image. MLIR sounds like a nice idea but isn't really Swift specific. I don't understand why they decided to do Swift for Tensorflow, should have invested in Julia for Tensorflow
Certhas 7y ago
I like Julia, but let's be real. We are a long way away from Julia being anywhere near Python when it comes to usability. Error messages, code structure and readability and documentation are afterthoughts rather than a central focus of the community. 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...
- wtetzner 7y ago
  > 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?
  - Certhas 7y ago
    It does, of course, but serialization is problematic (with the combination of Type inference and dynamicism this is maybe to be expected). 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-to-save-variables/21918 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 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).
cwyers 7y ago
It's not like Python's community is done writing libraries and improving libraries. If there is going to be a tipping point it's going to have to start happening before the Julia package ecosystem catches up to Python's.

Ygg2 7y ago

> Rust will never work except in niche because 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.

hu3 7y ago
What's wrong in expanding on a topic that was barely mentioned in the article? 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". http://news.ycombinator.com/newsguidelines.html http://news.ycombinator.com/newsguidelines.html
- fnord123 7y ago
  There can be no discussion with GGP since he obviously didn't read the article. They think the article will claim Rust supplants Python. They think there is a performance advantage in using Julia instead of Python (but the Python code is just calling C, C++, and Rust as described in the article). GGP thinks there will be a tipping point where Julia has more libraries than Python but this is also addressed in the 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.

MayeulC 7y ago

That may be true in data science, but the tradeoffs are not necessarily the same in other fields. I do not see Python fading away in mine, for instance. If anything, it looks more and more encroached, and even if the Python code becomes legacy code, interfaces will have to be maintained. I still use TCL quite often in design automation. Python is and will still be used to script Blender, Kodi, Inkscape, Klayout, sigrok, and countless others, for instance. 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.

mirekrusin 7y ago

Yes, Julia makes some impressive stunts - supercomputing [0], ml where code is very close to mathematical description [1], code reuse [2] etc. [0] https://juliacomputing.com/blog/2019/04/12/Supercomputing-julia.html https://juliacomputing.com/blog/2019/04/12/Supercomputing-ju... [1] https://www.youtube.com/watch?time_continue=188&v=9KBaRS2gy-U&feature=emb_logo https://www.youtube.com/watch?time_continue=188&v=9KBaRS2gy-... [2] https://www.youtube.com/watch?v=kc9HwsxE1OY&t=130s https://www.youtube.com/watch?v=kc9HwsxE1OY&t=130s

deleted 7y ago

[deleted]

pjmlp 7y ago

I am also betting on Julia.

ilteris 7y ago
What do you think about Swift
- pjmlp 7y ago
  It won't go anywhere, Tensorflow for Swift only exists because of Chris Lattner. 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 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.
- xiaodai 7y ago
  Too verbose. Does not even support Windows. Too closely related to iOS at least in image. MLIR sounds like a nice idea but isn't really Swift specific. I don't understand why they decided to do Swift for Tensorflow, should have invested in Julia for Tensorflow

Certhas 7y ago

I like Julia, but let's be real. We are a long way away from Julia being anywhere near Python when it comes to usability. Error messages, code structure and readability and documentation are afterthoughts rather than a central focus of the community. 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...

wtetzner 7y ago
> 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?
- Certhas 7y ago
  It does, of course, but serialization is problematic (with the combination of Type inference and dynamicism this is maybe to be expected). 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-to-save-variables/21918 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 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).

cwyers 7y ago

It's not like Python's community is done writing libraries and improving libraries. If there is going to be a tipping point it's going to have to start happening before the Julia package ecosystem catches up to Python's.