Learning Go as a Python Developer: The Good and the Bad
new.pythonforengineers.com
Learning Go as a Python Developer: The Good and the Bad
1–10 of 269 posts
Re: Learning Go as a Python Developer: The Good and the Bad
#2TL;DR: Python is hard because of library dependencies, go is better about that because of compiling to an executable, but is pickier about code quality ("I just want to try something"), and has more issues with library quality.
Re: Learning Go as a Python Developer: The Good and the Bad
#3Organizing 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.
Re: Learning Go as a Python Developer: The Good and the Bad
#4Organizing 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.
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 there's nothing wrong with that, up to at least 50kloc or so. That's less true in any language where files become a unit of modularization.
Re: Learning Go as a Python Developer: The Good and the Bad
#5I 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.
Re: Learning Go as a Python Developer: The Good and the Bad
#6>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.
Re: Learning Go as a Python Developer: The Good and the Bad
#7>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.
Re: Learning Go as a Python Developer: The Good and the Bad
#8Organizing 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.
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).
Re: Learning Go as a Python Developer: The Good and the Bad
#9>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…
That’s fine until it wont compile on someone else’s machine. Had that many times before with python.
SciPy is a bastard on macs for example.
Re: Learning Go as a Python Developer: The Good and the Bad
#10Organizing 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.
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.