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

121–130 of 269 posts

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

#121

Post by linsomniac »

chpmrc wrote: post #118
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…

- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet) - Pip freeze just pins all dependencies at once to requirements.txt - I don't know what "vendoring in dependency code" means - I've never used pipreqs in my life (and 80% of my work has been in Python) - Virtualenvs are just a convenient way to keep project runtimes separated And for 90% of Python projects in existence the fol…

"Vendoring" means including the library in your package. So instead of listing it in requirements.txt, you copy the code of the library.

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

#122

Post by kelvie »

maerF0x0 wrote: post #32

All the docs are easily found here: https://pkg.go.dev/ The complaint about aws-sdk-go (presumably v1) is legitimate, it seems to me that code was generated and therefore the repo can be less than ideal w/ Go. I suspect that is improved/ing in v2. using goimports as your formatter solves the complaint about unused imports There was a significant portion of time where python 2.x and earlier releases of Go overlapped,…

It's still valid for v2. While it's a bit easier to use in almost all respects, the documentation is still kind of crazy because it's mostly autogenerated.

In Go, the first thing you run into when making an API call is figuring out how to handle the errors, and the aws-sdk-go docs still don't give you much help there --you have to still dive into the official REST docs, or worse, the Java docs via google, and sort of guess how each exception/error code gets mapped into what Go error.

Jumping into the library code works for most Go libraries, but with the autogenerated REST bindings that is the AWS SDK, it usually isn't much more illuminating.

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

#123

Post by DenseComet »

wizofaus wrote: post #94
zozbot234 wrote: post #75

Earlier quoted context omitted.

Docker is linux specific. It can only run in a VM on non-linux platforms.

It requires a linux subsystem, true, but not a fully fledged VM. The subsystem still shares the file system with the primary OS, for a start. And while I haven't tried it, the instructions for installing AppImage on WSL (for example) don't look trivial.

WSL is a fully fledged VM under the hood, it's just well integrated.

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

#124

Post by mountainriver »

> The libraries for Go aren't as good as for Python– certainly, the documentation is lacking

Huh, Go has some of the best autodoc features of any language. Also the library assertion is insane to me. I switch back and forth from Go to Python all day and generally Go has more stable better maintained libs

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

#125

Post by Zopieux »

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…

It's a bit ironic to pick someone's up on "taking things personally upon criticism", then proceeding to display a deep, manichean, unfounded hatered for a language that, despite its numerous flaws, remains a popular and useful tool.

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

#126

Post by nathants »

corrral wrote: post #112
nathants wrote: post #76

Earlier quoted context omitted.

i can only speak for myself. i reserve raising my voice for where it's APPROPRIATE. as with the python/go debate, aesthetics are subjective.

Breaking basic language norms in this way is the equivalent of CONSTANTLY RAISING YOUR VOICE. It's distracting and attention-getting. Which may be your goal, but if your goal is to be easily understood and sympathetic to your reader, it's counterproductive.

this is exactly correct.

i sincerely apologize to any who have been harmed, even slightly, by my oddity.

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

#127

Post by wizofaus »

DenseComet wrote: post #123
wizofaus wrote: post #94

Earlier quoted context omitted.

It requires a linux subsystem, true, but not a fully fledged VM. The subsystem still shares the file system with the primary OS, for a start. And while I haven't tried it, the instructions for installing AppImage on WSL (for example) don't look trivial.

WSL is a fully fledged VM under the hood, it's just well integrated.

MS call it a "lightweight utility virtual machine", and "not a traditional VM experience", whatever that means. Docker also works on MacOS, with a basic linux distro running under hypervisor that again, I'm not sure qualifies as a 'fully fledged VM' (at least in terms of user access to it).

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

#128

Post by mcronce »

pdimitar wrote: post #102
okasaki wrote: post #96

Earlier quoted context omitted.

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have s…

> and even modern languages like rust (stuff is always broken, or I have some incompatible version, even when it builds it doesn't work) Been working on and off with Rust for the last 3 years, never happened to me once -- with the exception of the Tokio async runtime that has breaking changes between versions. Everything else always worked on the first try (checked with tests, too). Comparing Python with C++ doesn't…

This is consistent with my experience. Semantic versioning is very very widely used in the Rust ecosystem, so you're not looking at breaking changes unless you select a different major version (or different minor version, for 0.x crates) - which you have to do manually, cargo will only automatically update dependencies to versions which semver specifies should be compatible.

For crates that don't follow semver (which I'm fairly certain I've encountered zero times) you can pin a specific exact version.

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

#129

Post by pdimitar »

Zopieux wrote: post #125
pdimitar wrote: post #101

Earlier quoted context omitted.

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…

It's a bit ironic to pick someone's up on "taking things personally upon criticism", then proceeding to display a deep, manichean, unfounded hatered for a language that, despite its numerous flaws, remains a popular and useful tool.

Hanging people upon dawn was popular as well; people even got their kids for the event and it was happening regularly. Popularity says nothing about quality or even viability.

Use Python if it's useful for you, obviously. To me though the writing is on the wall -- it's on its loooong and painful (due to people being in denial) way out.

EDIT: I don't "hate"; it was a figure of speech. Our work has no place for such emotions. I simply get "sick of" (read: become weary of) something being preached as good when it clearly is not, at least in purely technical terms. And the "hate" is not at all unfounded. Choosing to ignore what doesn't conform to your view is not an argument.

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

#130

Post by bobbylarrybobby »

xboxnolifes wrote: post #111
bobbylarrybobby wrote: post #99

Earlier quoted context omitted.

How is this better than downgrading the error into a warning? You'd be able to build but would still know something was wrong-ish. Certainly a warning would be sufficient to chase down any bugs, and is very freeing compared to an error.

Turned around, what's the benefit of allowing someone to build something that may potentially break, when the alternative is an easy to fix error instead?

The benefit is not needing to make any additional source changes when you go from using an import to not using it to using it again.
Post reply on HN