3 ms·

Go gets around all these problems by being not all that popular (compared to Python and Node), not being as general purpose, and starting from a blank slate wit

Go gets around all these problems by being not all that popular (compared to Python and Node), not being as general purpose, and starting from a blank slate with control mostly from a corporate overlord. Static linking also simplifies things. Go doesn't make a habit of interfacing with lots of legacy C,C++ and Fortran Code. There's probably some of that. But nothing like Numpy, Scipy, Tensorflow...

nicoburns 4y ago
Rust/Cargo manage to deal with interfacing with lots of legacy C and C++ code (not sure about Fortran) while still "just working" seamlessly. Usually it's easier to get a C library to build via the Rust package (just `cargo add package && cargo build`) than it is to integrate it into a C build system.
- bayesian_horse 4y ago
  Not my point. Pip/setuptools can build most C/C++ code just fine. Most, maybe even "almost all an average user would care about". But Rust doesn't extend into the same depth, and once it does you can expect the same issues. And you hardly ever need to compile Python extensions with pip or conda either, because both can distribute binaries for the most used platforms anyways.
  - Yoric 4y ago
    FWIW, last time I attempted to install a Python dev environment under Windows (for teaching purposes), I eventually gave up because I couldn't get all my dependencies working. That is an important data point for me. Fortunately, I had a macbook at hand for teaching, but that's hardly ideal. I'm not sure what you mean about Rust not extending into the same depth, could you elaborate?
    - bayesian_horse 4y ago
      That must have been some strange dependencies. When I install anaconda on Windows, there's almost nothing to do to get Tensorflow, Torch, Jupyter etc going. Same with Blender, it just plain works. And if not then that's not a packaging issue but rather a problem about portability because yes, some packages are system specific, and Windows is quite specific. One way around even those issues is to use either WSL2 or Docker desktop, maybe using VSC development containers or WSL remote. There's always a fringe of packages in every package manager that deosn't have the greates compatibility among different dependencies and systems. Python's ecosystem is no exception to that.
      - Yoric 4y ago
        I was attempting to install PyGame. Hardly an unusual package. But the dependencies were somehow broken on Windows. After 20 minutes of trying, I gave up.
- bsder 4y ago
  Not even close. What is going on in the Python ecosystem is people expect Python to interface to C/C++ modules on Windows. Reliably. And no other ecosystem even really tries. As an example, Rust interfacing to Skia (C++) used to cause hideous build errors on various Windows installs. I needed to install and upgrade significant chunks of Visual Studio (not VSCode--actual Visual Studio) before the Rust system could compile it correctly. And the next Windows update it all broke again.
Yoric 4y ago
While this is largely true, the Python situation remains a mess that needs to be resolved. Also, Rust seems to indicate that being general purpose and interfacing with lots of legacy C (and some C++) aren't the issues.
- bayesian_horse 4y ago
  Nope, Rust is not doing anything better. It is doing significantly less. The fewer packages you have the fewer dependency issues you run into. Rust will still run into the same DLL issues on Windows, requiring custom solutions, once the package ecosystem comes anywhere close to what Python offers.
  - Yoric 4y ago
    I'm not sure how we ended up discussing dll. You were writing about "interfacing with lots of legacy C,C++ and Fortran Code", which is something else entirely. Does this mean that we agree that "interfacing with lots of legacy C,C++ and Fortran Code" is not the issue and that we have moved to another issue? Dynamic libraries can definitely be a problem, across languages. I've seen plenty of crates that rely on platform-specific .so/.dylib, so I'm not really nervous about that being supported, but it's absolutely possible that there may be Windows-specific issues that I haven't heard about. edit Complete rewrite, let's hope nobody has responded yet :)

nicoburns 4y ago

Rust/Cargo manage to deal with interfacing with lots of legacy C and C++ code (not sure about Fortran) while still "just working" seamlessly. Usually it's easier to get a C library to build via the Rust package (just `cargo add package && cargo build`) than it is to integrate it into a C build system.

bayesian_horse 4y ago
Not my point. Pip/setuptools can build most C/C++ code just fine. Most, maybe even "almost all an average user would care about". But Rust doesn't extend into the same depth, and once it does you can expect the same issues. And you hardly ever need to compile Python extensions with pip or conda either, because both can distribute binaries for the most used platforms anyways.
- Yoric 4y ago
  FWIW, last time I attempted to install a Python dev environment under Windows (for teaching purposes), I eventually gave up because I couldn't get all my dependencies working. That is an important data point for me. Fortunately, I had a macbook at hand for teaching, but that's hardly ideal. I'm not sure what you mean about Rust not extending into the same depth, could you elaborate?
  - bayesian_horse 4y ago
    That must have been some strange dependencies. When I install anaconda on Windows, there's almost nothing to do to get Tensorflow, Torch, Jupyter etc going. Same with Blender, it just plain works. And if not then that's not a packaging issue but rather a problem about portability because yes, some packages are system specific, and Windows is quite specific. One way around even those issues is to use either WSL2 or Docker desktop, maybe using VSC development containers or WSL remote. There's always a fringe of packages in every package manager that deosn't have the greates compatibility among different dependencies and systems. Python's ecosystem is no exception to that.
    - Yoric 4y ago
      I was attempting to install PyGame. Hardly an unusual package. But the dependencies were somehow broken on Windows. After 20 minutes of trying, I gave up.
bsder 4y ago
Not even close. What is going on in the Python ecosystem is people expect Python to interface to C/C++ modules on Windows. Reliably. And no other ecosystem even really tries. As an example, Rust interfacing to Skia (C++) used to cause hideous build errors on various Windows installs. I needed to install and upgrade significant chunks of Visual Studio (not VSCode--actual Visual Studio) before the Rust system could compile it correctly. And the next Windows update it all broke again.

Yoric 4y ago

While this is largely true, the Python situation remains a mess that needs to be resolved. Also, Rust seems to indicate that being general purpose and interfacing with lots of legacy C (and some C++) aren't the issues.

bayesian_horse 4y ago
Nope, Rust is not doing anything better. It is doing significantly less. The fewer packages you have the fewer dependency issues you run into. Rust will still run into the same DLL issues on Windows, requiring custom solutions, once the package ecosystem comes anywhere close to what Python offers.
- Yoric 4y ago
  I'm not sure how we ended up discussing dll. You were writing about "interfacing with lots of legacy C,C++ and Fortran Code", which is something else entirely. Does this mean that we agree that "interfacing with lots of legacy C,C++ and Fortran Code" is not the issue and that we have moved to another issue? Dynamic libraries can definitely be a problem, across languages. I've seen plenty of crates that rely on platform-specific .so/.dylib, so I'm not really nervous about that being supported, but it's absolutely possible that there may be Windows-specific issues that I haven't heard about. edit Complete rewrite, let's hope nobody has responded yet :)