锁定老帖子 主题:Go-lang特性介绍
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2010-01-22
chaoslawful 写道 xuby 写道 任何不能和C兼容的系统级编程语言,都没有前途可言。
三十多年的C资产积累,不可能被轻易抛下。 确实,我觉得go这类语言(包括scala)的最大问题是:为了使用新建的actor调度模型,所有直接同系统交互的外部库都需要重写,以避免系统调用时同时阻塞大量actor的执行过程。 cgo还是很强大的 go程序和c模块直接链接编译呀 |
|
返回顶楼 | |
发表时间:2010-01-22
其实我要说go就是个better C,如果只是better C,我觉得我至少不需要,不知道谁需要。;
|
|
返回顶楼 | |
发表时间:2010-01-22
等google内部都开始go了再说
|
|
返回顶楼 | |
发表时间:2010-01-22
jetthink 写道 等google内部都开始go了再说 等大路货了再学 就没价值了... |
|
返回顶楼 | |
发表时间:2010-01-22
chaoslawful 写道 bcccs 写道 mryufeng 写道 非常有前途的一门语言 有兴趣的同学一起来研究哦... 语言排行 目前第13, yeah Go有两种编译器,其中cgo用gcc backend,优化更好,但coroutine是直接 映射到thread上,结果被Stackless Python的用户嘲笑了一番:编译比C 慢,而运行比Python慢。 “coroutine直接映射到thread上”这个怎么讲? 我看目前goroutine实际的实现很类似于erlang的轻量级进程,同样是将大量goroutine(内部简写为g)交给多个scheduler线程(内部简写为m)调度处理,当某个goroutine内发生系统调用时,其他ready的goroutine会交给空闲的或新创建的scheduler线程继续处理(新建scheduler线程不退出,形成自动增长的scheduler线程池),而当前scheduler线程会阻塞等待系统调用返回。调度期间并没有可见的大开销,跑的又是native code,如果比stackless python慢就有点儿匪夷所思了。 人家说的是gcc backend的cgo. |
|
返回顶楼 | |
发表时间:2010-01-22
bcccs 写道 mryufeng 写道 非常有前途的一门语言 有兴趣的同学一起来研究哦... 语言排行 目前第13, yeah Go有两种编译器,其中cgo用gcc backend,优化更好,但coroutine是直接 映射到thread上,结果被Stackless Python的用户嘲笑了一番:编译比C 慢,而运行比Python慢。 好东西用用才知道... |
|
返回顶楼 | |
发表时间:2010-01-22
goroutine和erlang process差不多
可是go不是变量不可变,出错的概率就大了 另外我没有看出他有什么特别的特性是很有价值但erlang所不具备的 |
|
返回顶楼 | |
发表时间:2010-01-23
go那个吉祥物压根就是plan9一家的 土豆状啮齿类动物
|
|
返回顶楼 | |
发表时间:2010-01-23
seen 写道 go那个吉祥物压根就是plan9一家的 土豆状啮齿类动物
连大量代码都是从plan9直接移植的。就算有google的招牌,估计会成为失败滴产品。 |
|
返回顶楼 | |
发表时间:2010-01-23
Trustno1 写道 mryufeng 写道 非常有前途的一门语言 有兴趣的同学一起来研究哦... 语言排行 目前第13, yeah
问题是名字起得不吉利 Go-lang=够烂? 或者说Go 浪 |
|
返回顶楼 | |