>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,<p>wat? Pretty sure you can use == in requirements.txt<p>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.
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.
i dragged my feet on go for a long time. i also thought that skipping go and moving to rust was the play. a few years later, i still write python often, but i don’t build systems with it. python i now use like bash, to glue things together and automate random things. it’s a fantastic language and i will never drop it.<p>the verbosity of go is the biggest hurdle for a pythonista. the thought of giving up context managers, decorators, iterators, comprehensions, exceptions, coroutines, it’s unthinkable. in comparison go is ugly. your aesthetic mind screams in protest.<p>write go full time. dive in. as months pass, not only will those aesthetic objections fade, your mental model from python cleanly transforms to go. go is what mypy tried to be. the cost was aesthetic changes. the benefit is worth it.<p>the zen of python says if it’s easy to explain it might be a good idea. this is go, and it is.<p>i rebuilt a reasonably sized project from python[1] to go[2] over the last few years. i also have a system that i maintain both python[3] and go[4] implementations for, sharing a test suite in python. squint at the implementations. consciously ignore aesthetic objections. they are basically the same, not very different from a python codebase with and without type annotations.<p>go, like python, is fantastic. use both in whatever amount works for you. don’t read about them, build with them. you won’t regret it.<p>1. <a href="https://github.com/nathants/cli-aws/tree/bb78e529e7d1d3f95acc62dd0fbe21cadc822928" rel="nofollow">https://github.com/nathants/cli-aws/tree/bb78e529e7d1d3f95ac...</a><p>2. <a href="https://github.com/nathants/libaws" rel="nofollow">https://github.com/nathants/libaws</a><p>3. <a href="https://github.com/nathants/s4/tree/python" rel="nofollow">https://github.com/nathants/s4/tree/python</a><p>4. <a href="https://github.com/nathants/s4" rel="nofollow">https://github.com/nathants/s4</a>
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.
I only use python casually, but it seems to me that python library authors are always refactoring and breaking interfaces.<p>Recently, there was a bug in a second order dependency, and the version that fixed this bug was after a version that moved a function into a submodule.<p>So I had to make a local patch to my dependency that changed all of the imports.<p>Was the new interface more consistent? Yes, but could they have left a shim for backwards compatibility, or just lived with the old slightly less consistent interface? Seems to me like they could.
I don't think Python packaging is as bad as people make out (if packages only stick to the basic features of Python!) A far bigger issue I see is despite Python supposedly being 'cross-platform': the language introduces so many small, backwards-compatibility breaking changes that you really need to use the most up to date interpreter you can.<p>For instance: there is now a really cool operator that lets you do expressions where you assign a value and evaluate the result in one line. So you can write the C equivalent of something like while(buf = recv(...)) ... and it will work. Well, any program that uses this new feature won't run on anything but the most bleeding edge Python versions. Despite a program only needing a small fix to remove such expressions. It wouldn't run at all.<p>I think the Python interpreter needs to be 'smarter' and add the capability to automatically install parallel Python versions if it detects a package using a more recent interpreter. Would honestly solve so many issues.
All the docs are easily found here: <a href="https://pkg.go.dev/" rel="nofollow">https://pkg.go.dev/</a><p>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.<p>using goimports as your formatter solves the complaint about unused imports<p>There was a significant portion of time where python 2.x and earlier releases of Go overlapped, and finding UTF-8 safe python libraries was non-trivial. Go makes utf-8 the default. As I understand it many companies still have python2 w/o a EoL plan.<p>One thing I really miss about working with python is list/dict comprehensions and lambdas
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've been reimplementing a tool that was done in nodejs before and ported it to golang.<p>I have to say that a lot of programming paradigms are different in golang, a few parts are annoying, and some parts are "getting there" with generics.<p>The most annoying part if you do a lot of parsing is the golang mandated rule of what is public and what is private in a package. If you want to parse lots of JSON into a struct, mess is on you, always have to implement a custom marshal/unmarshal for it.<p>If you always have to implement a custom JSON marshalling method, and abuse annotations for mapping upper/lowercase properties...why was the uppercase rule mandated in the first place?<p>I wish golang had gone for an export keyword instead. Structs would have been so much cleaner.<p>The second issue I have with golang is that struct properties (as all data types) aren't nullable except via pointers, which makes consuming JSON APIs a fustercluck to deal with some times. I wish there was a nullable string data type instead of having to use dozens of helper functions.<p>The last issue is lack of functional ideas (as of now) but they are coming. lo is a lodash inspired library that makes a lot of things easier. [1] I hope that a lot of these helpers will at some point be part of the core libraries, so that datatypes can be easily mapped, casted and filtered.<p>[1] <a href="https://github.com/samber/lo" rel="nofollow">https://github.com/samber/lo</a>
I tried porting a Python utility I wrote to Go specifically because I did not want people to have to install any 3rd party libraries (in this case just one). If anything I had a much deeper appreciation as to how much Python does for you and just lets you work. I would still like to port someday. For now I can containerize my app but that would still require people to install docker and learn how to use docker.
I was kinda hoping an article with a headline like that would present some code and tooling and explain it in terms of how a Python programmer sees the world.
Tooling aside, Python is a more powerful language, so I’m wondering whether he started generating code to work around stuff like try/except and defaultdict and itertools and decorators.
I don't understand how the author struggled to find a good DynamoDB library. The official AWS SDK has a very useable DynamoDB client and provides utility classes for marshaling and unmarshaling Go types: <a href="https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/dynamodbattribute/" rel="nofollow">https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/...</a>
> I hate how it forces to you create a module everytime.<p>This affected me recently, so I have sympathy for the author. Trying to upgrade an older project I had to the module system meant trying to find out how to import modules which don't have reachable URLs and were only on the GOPATH. At I hate how it forces to you create a module everytime. some point programming in Go stopped being for fun.
Having done both Python and Go for quite some time now, yes, Python modules are a mess, but it wasn’t so long ago that the same could be said for Go (glide-> dep -> go mod anyone else?) Go mod is finally maturing, but there are still some painful edges as well.
> I especially struggled with the DynamoDb library for Go; so much so I wrote a Python script to query Dynamodb, and called it from Go.<p>This seems like a compelling enough reason to stick with Python
This roughly matches my experience, though he doesn't really discuss the language differences in this article. Here's a similar kind of article I wrote a few years ago, "Learning Go by porting a medium-sized web backend from Python": <a href="https://benhoyt.com/writings/learning-go/" rel="nofollow">https://benhoyt.com/writings/learning-go/</a> -- mine focuses more on language and standard library differences.
A bit of both is my answer. For some usage cases eg cloud functions go does seem superior. Yet the convenience of hacking stuff together with python has its appeals too
I realize that Go's original release is later than Python's, but they still feel roughly the same vintage to me. Usually, these articles have a "old to newer" feel, but these two ecosystems feel just different to me. Which is not bad.<p>What would be fascinating is to see some HN links to articles where the journeyman programmer went backwards in time, e.g. "Learning Fortran as a Python developer" or something like that.
So the biggest complaints, from what I read here, is "it does not allow me to write bad code or make mistakes, I want something I can hack together without having to worry about conciseness", and based on groupthink "HN was negative about it". Languages like Rust and Go were designed to keep this sort of thinking away.
> The libraries for Go aren't as good as for Python– certainly, the documentation is lacking<p>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
TL;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.
Shameless plug if it helps anybody else, like it helped me; <a href="http://govspy.peterbe.com/" rel="nofollow">http://govspy.peterbe.com/</a>
On the subject: What is a good, idiomatic, Go project to study? Something big enough to be a good example of code organization, yet small enough not to become a new hobby.
"I felt I was constantly fighting the compiler/borrow checker/whatever. I just want to write some code, dammit"<p>Well here's your problem. Type safety helps you avoid avoidable bugs. Try Haskell or Scala next.
> I had heard of Go for many years, but never stuck with it; it gets constant negative press on Hacker News/Reddit<p>I think on Hacker News it's really fashionable to criticize Go, and this has led to a culture where Go gets significantly more negativity than it deserves.<p>As technologists, one of our most important jobs is to see through such fashions and judge languages/tools/technologies based on their actual merit.<p>While gauging sentiment about things on a forum like Hacker News is generally really helpful, it should not be the main basis of our decisions.
I don't understand the criticism on "shared environments" which the author latter voids himself, but what I <i>do</i> know is that Go makes a fairly good choice for extending Python, but isn't really in the same ballpark as Python.<p>Some thoughts:<p>- Go singlecore is actually slower than Python (nb Stackless[0] [still stands], but not only that: graalpython/loom is even faster, much faster)<p>- 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].<p>- CSP is (in my opinion) less palatable than Actors and makes Go feel somewhat... dated? Matter of taste?<p>- Go doesn't use libc which can be awkward at times.<p>[0] <a href="https://entitycrisis.blogspot.com/2009/11/go-vs-stackless.html?m=1" rel="nofollow">https://entitycrisis.blogspot.com/2009/11/go-vs-stackless.ht...</a><p>[1] <a href="https://root.cern/cling/" rel="nofollow">https://root.cern/cling/</a>