1
lilydjwg 2015-06-09 22:32:18 +08:00
Go 和 Rust 的领域不太一样的。你的目标是什么?
|
2
tonsonxu OP 这一上来,就被move到程序员节点了。。。
|
7
lightening 2015-06-09 22:55:18 +08:00
说实话我觉得 Swift 开源的话,对他俩威胁还挺大。他们两家执行力都比 Apple 差了好多。
|
8
tonsonxu OP @lilydjwg 最看重的是效率,但我觉得C++写起来好啰嗦,我没法做到有效率地开发。。。所以想找个替代品,哪怕做不到C++那种运行速度,只要不是差太远就好。
|
9
ibigbug 2015-06-09 23:35:48 +08:00
我个人觉得,对于 Golang 和 Rust,Google 大法好。
|
10
1oscar 2015-06-09 23:53:59 +08:00
@lightening 已经开源了
|
11
lilydjwg 2015-06-09 23:59:12 +08:00
@tonsonxu 要速度的话就选 Rust 吧,和 C++ 的速度相当(有时快点,有些慢点)。不过 Rust 的类型转换会比较多,错误处理会让你多写不少字(带来的结果是:没有错误被不小心忽略掉没处理)。
@lightening 不要忘记了 KHTML 的遭遇。而且现在开源也太晚了,又没有(让我看到)什么特别的优势。 @1oscar 已经开源了吗?在哪里? |
12
ShiningRay 2015-06-10 00:05:39 +08:00
Rust的社区还没起来吧?连个 Web 框架都没有
|
13
chengzhoukun 2015-06-10 00:08:14 +08:00 via Android
@lightening rust有同步开发的浏览器项目servo啊,苹果的东西不捆绑到iOS上也没啥优势
|
14
WildCat 2015-06-10 00:11:14 +08:00 via iPhone
Swift 如果能在服务端火,我觉得 ARC 这个原因少不了。
|
17
ChiangDi 2015-06-10 00:54:07 +08:00
@1oscar 新闻是说计划开源,但是还没开呢 你是指这个吧 http://www.apple.com/live/2015-june-event/9d2ad033-d197-4009-96a7-2a97fd044cb7
|
18
wezzard 2015-06-10 01:00:28 +08:00
Swift
|
19
lightening 2015-06-10 01:32:10 +08:00 via iPhone
@lilydjwg 优势就是苹果会费力花钱去推动。他有钱有人,开发新 feature 和各种 library 快啊。
|
20
clino 2015-06-10 06:44:26 +08:00 via Android
我挺看好 go的,rust 还不了解
|
21
zeayes 2015-06-10 07:41:10 +08:00
@lightening 感觉苹果不会花费太多的资源去推动swift在服务端的发展,swift开源是一种取悦开发者的姿态,而且swift相比现有的服务端语言没有特别明显的优势。
|
22
lilydjwg 2015-06-10 07:41:26 +08:00
@1oscar 是你根本找不到吧。新闻只说苹果要把 Swift 开源,没说已经开源了。
@lightening 但是不一定是你所需要的。 @df4VW 据说跟 Google 其它一些开源项目一样不太友好: http://blog.csdn.net/liigo/article/details/23699459 |
23
lilydjwg 2015-06-10 07:43:20 +08:00
@ShiningRay 社区早有了啊,光 Rust 本身的贡献者都有一千多人了呢。crates.io 上的库也有两千多了。没起来的是整个生态环境:还处于大量缺库阶段。
|
24
codejsm 2015-06-10 08:59:47 +08:00
都系统学习下,你就有答案。golang比较符合我的口味,rust也很强,两个语言定位不一样。
|
25
nicai000 2015-06-10 09:07:06 +08:00
C程序员Go, C++程序员Rust
|
26
guotie 2015-06-10 09:09:16 +08:00
golang相对简单一些。
|
27
antspeed 2015-06-10 09:41:25 +08:00
golang是google几个大佬领军推出的,还不算google的产品吧,dart才是,不过dart现在前途不明,之前还说要替代js, 现在最新消息也不打算替代js, 方向变更为服务端开发,以及可能会成为安卓的一个基础运行框架? 用dart开发了几个服务程序,不过没有正式使用,个人很喜欢这个语言,pub使用也方便,只是相关的库有点少,希望dart越来越好吧。
|
28
clino 2015-06-10 09:44:38 +08:00
|
32
Bingwa 2015-06-10 10:36:04 +08:00
erlang大法好,配合lua写逻辑
|
33
laotaitai 2015-06-10 10:38:23 +08:00
我觉得题主的语气有点虚, 我认为题主只有用C++敲了许多"Hello Wold"的水平. 所以, 散了吧. 术语也用得虚, 比如"linux服务端高并发和内核引擎".
|
34
cbsw 2015-06-10 10:53:38 +08:00
有人与你有同样的疑问,看看那个vote最高的回复,相信你会收获比较大
http://www.reddit.com/r/golang/comments/394vzq/the_state_of_go_in_market_and_its_future/ |
36
jiazhoulvke 2015-06-10 11:08:02 +08:00
“人生苦短,说Go就Go”
|
37
lilydjwg 2015-06-10 11:39:48 +08:00
|
38
evolighting 2015-06-10 11:53:06 +08:00
@df4VW 毕竟“人类希望”
就算真的很烂那也是有个性的烂,反正google粉丝这么多,不缺人洗白; rust只要不乱搞,从设计目标看来我倒是觉得更好,go只是看起来更酷~~~然而少了些踏实的感觉.... |
39
canesten 2015-06-10 12:00:01 +08:00
golang不适合以计算为主的场景,更适合以IO为主的场景。
剩下的楼主自己斟酌自己的场景偏那一种。 |
40
chaucerling 2015-06-10 12:01:09 +08:00
rust is current, nim is the next
|
41
googollee 2015-06-10 12:03:30 +08:00 4
只要Rust和Swift不在语言层面加入对并发的支持,Go就不会受到本质威胁。如果一门语言不从一开始引入并发,等库多起来再想引入,基本上会被各种库直接阻塞住。这也是为什么Python早就有异步库,但依然被Node.js发展起来的原因。
Go的缺点是在语法上没追求,类型系统(相对于现代语言)过于简单。Javascript的类型系统叫简陋,Rust是复杂。Swift到是比较合适。 不知道Go 2.0版会不会改进类型系统,1.0肯定没戏了,稳定GC和调度器是当前最大的任务。 另外,说Go比Rust慢的,Computer Language Benchmarks Game上看,两者速度差不多。 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust |
42
JQ 2015-06-10 12:05:31 +08:00
2个都学,体会差异比较靠谱。
|
43
googollee 2015-06-10 12:12:43 +08:00
如果楼主目标是linux服务端高并发和内核引擎(偏算法),这两个其实是两个领域。
服务器端高并发,目前一个趋势是少陷核,极端如Google这种已经抛弃内核TCP栈,直接从UDP搞起。这个领域,是Go最初的设计目标,个人认为,也是Go有希望挤掉Java和C++的领域。 内核引擎,别想了,C和汇编。别的语言,等内核里真的有人用了再学不迟。 |
44
hooluupog 2015-06-10 12:14:52 +08:00 1
Go符合我的口味,所以我选了Go,就这么简单。至于为什么符合口味,要自己试过才知道(我经常用它写一些命令行下的小工具,以及爬虫之类的,很趁手性能也符合要求)。
因为这个语言没有什么牛逼炫酷的语法特性来唬人(主要是来自于FP语言的那一坨理论),所以没法吹牛逼,只能说:你自己去试试吧,看看是不是你的菜。 |
45
chingli 2015-06-10 12:20:18 +08:00 via Android
服务器端Go更成熟一点,偏重工程应用,并发支持好,但要看你是否能适应其稍显怪异(个性化)的语法。Rust不了解,好多人喜欢,应该更底层也更复杂一点,各方面比较均衡,最终运行速度应该快于Go。但考虑到Go对并发的良好支持,服务器端运行Go是不会慢的。
|
46
njutree 2015-06-10 13:21:12 +08:00 2
复杂的东西适合当玩具去研究把玩,简单的东西才是真正实用。研究把玩目的就学rust好了,项目应用看需要go更好。很多说go不好用的都没有用go构建过几万行的大项目,只是当玩具玩而已,而go语言的设计就注定它不是一个好玩的玩具,因为它太简单了,一个特性尽量统一用一个方法去实现。完全不像其它语言,有无穷无尽的语法糖和高级用法;以至于你很难知道你写的每个语句是不是最优雅的。这样的语言光语法就够人玩上好久了。然而在工程实践上并没有什么暖用~
|
47
kofj 2015-06-10 13:37:19 +08:00
写内核的话需要C啊,我没听说过Go能做内核开发的。目前正在用Go做开发。
|
48
clino 2015-06-10 15:09:37 +08:00
@googollee "这也是为什么Python早就有异步库,但依然被Node.js发展起来的原因。 "
node.js从语言上说就是javascript,可是javascript在语言层面上也木有并发啊... 即使python语言上支持并发,一样有很多人不想用python的 |
51
guotie 2015-06-10 15:36:29 +08:00
c是不可能被取代的
|
52
googollee 2015-06-10 16:41:53 +08:00
@clino Node.js在语言层面的并发,可以理解成runtime中libuv这一套东西,以及基于此之上的stdlib。这一部分是对Javascript语言的扩展。
|
53
lilydjwg 2015-06-10 17:08:25 +08:00
@googollee Rust 的类型系统还是比较简单的,相对于 Haskell 而言。
从你给出的测试,我只看到了 Go 的代码量少,但是内存占用多。 另外你把协程和并发搞混了。不支持并发的语言很少见了吧,支持多线程就可以并发了,支持多进程的也能,只是不方便。当然 Go 的优势是协程,很轻量。而 Rust 在这方面的优势是,「不作死就不会死」:只要不去欺骗编译器,那么写出来的多线程程序就是安全、没有 race condition 的——当然,如果你有那个能力写出来…… |
54
lilydjwg 2015-06-10 17:12:08 +08:00
|
55
semicircle21 2015-06-10 17:26:04 +08:00
@nicai000
C程序员Go, C++程序员Rust +1 |
56
hooluupog 2015-06-10 18:53:39 +08:00
@semicircle21 用c写的最终还是会用c写的,再说c和rust就不是一个口味。rust明显就是奔着c++去的。
|
57
yuelang85 2015-06-10 19:10:02 +08:00
每问一个人rust如何,回答都是两个字:
复杂 |
58
Feiox 2015-06-10 19:16:55 +08:00
会不会有那么一天,大神们一怒,Linux not only by C ~
|
59
heroicYang 2015-06-10 19:37:20 +08:00
|
60
ensonmj 2015-06-10 21:04:11 +08:00
没啥说的,要找工作,c++ or java
|
62
lilydjwg 2015-06-10 21:37:55 +08:00
@hooluupog 其实我很疑惑,如果 C++ 和 Rust 相似的话,那么为什么 C++ 程序员会倾向于 Rust 呢?C++ 用得很不爽么?
|
63
coetzee 2015-06-10 21:40:26 +08:00
个人浅见:偏向工程化的话就Go,偏向学术化的就Rust,前景的话Swift,另外我认为一个语言具有至少要有一个可以值得放大很多倍的优点,即使有软肋也无妨,JavaScript,Java都是优点和缺点很明显的语言,但是优点确实是顺应时代发展大势
|
64
coetzee 2015-06-10 21:43:23 +08:00
仅就C++来看,一直在进化,其实还是很不错的,很多新语言翻来覆去这么几套东西来回作为卖点来宣传,要么就是学术化太重
|
65
hooluupog 2015-06-10 22:25:37 +08:00
@lilydjwg 不好说。我觉得c++程序员是所有程序员里面宗教化最严重的,所以c++程序员会不会倒戈向rust,需要时间来验证。
|
68
ShiningRay 2015-06-11 18:18:15 +08:00
@heroicYang 哦,看来我 out 了,好久没看了
|
69
kran 2015-06-11 21:32:02 +08:00
小马过河,都试试吧,一天时间足够你做出选择了。
|
70
clino 2015-06-13 20:32:45 +08:00 via Android
我觉得go比较大的问题应该就是gc了,不过这个在不太讲究实时性能的场合可以忽略,如果讲究实时性能则可以针对优化到一定的程度,非常讲究的情况还是不太适合的
其他的go还是挺对我个人的胃口的 |