7 ms·

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be needed for performance, forever.

anothernewdude 5y ago
If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.
- dunefox 5y ago
  This is such a non-issue and I'm tired of reading a version of this comment in any thread where Julia is mentioned.
- freemint 5y ago
  This is a total non issue as indexing is an operation that is subject to multiple dispatch. For a humorous example see https://github.com/giordano/StarWarsArrays.jl https://github.com/giordano/StarWarsArrays.jl
- ChrisRackauckas 5y ago
  The person who comes to a Julia discussion and says "so, how's 1-based indexing?" is the same person who walks up to people in the office and goes "so, how's the weather today?" every single day. It's the Smash Mouth Allstar of programming language conversations. The only things interesting about the conversation at this point are the ever more elaborate attempts at semi-comedically changing the topic towards something that's not so overly repeated.
- fault1 5y ago
  Julia (and Fortran) have a concept called offset arrays where you can basically start on any sort of index: https://github.com/JuliaArrays/OffsetArrays.jl https://github.com/JuliaArrays/OffsetArrays.jl IMHO, one of the biggest advantages of Julia _is_ arrays.
  - TheRealKing 5y ago
    Julia does not have offset arrays. There is an external Julia package that can mimic Fortran's intrinsic behavior (arbitrary start index).
    - fault1 5y ago
      julia's package manager is quite modern (and very well designed relative to the mess that is either C++ or python, no experience in modern fortran for me), so something being external or in the core language is not as important as it is with other languages. this is also the same model as in for example, Rust or Javascript. in fact, it appears to me that they intentionally made the core language with fewer amounts of intrinsics relative to other languages. Many of the packages in JuliaArrays/ might as well as be in the core language, especially things like StaticArrays: https://github.com/orgs/JuliaArrays/repositories https://github.com/orgs/JuliaArrays/repositories
  - mrtweetyhack 5y ago
    then why not start at 0 by default?
humanrebar 5y ago
I happen to know that pytorch is a pain to maintain in packaging systems. It has a complex build system, many non-python dependencies, and massive build times. I don't know how this factors into the dissatisfaction with a C++ implementation, but I wouldn't be surprised if it were a factor. In other words, python binary wheels are harder to maintain than source-only python packages. And pytorch uses more than a few. I can't imagine Julia makes the problem much simpler. The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code. I don't know what it would take for this sort of pain point to improve significantly. Some standards around how C, C++, and Fortran projects are packaged would help. This would allow projects to build on top of existing natively compiled tech a lot better. Maybe the biggest reason those languages don't have the same "ecosystem" as python is utter lack of packaging standardization.
- fock 5y ago
  I would recommend you never try to compile tensorflow then. Honestly pytorch might take ages and be relatively complex. But 9/10 tries it builds on a recent Fedora, when you get a new release. tensorflow then ... I mean it's not me to judge that, as I don't understand why you would vendor a ton of C-libraries while depending on a single-file v0.0.3 python library...
- adgjlsfhk1 5y ago
  Julia actually makes this problem way better for 2 different reasons. the first is that you don't need nearly as much C/Fortran when you are working in a fast language. the second is that Julia has binarybuilder which is a really good system for delivering reproduceable binaries that can be distributed. To show how well this works, try adding the Cuda Julia library. it just works without any of the issues python has.
- Sukera 5y ago
  > The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code. Are you talking about something like BinaryBuilder.jl[1], which provides native binaries as julia-callable wrappers? -- [1] https://binarybuilder.org https://binarybuilder.org

anothernewdude 5y ago

If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.

dunefox 5y ago
This is such a non-issue and I'm tired of reading a version of this comment in any thread where Julia is mentioned.
freemint 5y ago
This is a total non issue as indexing is an operation that is subject to multiple dispatch. For a humorous example see https://github.com/giordano/StarWarsArrays.jl https://github.com/giordano/StarWarsArrays.jl
ChrisRackauckas 5y ago
The person who comes to a Julia discussion and says "so, how's 1-based indexing?" is the same person who walks up to people in the office and goes "so, how's the weather today?" every single day. It's the Smash Mouth Allstar of programming language conversations. The only things interesting about the conversation at this point are the ever more elaborate attempts at semi-comedically changing the topic towards something that's not so overly repeated.
fault1 5y ago
Julia (and Fortran) have a concept called offset arrays where you can basically start on any sort of index: https://github.com/JuliaArrays/OffsetArrays.jl https://github.com/JuliaArrays/OffsetArrays.jl IMHO, one of the biggest advantages of Julia _is_ arrays.
- TheRealKing 5y ago
  Julia does not have offset arrays. There is an external Julia package that can mimic Fortran's intrinsic behavior (arbitrary start index).
  - fault1 5y ago
    julia's package manager is quite modern (and very well designed relative to the mess that is either C++ or python, no experience in modern fortran for me), so something being external or in the core language is not as important as it is with other languages. this is also the same model as in for example, Rust or Javascript. in fact, it appears to me that they intentionally made the core language with fewer amounts of intrinsics relative to other languages. Many of the packages in JuliaArrays/ might as well as be in the core language, especially things like StaticArrays: https://github.com/orgs/JuliaArrays/repositories https://github.com/orgs/JuliaArrays/repositories
- mrtweetyhack 5y ago
  then why not start at 0 by default?

humanrebar 5y ago

I happen to know that pytorch is a pain to maintain in packaging systems. It has a complex build system, many non-python dependencies, and massive build times. I don't know how this factors into the dissatisfaction with a C++ implementation, but I wouldn't be surprised if it were a factor. In other words, python binary wheels are harder to maintain than source-only python packages. And pytorch uses more than a few. I can't imagine Julia makes the problem much simpler. The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code. I don't know what it would take for this sort of pain point to improve significantly. Some standards around how C, C++, and Fortran projects are packaged would help. This would allow projects to build on top of existing natively compiled tech a lot better. Maybe the biggest reason those languages don't have the same "ecosystem" as python is utter lack of packaging standardization.

fock 5y ago
I would recommend you never try to compile tensorflow then. Honestly pytorch might take ages and be relatively complex. But 9/10 tries it builds on a recent Fedora, when you get a new release. tensorflow then ... I mean it's not me to judge that, as I don't understand why you would vendor a ton of C-libraries while depending on a single-file v0.0.3 python library...
adgjlsfhk1 5y ago
Julia actually makes this problem way better for 2 different reasons. the first is that you don't need nearly as much C/Fortran when you are working in a fast language. the second is that Julia has binarybuilder which is a really good system for delivering reproduceable binaries that can be distributed. To show how well this works, try adding the Cuda Julia library. it just works without any of the issues python has.
Sukera 5y ago
> The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code. Are you talking about something like BinaryBuilder.jl[1], which provides native binaries as julia-callable wrappers? -- [1] https://binarybuilder.org https://binarybuilder.org