Live data from Hacker News

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

new.pythonforengineers.com

11–20 of 269 posts

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

#11
post #5

I hated the "damnable use requirement" (the error you get on unused imports) for years, but I've been keeping a count of how many bugs they've caught (I was surprised the first time this happened) and I'm up to 3-4 now. What people who code in Go seriously do is just hook `goimports` up to their editor, and then never think about this again.

goimports seems an endless source of absolutely bizarre bugs unless your packages' terminal path element exactly matches the package name (even sometimes if it does e.g. https://github.com/golang/go/issues/29041).

These do get addressed over time but also seems to break in a new way at least a couple times a year.

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

#12

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

Yep, I have no idea how they do not even understand the basics of python dependency management. pip freeze > requirements.txt will do it all for you. No wonder they found rust to hard.

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

#13

Organizing a golang-based project is also something that, while documented, is not front of mind for most new golang users, nor does the "beginning go" posts out there do a good job of how to lay out a project for success.

I always felt that the official documentation is pretty excellent (Worth a re-read if you haven't in a while):

Code organization: https://go.dev/doc/code

Pretty much everything else you should know: https://go.dev/doc/effective_go

There's one thing I think that people getting started with this language should know and that's in the pursuit of getting the stuff you mentioned right, is making sure the reference material (blog post, book, whatever it is) you're reading is something written within the past two or three years. The official site really has enough that you need to know in order to have good knowledge coverage, but the module system beyond version 1.16 especially is something you need to get right and which a ton of old information is out of date on:

https://go.dev/doc/modules/developing

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

#14

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

This is what I came to the comment section to say... You absolutely can pin dependencies.... da fudge? Sounds like this guy needs to finish learning Python before he learns something else. From what you suggested, to containerizing things with something like Docker, there are ways to make Python more easily distributable.

What if the depedencies you pinned have non-pinned depedencies?

packageA==1.0.0 depends itself on packageB

Therefore, you can find yourself with a different set of deps. Had a bug like this once.

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

#15
post #8
post #4

Earlier quoted context omitted.

Is Python significantly better in this regard? I don't think so, especially with the differentiation between modules which are directories with an __init__.py and modules which are files you import directly but if not in the same directory also still need an __init__.py which has tripped up probably 80% of the people I try to teach Python to. In Go you can at least get pretty far with a totally flat namespace and the…

> modules which are files you import directly but if not in the same directory also still need an __init__.py which has tripped up probably 80% of the people I try to teach Python to. Not necessary anymore since Python 3.3 (released in 2012).

Thanks, I went from a lifetime of Python 2.7 straight to 3.8 and missed this.

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

#16
post #10
post #4

Earlier quoted context omitted.

Is Python significantly better in this regard? I don't think so, especially with the differentiation between modules which are directories with an __init__.py and modules which are files you import directly but if not in the same directory also still need an __init__.py which has tripped up probably 80% of the people I try to teach Python to. In Go you can at least get pretty far with a totally flat namespace and the…

With python you can also go pretty far without __init__.py IMO. Just put everything in a single directory.

Beginners trying this are still liable to make import cycles, which... sort of work? Depending on what you do with them? I feel like Go and Java have much better (and different) answers here; I wonder what a Python equivalent of the Java style would look like.

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

#17

Earlier quoted context omitted.

This is what I came to the comment section to say... You absolutely can pin dependencies.... da fudge? Sounds like this guy needs to finish learning Python before he learns something else. From what you suggested, to containerizing things with something like Docker, there are ways to make Python more easily distributable.

What if the depedencies you pinned have non-pinned depedencies? packageA==1.0.0 depends itself on packageB Therefore, you can find yourself with a different set of deps. Had a bug like this once.

Pip freeze will pin explicit as well as transitive dependencies

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

#18

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

Sure can pin versions, it’s easy too, if you just use «pip freeze».

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

#20
While the documentation of many open source Go libraries is definitely lacking, I find that the combination of types and links to readable source in the generated docs more than make up for it. While the documentation for Python libraries is often better, it is generally much harder to answer questions not answered by the docs yourself.
Post reply on HN