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

111–120 of 269 posts

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

#111

Post by xboxnolifes »

bobbylarrybobby wrote: post #99
tptacek wrote: 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.

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?

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

#112

Post by corrral »

nathants wrote: post #76
vonseel wrote: post #58

Earlier quoted context omitted.

Do Go programmers also not like capitalization? Just a tease, I noticed the readme and your comment don't have any Capitalized Letters. Well, the readme has a few but you know what I mean.

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.

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

#113

Post by punnerud »

jeremydw wrote: post #38
ActorNightly wrote: post #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…

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…

Not a mess, but options. That’s what’s encourage innovation and open up for new ideas.

This Fortran vs Python example is worth reading: https://cerfacs.fr/coop/fortran-vs-python

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

#114

Post by tandav »

Scarblac wrote: post #8
morelisp wrote: 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).

Still necessary for mypy (if you want type checks) and setuptools (if you want to publish library to pypi)

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

#115

Post by ska »

pletnes wrote: post #18
ActorNightly wrote: post #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…

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

That only solves part of the problem.

something like poetry's approach is the right one here; you need a list of core dependencies (not derived ones), you need a solver for when anything changes to find a new set of viable versions, and you need a lock file of some sort to uniquely & reproducible construct an environment.

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

#116

Post by tptacek »

bobbylarrybobby wrote: post #99
tptacek wrote: 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.

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.

I'm not offering any opinion about the use requirement other than to say that it has caught 3-4 bugs for me.

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

#117

Post by obviouslynotme »

ledauphin wrote: post #106
obviouslynotme wrote: post #78

Earlier quoted context omitted.

Go has always been a Java, C#, Python, and Ruby killer. It has not and never will be a C or C++ killer. C is the language of libraries and embedded, neither of which Go is good for. C++ is the language of large systems that need extreme control over resource allocation. Go is not good for this either.

I agree with you that Go does not replace C or C++, but I strongly disagree that Go is an obvious replacement for most uses of Python, C#, Java or Ruby, all of which are, frankly, _much_ higher level languages than Go. Go gets used for two main reasons that I've been able to observe: 1) a desire for a very specific type of concurrency 2) a desire for a fast compiled language with a minimalistic feature set that scale…

Go has always been a high level language, and is even more so now with generics. I would even argue that Go, correctly done, is halfway between the Java tier and the Lisp tier. Due to Go's quick and easy parsability, generation, and compilation. It is very easy to write tools for Go. Code generation and struct tags are even part of the standard, but very people use them beyond the basic serialization libraries. It's not quite lisp, but it is very close in many ways.

Very few people rewrite projects. Most change happens by new projects adopting one language over another. The fact that I hear of Python rewrites to Go is honestly amazing.

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

#118

Post by chpmrc »

jeremydw wrote: post #38
ActorNightly wrote: post #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…

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 following is sufficient (assuming Python3 is installed):

- python -m venv .venv

- source .venv/bin/activate

- pip install -r requirements.txt

That's it. And all of that requires a single dependency: Python. Could it be better? Sure. But to call that a "mess" is an exaggeration.

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

#119

Post by obviouslynotme »

wizofaus wrote: post #97
obviouslynotme wrote: post #78

Earlier quoted context omitted.

Go has always been a Java, C#, Python, and Ruby killer. It has not and never will be a C or C++ killer. C is the language of libraries and embedded, neither of which Go is good for. C++ is the language of large systems that need extreme control over resource allocation. Go is not good for this either.

Is Go really killing C# though? I've rewritten Go components in C# (the initial version only had basic functionality requirements, but as they expanded, Go made less and less sense given the rest of our codebase), but can't readily imagine wanting to rewrite C# in Go. Maybe once they add proper exceptions...

No. C# is usually used by Microsoft shops, and half the reason to use C# is so you can use Visual Studio.

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

#120

Post by takeda »

jeremydw wrote: post #38
ActorNightly wrote: post #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…

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…

Keep in mind that Python is 31 year old (it's even older than Java) it was created around the same time as world wide web. So it started when no one even knew they would need dependency management and evolved over time from people posting packages on their home pages, to a central website to what we now call PyPI. Similarly the tooling and way of packaging the code evolved.

What you described are multiple tools that also target different areas:

> - poetry

from what you listed this seems like the only tool that actually takes care of dependency management

> - "Just pin the dependencies and use Docker"

this is standard fallback for all languages when people are lazy and don't want to figure out how to handle the dependencies

> - pip freeze

all this does it just lists currently installed packages in a form that can be automatically read by pip

> - Vendoring in dependency code

this again is just a way that applies to all languages, and it is still necessary even if there's a robust dependency management as there are some cases where bundling everything together is preferred

> - pipreqs

this is just a tool that scans your code and tells you what dependencies you are using. You are really lost if you need a tool to tell you what packages is your application is using, but I suppose it can be useful for one offs if you inherit some python code that wasn't using any dependence management.

> - virtualenv

this is just a method to have dependencies installed locally in project directory instead per system. This was created especially for development (although it can be used for deployment as well) as people started working on multiple services with different dependencies. It's now included in python so it's more like a feature of the language.

Post reply on HN