Hacker News Reader

Comment by 2h | Hacker News Reader

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 and download Go, then set location to where the code is, and enter "go build". thats it. All languages should be that easy.

View on HN

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...

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.

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.

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?

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.

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.

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.

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.

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.

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 :)

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

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.

Compared to the dumpster fire aka Python packaging, Go versioning is easy and predictable indeed.

Until you hit the obscure rules around v2+ go modules.

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.

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.

my biggest project has 13 stars, so I think I can do what I want with it.

Fair

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.

that was before go modules and now workspaces right?

Reply on news.ycombinator.com