![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Frequently Asked Questions
黄慢慢manman
Java修炼中
展开
-
Frequently Asked Questions: Go的map操作为什么不定义为原子操作
Go的map操作为什么不定义为原子操作? 经过漫长的讨论,我们决定maps平常的使用不需要保证多协程的并发安全。而当需要考虑多协程并发安全的时候,往往map是一个更大的数据结构或者计算过程的一部分,这这些早就被同步锁住了。因此如果要求所有的map操作都先获取一个互斥锁反而会降低大部分程序运行速度,而换来一丁点儿的安全提升。这其实不是一个简单的决定,因为它意味着不受控制的map设计可能会导致程序崩溃。 Go后续版本不会排除原子实现map。当需要的时候,比如运行一个不信任的代码的时候,一些方法可以实现map的访原创 2021-06-11 22:25:03 · 277 阅读 · 0 评论 -
Frequently Asked Questions :Go为什么用协程替代线程?
Go没有提供断言。不可否认,断言十分方便。但是按我们的经验来看,程序员往往会因为不想思考如何更好的处理异常,而滥用断言。更好的异常处理意味着,当服务遇到非致命的错误,仍然会继续运行。精确的错误类型会让程序员定位错误更加快速。 我们知道这是一个争议点,Go语言和其他现代语言有许许多多不同点,也是因为我们认为这些设计是值得做的尝试。 ...原创 2021-06-02 23:15:53 · 165 阅读 · 0 评论 -
FAQ : Go为什么没有异常
我们认为把“异常”(exception)机制设计成一个控制结构(control structure)(PS:理解为闭环是否会好一点?)会让代码变得很复杂,例如常见的try-catch-finally的设计。这种设计隐性在鼓励人们把一些诸如打开文件失败等常见的错误,当成是异常。 Go采用了一种不一样的设计。对于简单的错误处理,通过Go的多值返回特性能够让报告一个错误变得简单,而且这样不会重载返回值。(PS: 在Java中通过throws exception来实现报告错误,Go是通过直接return error原创 2021-05-26 00:05:52 · 300 阅读 · 0 评论 -
Frequently Asked Questions :Go为什么没有泛型?
Go为什么没有泛型 详细可以见issue:https://github.com/golang/go/issues/43651 ,这个issue已经被认同,不出意外的话在Go的1.18版本就能支持泛型了。 Go希望被设计为一个能够被容易持续运行很久的服务端语言(详细可参考这篇文章https://talks.golang.org/2012/splash.article),因此设计的时候聚焦于可拓展性、可阅读性和并发性上,因此当时看来多态编程并不是必不可少的,所以就忽略了。 现在语言原来越成熟完善,可以开始考虑泛原创 2021-05-23 23:47:34 · 189 阅读 · 0 评论 -
Frequently Asked Questions :Go为什么没有一些某某特性?
Go为什么没有一些某某特性? 每一种语言要么会有一些新颖的设计,当然也可能会忽略一些人们喜欢的设计。Go语言设计时希望做到更好的编程体验,更快的编译速度,正交性的概念( orthogonality of concepts),以及能够做到基本的并发、垃圾回收。基于以上设计考虑,你所喜欢的特性可能在Go语言中就不那么合适,因为它们或多或少降低了编译速度、降低了设计的整洁,也可能会让基础系统架构变得很复杂。 如果因为Go少了某些你想要的特性,请原谅我们,也希望您更加关注Go独特的一些特性。探索这些特性也许会让你感原创 2021-05-23 23:14:51 · 66 阅读 · 1 评论 -
Frequently Asked Questions : GO有“运行时”设计吗?
GO有“运行时”设计吗? Go是有“运行时”库(runtime)的,它是每一个Go程序不可缺少的一部分。“运行时”库实现了垃圾回收、并发、栈管理以及其他Go重要的特性。Go的“运行时”库类似于C语言的libc库。 但是要知道一点,Go的“运行时”库并不是指虚拟机的设计,这点和Java的“运行时”设计不同(PS:Java的“运行时”,是指JVM)。因为Go程序会提前编译为原生机器代码(可能会是Javascript、WebAssembly…),所以,尽管“运行时”通常描述为某种程序运行的虚拟环境,但是在Go中,原创 2021-05-20 22:51:42 · 200 阅读 · 0 评论