Permalink to this article – https://ift.tt/0M7gJDG
I recently read the article “The Tao of Go” by John Arundel . After reading it, I have the heart to read the Tao Te Ching again :). The author organically linked the Go language design philosophy and conventions with the three treasures of “Tao” learning, which gave me a lot of inspiration. It is translated into Chinese here for your reference.
You can let the buffalo go anywhere they want – Gerald Weinberg , The Mystery of Consulting
“Tao” refers to the inner essence or natural tendency of things . For example, water flows downhill: this is the “way” of water. You can dam, divert, pump, or otherwise interfere with it, but despite all your efforts, it may end up where it’s going.
You follow the “Tao” as your principle of doing things, which is to be sensitive to the natural trend of things, not to waste energy fighting against it, but to follow the trend, not against it .
Expanding on the water analogy, a bad swimmer flutters in the water, making a lot of noise and commotion, but not really moving forward. Taoism, on the other hand, is surfing in the water.
So what is the way of the Go language ? What would it look like if we approached software development in Go in a sensitive, intelligent way, following the natural contours of the language and the problem, rather than trying to bulldoze them away? Let’s try to establish some general principles .
1. Kindness
I have the Three Jewels, keep and keep them. The first is kindness, the second is simplicity, and the third is humility. – Tao Te Ching
What does it mean to program with kindness and compassion? It means we write code for people, not computers . Humans are fallible, impatient, inexperienced, inattentive, and otherwise imperfect. We can make everyone’s life (and work) easier by putting some thought into the design and details of Go code .
We can be kind to our users: give our libraries descriptive names, make them easy to import, provide good documentation, and give them a permissive open source license. We can design deep abstractions that allow users to leverage small and simple APIs to access powerful and useful behaviors.
We can be kind to those who run our programs, make them easy to install and update, require minimal configuration and dependencies, catch the most common usage errors and runtime errors, provide users with useful, accurate and friendly information, tell What is wrong with them and how to fix it.
Smartness is a gift, kindness is a choice. – Jeff Bezos
We can be kind to those who have to read our code by being as clear, simple, and explicit as possible. We can give types and functions names that make sense in the context, allowing users to create their own programs in direct, logical combinations using our abstractions. We can remove cognitive barriers and speed barriers by following conventions, implementing standard interfaces, and doing the obvious in obvious ways.
In code reviews, we remain moderate and use encouraging language. We find praise in other people’s work, and we don’t take them for fools because they make mistakes or ignore details. If we are honest with ourselves, we will admit that we too make the same mistakes. We also know that accepting criticism is painful and difficult for us, but we can adjust to it with kindness.
Finally, we also have to be kind to ourselves, by writing good tests that make our programs easy to understand, fix, and improve in the future, and don’t get angry with ourselves when we find bugs or design flaws.
Once the code repo becomes spaghetti, it’s nearly impossible to fix. – John Ousterhout, The Philosophy of Software Design
Another way to be kind to our future selves and our successors is to make small, continuous improvements to the program’s structure and overall design. Good programs live a long time (and, of course, some bad ones do), and the cumulative effect of many small changes often makes codebases cluttered, complex, and unwieldy. We can take a little extra time to help avoid this, and whenever we hit the codebase for something, we can refactor and clean it up. Because we rarely get the chance to rewrite a system from scratch, investing a small amount of time in micro-improvements over the long term is the only practical way to keep the system healthy.
2. Simplicity
The second virtue that Tao teaches us is frugality, modesty, and simplicity: to be small and big, to eliminate clutter. Go itself is a “thrifty” language with less syntax and surface area. It doesn’t try to do everything, or please everyone .
Our lives are wasted on trivial details. Simplify, Simplify” – Henry David Thoreau , “Walden”
We should do the same, keep our programs small and focused, not cluttered, and do one thing well. Deep abstraction provides a simple interface to powerful machines. We don’t make users do a lot of paperwork in order to gain privileges to call our library. As long as we can provide a simple API and sensible defaults for the most common cases, we will.
Flexibility is a good thing, but we shouldn’t try to handle every situation, or provide every feature. Extensibility is nice, but we shouldn’t compromise a simple design for something we don’t need right now. In fact, a simple program is easier to extend than a complex program.
I have the easiest flavors. I’m always happy with the best stuff. – Oscar Wilde, quoted in Edgar Saltus, “Oscar Wilde, the impression of an idler”
We don’t overwhelm users with functions, types, interfaces, callbacks, parameters, and functional options. The smallest API is best because it requires the least knowledge to use. We won’t complicate our modules with dozens of packages and subfolders of subfolders. We don’t resort to endless command-line flags or require users to write lengthy configuration files.
We’re content with repeating chunks of code rather than inventing unnecessary abstractions purely to satisfy our desire to keep our code dry. If we can solve the problem by implementing the same function for several different types, we don’t write complex code generators or generic functions. more concise). If a method is naturally a bit long, we make it long instead of aggressively refactoring it into unnecessary sub-functions, just to make each sub-function a few lines long.
If one is enough, we don’t write ten tests. If we only need a function, we don’t create an interface. Instead of making users implement our interface, we want to implement theirs.
The way out is through the door. Why is it that no one will use this method? — Confucius
We are explicit/explicit; we avoid magic. We don’t use concurrency where it doesn’t help. We make packages self-contained and decoupled from other packages, and we avoid letting the type of one package or API leak into other parts of our codebase. We set clear internal and external boundaries and enforce them.
We conserve resources; we avoid leaks and use as little memory or CPU as possible when necessary. We process data streams efficiently instead of putting them into large chunks of memory. The less garbage we generate, the less we need to collect. We don’t pass Context where we don’t need it.
We don’t dwell on performance issues. Go is performant. But our code probably doesn’t need to be that fast; at least, it doesn’t need to trade simplicity for high performance.
As the Go proverb says: we accept interface values. This way we need to make minimal assumptions about what they are, but we return concrete values (structs) so the user doesn’t have to write a lot of type assertions for them.
3. Humility
The third treasure is humility. Like water, Taoism seeks to keep a low profile, not to argue, not to compare, not to try to impress others. Go itself is unassuming and pragmatic: it doesn’t have the high-tech features and theoretical advantages that other languages have. In fact, it deliberately ignores many important selling points of other languages. Its designers were not interested in creating an impressive programming language or ranking at the top of popularity surveys, but wanted to provide people with a small and simple tool to do useful things in the most practical and straightforward way possible. Work.
Go recognizes that we are fallible, so it provides many ways to protect us from making mistakes. It takes care of allocating memory, cleaning up what we’ve used up, and warning us about unused package imports or variables. It’s a language for those who know they don’t know everything, and who understand their wrong tendencies (in other words, the humble person).
The most dangerous mistake is not recognizing our own wrong tendencies. – Basel-Liddell-Hart
As Go programmers, we write code without appearing to be overly smart, and this is how we stay humble. We don’t write code to impress people how great programmers we are: instead, we settle for the obvious. We express ourselves clearly and directly without feeling the need to impose our own personality on the code.
We use the standard library when it solves a problem, and use a third-party library only when it doesn’t. If there’s a de facto standard package, we use it: if it’s good enough for others, it’s good enough for us.
We avoid accidentally terminating the user’s program by panicing or calling os.Exit or log.Fatal because we recognize that we are not smart enough to determine in advance whether a problem is truly fatal. Instead, we handle everything we can when a problem occurs, and when we can’t, we humbly return an error with useful contextual information for our users to decide how to handle.
We can recognize that we don’t know everything, and we can’t make very accurate predictions (especially for the future), so we shouldn’t waste time and effort pre-engineering things we may never need. We don’t think we know best whether other software will want to use it with ours, so we don’t impose a reliance on it.
We assume that anything we write will contain bugs, so we write exhaustive test code in an attempt to elicit unexpected behavior or incorrect results. We understand that there will inevitably be important things that we don’t know or can’t predict correctly, so we don’t optimize code too much for the status quo because a lot of the work ends up being wasted.
As a student (keep learning), never feel grown up without asking questions, never feel like you know too much and refuse to learn new things. – Og Mandino, author of The World’s Greatest Salesman
When we review other people’s code, we don’t automatically assume we know best: we’re happy to learn from anyone who has something to teach us. If something seems odd or wrong, we ask, “From what point of view does this make sense? I don’t have any information to explain why this is necessary?”
We take our comments as questions, asking them in a sincere, rather than sarcastic, way: Is it necessary? What if…? Have you ever considered…? Wouldn’t it be better if…? We respect other people’s time as much as our own, so we don’t ask them for unnecessary information, or make small changes just to fit our preferred style, or sit and waste time in walk-in meetings, Or write redundant status reports.
We know we’re not always right. Wise people can dispute things in a civilized and constructive way. If we treat people as idiots, we shouldn’t be surprised when they don’t respond well. Instead, we start by assuming that the other person is rational, decent, and acting in good faith according to their best understanding of the situation. Sometimes this isn’t the case, but it remains the correct default assumption until they finally prove otherwise.
We humbly review our own code before asking others to review it, because why would they do it if we were too lazy to do it? We take the time to read line by line, read like a new user or developer, and follow logic one by one: Is it clear where to start? Does the program introduce key types or constants at the outset and explain how they are used? Did the naming clearly and precisely designate what they do, or did they become confusing and outdated over a dozen refactorings? Does the program fit neatly and naturally into its structure, or is it over-stuffed in some parts and strangely left blank in others?
Because we’re not bound by our own cleverness and grace, we don’t need to cram three or four different ideas into a single line of code. Instead, we lay out the logic clearly, simply, and explicitly, step by step, stating one by one, bit by bit, doing exactly what is necessary in the way the reader expects. Where this is not possible, we take the trouble to explain to readers what they need to know to understand what is going on.
Because we know we’re not geniuses and we can’t write programs so well that it’s self-explanatory, we put some effort into explaining it. We provide documentation for the code, explaining not only what the program does, but how it can be used to accomplish what the user might want to do. The documentation also contains detailed usage examples showing exactly what needs to be done, from scratch, to perform a realistic task, what users should expect to see when it’s done, and what they should do next, and we strictly Check these examples regularly to make sure they are still valid.
4. Not Striving
We’ve touched on some ways to apply the three treasures of kindness, simplicity, and humility to writing software in Go. These qualities are already present in everyone, even if they are well hidden in some. Likewise, everyone already knows how to follow the “Tao” in programming and in life. Indeed, they can’t help but do so. But once you understand that fact and stop struggling like this with everything, life becomes a lot more interesting.
The last teaching the Tao teaches us is not striving . This is sometimes misinterpreted as lazy, withdrawn, or passive; quite the opposite. Hard work doesn’t always mean good work. We all know people who are chronically busy, always in a hurry, chaotic, and active, but they never seem to actually achieve anything. And, they were miserable because they knew it too.
Instead, we often do our job at our best when others see us as doing nothing: taking a walk by the river on a beautiful day, or sitting on a porch and watching spiders spin their webs. If we wisely take a break from our busyness, it only takes a minute for the right idea to appear directly in our minds.
Instead of treating every problem as an enemy to attack, a mountain to climb, or a wall to tear down, we can use the principle of “doing nothing” (sometimes “not forcing” is a better translation). We’ve all probably had the embarrassing experience of pushing a stubborn door fruitlessly, only to realize in the end that it responds better to a pull. What are the little signs that we should be pulling instead of pushing in our day-to-day work?
A problem-solving mindset is good, but eliminating the problem is even better. How can we reframe this problem so that it goes away? A restatement of requirements would make the solution trivial, or even obvious? Is there a simple and elegant design that we’re not seeing because we focus on some details that prove to be irrelevant? Can we solve this problem without trying? The best optimization is to not do it at all.
It is a common mistake to confuse programming with typing. If someone is just sitting there staring at the space, it doesn’t seem like they’re doing anything useful. But if they’re pounding like crazy on the keyboard, we think they’re doing something. In fact, the real programming happens before, and sometimes replaces, typing. When we conceive of a very good program, the only key we need to press is often the delete key.
What’s really interesting is that you don’t need to take my word for it to prove the validity of Taoist principles in programming, or in other areas of life. The world itself will teach you what works and what doesn’t, and how to tell them apart. Do a little experiment in exercising your kindness, simplicity and humility and see what happens and how it feels.
You don’t have to call it “Tao” if that annoys you. It’s just a made-up word. If you always know there is a right way and a wrong way to do things, and you think I just used a fancy Chinese name without saying anything new or valuable, you are right.
The next time you have a problem, try not trying or forcing once and see if you can gently encourage the problem to solve itself. If you find yourself struggling to get your buffalo where you want to go, look no further. Ask yourself if you can find where the buffalo wants to go, maybe that might not be the best location for it.
“Gopher Tribe” Knowledge Planet aims to create a high-quality Go learning and advanced community! High-quality first published Go technical articles, “three-day” first published reading rights, analysis of the current situation of Go language development twice a year, read the fresh Gopher daily 1 hour in advance every day, online courses, technical columns, book content preview, must answer within six hours Guaranteed to meet all your needs about the Go language ecosystem! In 2022, the Gopher tribe will be fully revised, and will continue to share knowledge, skills and practices in the Go language and Go application fields, and add many forms of interaction. Everyone is welcome to join!
I love texting : Enterprise-level SMS platform customization development expert https://51smspush.com/. smspush : A customized SMS platform that can be deployed within the enterprise, with three-network coverage, not afraid of large concurrent access, and can be customized and expanded; the content of the SMS is determined by you, no longer bound, with rich interfaces, long SMS support, and optional signature. On April 8, 2020, China’s three major telecom operators jointly released the “5G Message White Paper”, and the 51 SMS platform will also be newly upgraded to the “51 Commercial Message Platform” to fully support 5G RCS messages.
The famous cloud hosting service provider DigitalOcean released the latest hosting plan. The entry-level Droplet configuration is upgraded to: 1 core CPU, 1G memory, 25G high-speed SSD, and the price is 5$/month. Friends who need to use DigitalOcean can open this link : https://ift.tt/VwY61nJ to open your DO host road.
Gopher Daily Archive Repository – https://ift.tt/nVXCxu4
my contact information:
- Weibo: https://ift.tt/wJ3ZQoC
- Blog: tonybai.com
- github: https://ift.tt/7JkKNS5
Business cooperation methods: writing, publishing books, training, online courses, partnership entrepreneurship, consulting, advertising cooperation.
© 2022, bigwhite . All rights reserved.
This article is reprinted from https://tonybai.com/2022/09/25/the-tao-of-go/
This site is for inclusion only, and the copyright belongs to the original author.