When did Go get generic types?
Go 何时获得泛型类型？
The Go 1.18 release added type parameters to the language. This permits a form of polymorphic or generic programming. See the language spec and the proposal for details.
Go 1.18 版本向该语言添加了类型参数。这允许某种形式的多态或通用编程。有关详细信息，请参阅语言规范和 提案。
polymorphic
adj. 多形的，多态的，多形态的;多晶形;
Why was Go initially released without generic types?
为什么 Go 最初发布时没有泛型类型？
Go was intended as a language for writing server programs that would be easy to maintain over time. (See this article for more background.) The design concentrated on things like scalability, readability, and concurrency. Polymorphic programming did not seem essential to the language's goals at the time, and so was initially left out for simplicity.
Go 的目的是作为一种用于编写易于维护的服务器程序的语言。（有关更多背景信息，请参阅本文。）设计重点关注可扩展性、可读性和并发性等方面。多态编程对于当时的语言目标来说似乎并不重要，因此最初为了简单起见而被排除在外。
concentrated
adj. 集中的;全神贯注的;浓缩的;汰选出来的;
v. 集中(concentrate的过去分词);聚集，集结;凝缩，浓缩;[矿]汰选;
Generics are convenient but they come at a cost in complexity in the type system and run-time. It took a while to develop a design that we believe gives value proportionate to the complexity.
泛型很方便，但代价是类型系统和运行时的复杂性。我们花了一段时间才开发出一种设计，我们相信这种设计的价值与复杂性成正比。
Why does Go not have exceptions?
为什么 Go 没有异常？
We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.
我们认为，将异常耦合到控制结构（如try-catch-finally惯用语中那样）会导致代码变得复杂。它还倾向于鼓励程序员将太多普通错误（例如无法打开文件）标记为异常错误。
coupling
n. [电]耦合;联结;[机]管箍;（火车的）车钩;
v. 连接(couple的现在分词);
idiom
n. 习语，成语;方言，土语;（语言）风格;惯用语法;
convoluted
adj. 盘绕的，卷曲的;复杂的;
v. 回旋，卷绕，盘旋( convolute的过去式和过去分词 );
label
n. 标签;标记;称谓;唱片公司;
v. 贴标签于;用标签表明;（尤指不公平地）把…称之为;
Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.
Go 采用了不同的方法。对于简单的错误处理，Go 的多值返回可以轻松报告错误，而无需重载返回值。 规范的错误类型与 Go 的其他功能相结合，使错误处理变得令人愉快，但与其他语言中的错误处理有很大不同。
approach
v. 接近，临近;对付，处理;接洽，要求;
n. 方法，方式;接近，来临;接洽，要求;途径，道路;相似的事物;
canonical
adj. 权威的;见于<圣经>正经篇目的;大教堂教士的;按照教规的;
Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.
Go 还有一些内置函数来发出信号并从真正的异常情况中恢复。恢复机制仅作为错误后被拆除的函数状态的一部分执行，这足以处理灾难，但不需要额外的控制结构，并且如果使用得当，可以产生干净的错误处理代码。
See the Defer, Panic, and Recover article for details. Also, the Errors are values blog post describes one approach to handling errors cleanly in Go by demonstrating that, since errors are just values, the full power of Go can be deployed in error handling.
有关详细信息， 请参阅延迟、紧急和恢复一文。此外，错误是值博客文章描述了一种在 Go 中干净地处理错误的方法，通过演示，由于错误只是值，因此可以在错误处理中部署 Go 的全部功能。
Why does Go not have assertions?
为什么 Go 没有断言？
Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.
Go 不提供断言。不可否认，它们很方便，但我们的经验是，程序员将它们用作拐杖，以避免考虑正确的错误处理和报告。正确的错误处理意味着服务器在非致命错误后继续运行而不是崩溃。正确的错误报告意味着错误是直接且切题的，使程序员无需解释大量的崩溃跟踪。当看到错误的程序员不熟悉代码时，精确的错误尤为重要。
crutch
n. 拐杖;支持物;精神上的寄托;胯部;
We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.
我们知道这是一个争论点。Go 语言和库中有很多与现代实践不同的东西，仅仅是因为我们觉得有时值得尝试不同的方法。
