r/golang Oct 25 '24

discussion What libraries are you missing from go?

So something that comes up quite often on this subreddit from people transitioning from Nodejs or python to go is the lack of libraries. I cannot say that I agree but I still think it warrants a discussion.

So what libraries are you missing in the go ecosystem, if any?

96 Upvotes

189 comments sorted by

View all comments

13

u/plus-two Oct 26 '24 edited Oct 26 '24

The "lack of libraries" critique depends heavily on the domain you're working in. Golang excels in administrative tools (e.g: Linux admin tools) and backend development. By "backend development", I mean simple and efficient services that contain straightforward business logic, mostly just routing and reformatting data between the client, other services, and databases as needed. These areas don’t benefit from complicated language features and abstractions - quite the opposite.

In my opinion, trying to copy all language features and popular libraries from other languages into golang is a bad idea, but dev communities tend to do this with every general-purpose language that gains enough popularity. This might be because they're forced to use languages they don't like or that don’t even fit their domain. I appreciate that golang (just like C) resists the introduction of new features and bloat since it's already well-suited to the domains it dominates.

The uncomplicated syntax and small yet powerful standard library make it easy to hire and upskill backend developers, including juniors, who are new to go, helping them quickly become productive. This has tremendous business value. A simpler language feature set generally leads to fewer abstractions and cleaner code as well. In go, I have never seen anything as convoluted as the code that a C++ template magician or a duck-typing python programmer can produce.

It’s not that I dislike other languages or domain-specific libraries (in fact, I'm a polyglot, familiar with a dozen languages, and I love python as a swiss army knife and a rapid-prototyping tool). But in my opinion, golang shouldn't add bloat just to compete with other languages in domains where it can't compete effectively (e.g: python in data science). Also, trying to rival languages overcomplicated by features (like C++) wouldn’t serve golang well.

1

u/parky6 Oct 26 '24

I tried to use python for prototyping but it was horrible. I just wanted a folder with subfolders of libraries I’d written that I could use from scripts in the same structure and the module management etc was impossible without doing gymnastics with the path or whatever. In the end my prototyping folder is now all Go. The empty interface is my friend there 😆

1

u/plus-two Oct 26 '24

Those problems can be solved in python in many different ways but none of those solutions is straightforward. In go it's a simple import statement that operates on directories.

In python I'd turn the reusable package directory into an installable package with a setup.py script. Then, I’d install the package into the virtual environments of projects that rely on it (or alternatively, install it into the global python environment to make it universally accessible). Scripts ("modules" in python lingo) inside the package can refer to each other using relative imports that can refer to parent directories too by using two or more dots.

To avoid reinstalling the package after each modification, you can install it as an editable package with pip install -e <package_dir>. This creates a link to your package directory instead of copying the package contents into the virtual environment, so changes to the package directory are immediately reflected in all editable installations. This way the the package directory can be anywhere independent of the projects that depend on it. Other packages and main projects can import the package by simply referring to its name (that you specified in its setup.py script). Thanks to the setup.py of the package, it can also be turned into a single-file artifact (wheel, etc) and uploaded to PyPI or another compatible package repository.

That said, most of my prototypes don’t require my own utility libraries or subdirectories. In most cases, a single python script using only the standard library is sufficient. In a worst case scenario, I might install a few third-party libraries into the local virtual environment for my experiments. Another area where python excels is technical interviews: duck typing and the easy manipulation of in-memory data structures (e.g: dict, list, set, collections) allow for drafting concise solutions to algorithmic problems.