这是一个创建于 3453 天前的主题，其中的信息可能已经有所发展或是发生改变。
对C++不再有激情，服务器开发或者说后端，Golang还是Rust更有可能壮大起来？
 |
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还是挺对我个人的胃口的 |
Select Language