4 ms·

100% agree. I use a programming language to get stuff done. and if the day ever comes that someone wants me to show them how I do what I do, I dont want to star

by 2h 4y ago

100% agree. I use a programming language to get stuff done. and if the day ever comes that someone wants me to show them how I do what I do, I dont want to start that conversation with a sigh "well...", I want to start it with a "OK cool..." and all these Python "tools on top of tools" make me sad. Personally I like Go. If someone wants to build my stuff, then I just say go here http://go.dev/dl http://go.dev/dl and download Go, then set location to where the code is, and enter "go build". thats it. All languages should be that easy.

paulddraper 4y ago
Wait did you just call Go versioning and dependency management "easy"??
- 2h 4y ago
  I dont have trouble with it. Link to my code is in my bio, wheres yours? Unless you actually write Go code, I dont think you have a leg to stand on here.
- cure 4y ago
  Compared to the dumpster fire aka Python packaging, Go versioning is easy and predictable indeed.
  - silverwind 4y ago
    Until you hit the obscure rules around v2+ go modules.
    - 2h 4y ago
      I have been coding in Go for years, even professionally sometimes, and I have never had to use "v2" in any of my code. granted my stuff is not popular, but its really just a way for popular repos to handle big changes. Once I got past v1.9.9, I just changed to v1.10.0.
      - silverwind 4y ago
        SemVer dictates a new major version on every breaking change, but it seems this concept is alien to many go developers and they just release breaking changes in patch releases, at the detriment of the ecosystem.
        2h 4y ago
        my biggest project has 13 stars, so I think I can do what I want with it.
  - paulddraper 4y ago
    Fair
- jerf 4y ago
  Are you running on 5+ year old data now? I'm seriously asking, because I'm actually a bit mystified as to the people who think Go's dependency management is some sort of disaster nowadays. Just about the only question I've fielded every so often in the past several months have been people who found their way to an old tutorial based on the old system and them being confused about what happens, and a quick link to the current docs seems to resolve all their problems.
blondin 4y ago
that was before go modules and now workspaces right?
bayesian_horse 4y ago
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.

by 2h 4y ago

paulddraper 4y ago

Wait did you just call Go versioning and dependency management "easy"??

2h 4y ago
I dont have trouble with it. Link to my code is in my bio, wheres yours? Unless you actually write Go code, I dont think you have a leg to stand on here.
cure 4y ago
Compared to the dumpster fire aka Python packaging, Go versioning is easy and predictable indeed.
- silverwind 4y ago
  Until you hit the obscure rules around v2+ go modules.
  - 2h 4y ago
    I have been coding in Go for years, even professionally sometimes, and I have never had to use "v2" in any of my code. granted my stuff is not popular, but its really just a way for popular repos to handle big changes. Once I got past v1.9.9, I just changed to v1.10.0.
    - silverwind 4y ago
      SemVer dictates a new major version on every breaking change, but it seems this concept is alien to many go developers and they just release breaking changes in patch releases, at the detriment of the ecosystem.
      - 2h 4y ago
        my biggest project has 13 stars, so I think I can do what I want with it.
- paulddraper 4y ago
  Fair
jerf 4y ago
Are you running on 5+ year old data now? I'm seriously asking, because I'm actually a bit mystified as to the people who think Go's dependency management is some sort of disaster nowadays. Just about the only question I've fielded every so often in the past several months have been people who found their way to an old tutorial based on the old system and them being confused about what happens, and a quick link to the current docs seems to resolve all their problems.

blondin 4y ago

that was before go modules and now workspaces right?

bayesian_horse 4y ago

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.