1. 首页 科技 前瞻 正文

                Go 语言为何不受待见?

                2019年03月24日 23:35:35  来源:CSDN  编辑:王的心事

                原标题:Go 语言为何不受待见?

                Go语言为何不受待见?事实上,Go仍然是一种相当不错的语言,并且逐渐取代Python成为很多?#35828;?#39318;选语言。但是其却有一些问题,使得开发速?#21364;?#21463;影响。本文就跟随作者一起解读下Go?#24515;?#20123;“硬伤”设计。

                作者 | Ben E. C. Boyter

                译者 | 苏本如

                责编 | 郭芮

                出品 | CSDN(ID:CSDNnews)

                以下为译文:

                Go作为一种编程语言来说是相当体面的,然而,我在公司Slack(译者注:一种团队协作工具)的编程频道上对它的抱怨却越来越多(猜到我是做啥?#35828;?#21543;?)。我想?#19968;故前?#36825;些抱怨写下来放在这里,这样当人们问我到底抱怨什么时,我就可以给他们一个链接,让他们直接到这里来看。

                过去一年左右的时间我都一直在大量地使用Go语言来编程,写一些命令行应用程序、scc(https://github.com/boyter/scc/)、lc(https://github.com/boyter/lc/)和一些API等?#21462;?#20854;中包括一个供客户?#35828;?#29992;代码高亮插件(https://github.com/boyter/searchcode-server-highlighter)的大规模API,这个代码高亮插件很快将会在https://searchcode.com/网站中使用。

                我在这里的批评是专门针对Go编程语言的。然而,我对我使用的每种编程语言都有抱怨。这里我引用一下C++编程语言之父Bjarne Stroustrup说过的一句话:

                “世界上只有两种编程语言:一种是人们抱怨的语言,另一种是没人使用的语言。?#34180;狟jarne Stroustrup

                缺乏函数式编程

                我不是一个函数式编程的狂热分子。Lisp语言让我首先想到的是语言障碍,

                这可能是我使用Go语言编程时最痛苦的地?#20581;?/p>

                和大多数开发者不一样,我不想要泛型,我认为这只会给大多数Go项目增加不必要的复?#26377;浴?#25105;想要的是一些可以应用于内置的Slice(切片)和Map类型之上的函数方法。Slice和Map这两种类型都可以容纳任何类型,而且是泛型的,这种在某种意义上很神奇。然而Go的泛型不使用接口的话,就无法实现?#32422;海?#36825;样就损失了所有的安全性和性能。

                举个例子,考虑下面的需求。

                给定两个字符串片断,?#39029;?#36825;两段字符串片断中都包含的相同的子字符串,并将其放入一个新的字符串片断中,以便我们稍后处理它。

                existsBoth := [] string{}

                for_, first := rangefirstSlice {

                for_, second := rangesecondSlice {

                iffirst == second {

                existsBoth = append(existsBoth, proxy)

                break

                }

                }

                }

                上面的Go语言的解决方法很简单。但我们还有其他方法,如使用Map来解决这个问题,使用Map可以减少运行时间,但是如果我们的内存容量有限,或者我们没有很大的片断需要处理,那么额外的运行时间并不足以抵消它带来的复?#26377;浴?/p>

                让我们将其与Java中使用Stream和函数编程来实现相同逻辑的代码比较一下。

                varexistsBoth = firstList.stream()

                .filter(x -> secondList.contains(x))

                .collect(Collectors.toList());

                上面的代码确?#21040;?#31639;法的复?#26377;?#38544;藏起来,从代码上看清楚要实现的逻辑容易得多。

                与实现同样功能的Go代码相比,上面的代码的意图是显而易见的,真正的简洁之处是添加额外的过滤器也变得非常简单。而如果用Go语言实现像下面的示例一样添加额外的过滤器,我们就必须在已经嵌套的for循环中再添加两个if条件。

                varexistsBoth = firstList.stream()

                .filter(x -> secondList.contains(x))

                .filter(x -> x.startsWith(needle))

                .filter(x -> x.length() >= 5)

                .collect(Collectors.toList());

                有一些使用Go Generate的项目可以为你做到上面所说的,但是如果没有好的IDE支持的话,将上面的循环提取到它?#32422;?#30340;方法中会非常笨重,而?#19968;?#24102;来更多的麻?#22330;?/p>

                通道(channel)/并?#26143;?#29255;(Slice)处理

                Go的通道(channel)通常非常简洁。虽然它们存在一些问题会导致它永久阻塞,但它们并不打算提供安全的并发性,因为通过竞争检测机制可以很容易地摆脱这些问题。对于一个不知道有多少个值或何时结束的流,或者如果处理这些值的方法不受CPU的制约,那么通道是一个很好的选择。

                通道不太擅长的是处理那些预先知?#26469;?#23567;并希望并?#20889;?#29702;的切片(Slice)。

                并?#20889;?#29702;在几乎所有其他语言中都很常见,通常发生在你有一个大的列表或切片,使用并行流、并行LINQ(语言集成查询)、Rayon(一种数据并行库)、多进程或其他一些语法,使用所有可用的CPU,对该列表/切片进行迭代处理时。你将它们应用到你的列表上,然后返回处理好的元素列表。如果你的列表有太多的元素,或者你正在使用的函数太复杂,使用一个多核系统应该也可以更快地完成。

                然而,在Go语言中,你需要怎么实现它并不明确。

                一种可能的解决方法是为切片中的每个元素生成一个goroutine。因为goroutine的开销很低,所以在某种程度上,这是一个有效的策略。

                toProcess := [] int{ 1, 2, 3, 4, 5, 6, 7, 8, 9}

                varwg sync.WaitGroup

                fori, _ := rangetoProcess {

                wg.Add( 1)

                gofunc(j int){

                toProcess[j] = someSlowCalculation(toProcess[j])

                wg.Done()

                }(i)

                }

                wg.Wait()

                fmt.Println(toProcess)

                上面的代码会保持切片中元素的顺序,但是我们的例子并不要求实现这点。

                上面的问题首先是添加一个waitgroup,并且必须?#20146;?#36882;增并调用它。这对开发人员开说是额外负担。如果弄错了,这个程序将不会产生正确的输出,可能是不确定的结果,也可能永远不会执行完成。另外,如果你的列表很长,你要为列表中每个单独的元素生成一个goroutine。正如我之前所说,这本身不是一个问题,因为Go语言能毫无问题地做到这一点。但问题是,每一个goroutine都要为使用CPU的时间片而竞争。因?#33487;?#19981;是执?#20889;?#20219;务的最有效方法。

                你可能想做的是为每个CPU生成一个goroutine,并让它?#19988;来?#25361;选处理它的列表。增加一个goroutine的开销很小,但是对于一个迭代?#38382;?#24456;多的循环来说,这个开销并不算小。当我在为scc项目工作时,我遇到了这个问题,它在每个CPU的内核上创建了一个goroutine。如果要完全用Go语言的方式来解决这个问题,你就需要创建一个通道,然后循环你的每个切片元素,让你的函数从该通道读取,然后再从另一个通道读取。

                让我们看看代码。

                toProcess := [] int{ 1, 2, 3, 4, 5, 6, 7, 8, 9}

                varinput = make( chanint, len(toProcess))

                fori, _ := rangetoProcess {

                input <- i

                }

                close(input)

                varwg sync.WaitGroup

                fori := 0; i < runtime.NumCPU(); i++ {

                wg.Add( 1)

                gofunc(input chanint, output []int){

                forj := rangeinput {

                toProcess[j] = someSlowCalculation(toProcess[j])

                }

                wg.Done()

                }(input, toProcess)

                }

                wg.Wait()

                fmt.Println(toProcess)

                上面的代码先是创建了一个通道,循环我们的切片并将每个值放入其?#23567;?#25509;着,为每个CPU内核创建一个goroutine来处理输入的值,然后等待它全?#23458;?#25104;。要消化的代码很多。

                这不是一个你应该怎么做的问题,因为如果你的切片非常大,你可能不想有一个具有相同长度的缓冲区的通道,所以你实际上应该创建另一个goroutine来循环切片,并将这些值放入通道。当处理完成后,它关闭通道。我已经删除了这个代码,因为它使代码变得更长,而且我已经基本上知道怎么做了。

                Java的做法和上面大致相同。

                varfirstList = List.of( 1, 2, 3, 4, 5, 6, 7, 8, 9);

                firstList = firstList.parallelStream()

                .map(this::someSlowCalculation)

                .collect(Collectors.toList());

                是的,Go语言的通道(channel)和Java中的流(stream)并不是一回事,通道更接近于Java中的队列(queue),但我们这里的目的不是1对1的对?#21462;?#25105;们想要的是使用我们所有的CPU内核来处理一个切片/列表。

                当然,如果某个slowcaluation实际上是一个在网络上调用的方法,或者是其他一些需要大量CPU的方法,那么这就不是一个问题。在这种情况下,通道和goroutine都很出色。

                这一问题与缺乏函数式编程有关。如果Go语言在slice/map对象之上有函数方法,那么添加这个功能是可能的。这也很烦人,因为如果Go支持泛型的话,就会有人可以把上面谈到的写成一个函数库,就像Rust的Rayon一样,每个人都会受益。

                ?#28526;?#35828;一句,我认为这一点阻碍了Go语言在数据科学领域的任何成功,因此,为什么Python仍然是那里的王者。而Go语言在数字操作中缺乏表现力和力量——以上就是原因。

                垃圾回收(GC)

                Go语言的垃圾回收机?#21697;?#24120;可靠。?#30475;蜧o语言版本更新,我都发现我的应用程序变得更快了,原因通常是因为GC的改进。将延迟的优先级置于所有其它要求之上,对于API和UI来说,是一个完全可?#36234;?#21463;的选择。同样地它也适用于任何有网络呼叫的情况,这些呼叫?#19981;?#25104;为瓶颈。

                关键是Go语言对UI功能的实现没有任何?#20040;Γ?#25454;我所知没有合适的绑定),当你需要尽可能大的吞吐量时,这个选择确实会伤害你。我在处理scc项目时遇到了一个大问题,scc是一个命令行应用程序,对CPU的要求很高。这是个问题,我添加了一个逻辑来关闭内存回收机制,直到内存使用?#30475;?#21040;阈值。但是,我不能禁用它,因为程序在某些情况下工作时很快就会耗尽内存。

                对GC缺乏控制有时令?#21496;?#20007;。你学会了接受它,但有时你会说“嘿,这里的代码真的需要尽可能快的运行,所以如果?#33454;?#25442;到高吞吐量模式一?#38382;?#38388;,那就太好了。”

                我认为随着Go语言的1.12版本的发布,这一点变得越来越不可能了,在这个版本中,GC看起来再次得到了改进,但是仅仅关闭和打开GC并不是我想要的控制。有时间的话?#19968;?#20877;次深入了解一下。

                错误处理

                我不是唯一一个对这点有抱怨的人,但我必须写出来。

                value, err := someFunc()

                iferr != nil{

                // Do something here

                }

                err = someOtherFunc(value)

                iferr != nil{

                // Do something here

                }

                上面的代码看起来相当乏味。Go语言甚至不强制你处理大家建议的错误。你可以显式忽略它(这是否算作处理它?),你甚至可以完全忽略它。例如,我可以像这样重写上面的内容:

                value, _ := someFunc()

                someOtherFunc( value)

                你很容易发现我省略了somefunc返回的内容,但是someotherfunc(value)同时也可以返回错误,而我却完全忽略了这个错误,对它不作任何处理。

                老实说,我不知道有这里有什么解决办法。不过我?#19981;禦ust言语的问号(?)操作符,它可以避免这个问题。另外V-Lang(https://vlang.io/)看起来也可能有一些有趣的解决方案。

                另一个想法是可选类型(Optional Type)和删除nil,但是这些在Go语言的2.0版本中是永远不会出现的,因为它会破坏向后兼容性。

                总结

                总的来讲,Go仍然是一种相当不错的语言。如果你要我要写一个API,或者一些需要快速进行大?#30475;?#30424;/网络调用的应用,它仍然是我的第一选择。事实上,我正处在这样一个阶段:Go已经取代Python,成为我要完成的大量的一次性任务的首选语言。数据合并任务除外,因为缺乏函数式编程仍然是一件痛苦的事情,这使得开发速?#21364;?#21463;影响。

                对诸如像字符串stringA == stringB和编译错误的比较,你会发现Go语言的切片用在这里非常合适。它不像我在上面用来比较的Java语言那样经常有出人意料的结果。

                Go的二进制文件的大小可以更小(一些编译开关和upx(可执行文件压缩工具)可?#36234;?#20915;这个问题),我希望它在某些方面运行得更快一些,GOPATH不是很好,但也没有每个人所说的那么糟糕,默认的单元测试框架缺少很多功能,Mocking有点痛苦等?#21462;?/p>

                Go仍然是我使用过的一种更有效的语言。?#19968;?#32487;续使用它,尽管我希望https://vlang.io/最终能够发?#30142;⑶医?#20915;我的许多?#31471;?#30340;问题。它可能Go 2.0版,可能是Nim,也可能是Rust。现在有很多很酷的新语言可以玩。我们的开发人员真的被宠坏了。

                原文:https://boyter.org/posts/my-personal-complaints-about-golang/

                举报本文
                +10
                +10

                依据《信息网络传播权保护条例?#36820;?#20108;十二条之规定,即“避风港原则?#20445;?#26412;站所有文章及内容系第三方作者上传,如有侵权行为请及时联?#24403;?#31449;客服删除,本站不对内容传播行为承担赔偿责任。

                跟贴 0
                参与 0
                发贴
                网友评论仅供其表达个人看法,并不表明E都市立场。
                11选5任3必中计算方法