Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Go as a Python Developer: The Good and the Bad

new.pythonforengineers.com

Post reply on HN
Print view View original

211–220 of 269 posts

Re: Learning Go as a Python Developer: The Good and the Bad

#211

Post by throwawaymaths »

derac wrote: post #98
throwawaymaths wrote: post #41

Earlier quoted context omitted.

Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.

The major issues you'll see involve library version mismatches. It's a very good idea to use venv with these tools since there are often mismatches between projects.

Tensorflow sometimes is pinned to Nvidia drivers, and protobuf. And I think it has to be system level unless you reaaaaally want to fiddle with the internals.

Re: Learning Go as a Python Developer: The Good and the Bad

#212

Post by throwawaymaths »

smeagull wrote: post #152
throwawaymaths wrote: post #41

Earlier quoted context omitted.

Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.

I'd be too fat from all that icecream.

Ok. I know two companies that exist because of this problem.

Re: Learning Go as a Python Developer: The Good and the Bad

#213

Post by throwawaymaths »

korijn wrote: post #80
jeremydw wrote: post #38

Earlier quoted context omitted.

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

Is it a mess? Yes. But, is the problem to be solved perhaps much simpler "in other languages"? Do you interface with C++ libraries, system-managed dependencies, and perhaps your GPU in these other languages? Or are all your dependencies purely coded in these other languages, making everything simpler? Of course the answer to these questions could be anything but to me it feels like attacks on Python's package managem…

Yes. In elixir, you can install GPU stuff (Nx) with very few problems. Some people have built some really cool tools like burrito, which cross-compile and bundles up the VMs to other architectures. Even before that it's been pretty common to cross-compile from x86 to an arm raspberry pi image in the form of Nerves.

As a rule elixir devs don't do system level dependencies, probably because of lessons learned from the hell scape that is python (and Ruby)

Yesterday I onboarded a coworker onto the elixir project, he instinctively put it into a docker container. I laughed and just told him to run it bare (he runs macos, I run Linux). There were 0 problems out of the box except I forgot the npm incantations to load up the frontend libraries.

Re: Learning Go as a Python Developer: The Good and the Bad

#214

Post by Ygg2 »

oarabbus_ wrote: post #192
takeda wrote: post #172

Earlier quoted context omitted.

But Python has a decent and a reproducible way of installing packages. The problem python has is that things evolved over time, so you can find on the net plenty of outdated information. There is also a lot of blogs and articles with bad practices, most written by people that got something working. I think also a lot of issues with packaging is ironically because of PyPA that supposed to work on a standard, but in re…

>But Python has a decent and a reproducible way of installing packages. Reading the comment thread it's not immediately clear what the answer is - it seems implied that the proper way is using Poetry, is that the case?

It's not.

See https://imgs.xkcd.com/comics/python_environment_2x.png

Or sometime the computer is haunted and my colleague had problems installing tensorflow. To this day he has no working tensorflow.

Re: Learning Go as a Python Developer: The Good and the Bad

#215

Post by remix2000 »

I don't understand the criticism on "shared environments" which the author latter voids himself, but what I do know is that Go makes a fairly good choice for extending Python, but isn't really in the same ballpark as Python.

Some thoughts:

- Go singlecore is actually slower than Python (nb Stackless[0] [still stands], but not only that: graalpython/loom is even faster, much faster)

- Prototyping is always slower in most AoT-compiled languages, obviously. I'd be more convinced to try Go if it had something like Cling[1].

- CSP is (in my opinion) less palatable than Actors and makes Go feel somewhat... dated? Matter of taste?

- Go doesn't use libc which can be awkward at times.

[0] https://entitycrisis.blogspot.com/2009/11/go-vs-stackless.ht...

[1] https://root.cern/cling/

Re: Learning Go as a Python Developer: The Good and the Bad

#216

Post by shaklee3 »

brightball wrote: post #203
jeremydw wrote: post #38

Earlier quoted context omitted.

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

When I tried learning Python, this mess is what turned me off so badly. Python is the first language I ever came across where I felt like Docker was necessary just to keep the mess in a sandbox. Coming to that from hearing stories that there was supposed to be one way to do everything disenchanted me quickly.

python has had virtual environments forever now. what was it missing?

Re: Learning Go as a Python Developer: The Good and the Bad

#217

Post by damagednoob »

remix2000 wrote: post #215

I don't understand the criticism on "shared environments" which the author latter voids himself, but what I do know is that Go makes a fairly good choice for extending Python, but isn't really in the same ballpark as Python. Some thoughts: - Go singlecore is actually slower than Python (nb Stackless[0] [still stands], but not only that: graalpython/loom is even faster, much faster) - Prototyping is always slower in m…

> Go singlecore is actually slower than Python

This is news to me. Do you have something newer then a 13 year old blog post that shows this?

Re: Learning Go as a Python Developer: The Good and the Bad

#218

Post by korijn »

pdimitar wrote: post #101
korijn wrote: post #80

Earlier quoted context omitted.

Is it a mess? Yes. But, is the problem to be solved perhaps much simpler "in other languages"? Do you interface with C++ libraries, system-managed dependencies, and perhaps your GPU in these other languages? Or are all your dependencies purely coded in these other languages, making everything simpler? Of course the answer to these questions could be anything but to me it feels like attacks on Python's package managem…

Or the "complainers" work with Rust and Elixir and giggle at Python's last-century dependency-management woes, while they run a command or two and can upgrade and/or pin their dependencies and put that in version control and have builds identical [to those on their dev machines] in their CI/CD environment. ¯\_(ツ)_/¯ Your comment hints that you are feeling personally attacked when Python is criticized. Friendly unsoli…

> Your comment hints that you are feeling personally attacked when Python is criticized.

I am not feeling personally attacked (I am not married to Python), I am mostly just tired of reading the same unproductive type of complaints over and over again. This attitude is not unique to Python's situation, but actually is typical to our industry. It makes me want to find a different job, on some days.

The community is trying to improve the situation but there is no way to erase Python's history. So it's always going to continue to look messy if you keep looking back. The complaint is unproductive, or in other words, not constructive.

Re: Learning Go as a Python Developer: The Good and the Bad

#219

Post by korijn »

throwawaymaths wrote: post #213
korijn wrote: post #80

Earlier quoted context omitted.

Is it a mess? Yes. But, is the problem to be solved perhaps much simpler "in other languages"? Do you interface with C++ libraries, system-managed dependencies, and perhaps your GPU in these other languages? Or are all your dependencies purely coded in these other languages, making everything simpler? Of course the answer to these questions could be anything but to me it feels like attacks on Python's package managem…

Yes. In elixir, you can install GPU stuff (Nx) with very few problems. Some people have built some really cool tools like burrito, which cross-compile and bundles up the VMs to other architectures . Even before that it's been pretty common to cross-compile from x86 to an arm raspberry pi image in the form of Nerves. As a rule elixir devs don't do system level dependencies, probably because of lessons learned from the…

Ok, now I am curious :) let's try some typical problems from the Python package ecosystem:

- Can you resolve precompiled GPU dependencies with system managed CUDA driver versions?

- Are there packages that can convert PDF to PNG without system dependencies?

- Can you run a Qt GUI app on CI without needing to do any additional system setup?

With regards to cross compilation tools like burrito, that's neat! But Python is not a compiled language.

Re: Learning Go as a Python Developer: The Good and the Bad

#220

Post by Gilboboy »

raffraffraff wrote: post #85
throwawaymaths wrote: post #41

Earlier quoted context omitted.

Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.

And unless things have gotten a lot better in the 2 years since I last did `pip install numpy` on ARM, prepare for a very long wait because you'll be building it from source.

There's a precompiled package for ARM these days.
Post reply on HN