Rust语言介绍 -解道Jdon
& & & &&& & &
　　Rust语言是一个极其讲究精致的系统级别语言，它瞄准的是取代C/C++，语言的发展和变化很快， 本文介绍Rust语言的优缺点以及与其他语言的大概比较。
　　首先是没有GC的内存安全型，对于低级系统级的编程语言，直接内存操作是允许的，在运行时出现内存错误如use-after-free或内存泄漏的代价是昂贵的，虽然C++提供很好的工具来处理它，但是这还是需要工程师的纪律，在大型系统中就不难很好解决这个问题。垃圾回收GC是解决内存安全的最普通方式，但是Rust系统并不依靠GC，而是在编译时通过(Resource Acquisition Is Initialization)实现资源自动释放，这样不但能提供内存安全，还提供数据和资源安全。这样能降低开发者手工管理内存的必要，能够自动确保清理工作总是在运行，甚至当任务出现崩溃恐慌时。
　　动态语言如Python和Ruby也提供类似能力，但是没有Rust这样强大。
　　第二个优点是无需竞争的并发，Rust能够确保在并发编程中的数据安全，某个时间点同时只能有多个读操作或一个写操作被允许访问共享数据。
　　第三个优点是提供代数数据类型，除了tuple struct类型以外，Rust还提供enum和模式匹配，这些都是高级类型系统才拥有的功能如今出现在系统级的编程语言中。
　　第三个优点是基于继承的组合，Rust能基于继承实现组合，Trait是Rust泛型中重要角色。
　　水至清则无鱼，对于Rust编译器，每件事都必须得清清楚楚，当遇到灰色情况它会拒绝编译，直至你搞清楚它，这对于代码质量是一个好事情，但是对于讲究开发效率的项目来说就是有点苛刻了。
　　第二个缺点是GC是二等公民，Rust提供基本的GC(RC)，如引用计数 自动计数(Arc)，并没有循环检测，它们并不是语言中第一等公民，你最终只能使用Rust的内存管理(stack 和Box)。
　　第三个缺点是富有表现力不是其目标，充满像动态语言那样富有表现力和优雅不是Rust的目标。
　　第四个缺点是门槛高，Rust并不是你能在几周内捡起学习马上就精通的那种语言，Rust也许小于C++，但是它的定义比很多语言要大，它不一定适合大多数人群，从另外方面看，门槛高也是过滤器，可以保证代码高质量。
与其他语言比较
　　与动态语言或脚本语言比较，它们的目标是不同的，动态语言适合快速原型或立即完成实现的任务，而Rust适合大型团队，需要很长的产品周期，长期不断进行维护重构的项目。
　　动态语言让你起步很快，代价会在后期偿还，而Rust编译器一开始就强迫你正确细节地做事，时间长了效率会不断提高。
　　与Go语言比较，Go语言相比Rust太简单，太小型化了，Go适合企业软件开发，类似以前的java，另外Go语言是由Google推动的，如果以后公司利益与社区利益冲突如何处理？而Rust则是由非营利组织Mozilla 推动的。
　　与 (正式名称 Nimrod)比较，Nim能编译到C，这样它的性能很好，它非常酷似Python，它是GC语言，但是实时提供对GC行为更多预测，最大的问题是生态系统和成熟度，有待发展和健全。
和语言比较，Julia是一个拥有好的性能的动态语言，提供REPL和平滑的C调用，它在数字和科学领域比较受欢迎，不是一个通用目标的语言。D语言目标是一个更好的C++，但是其实使用范围不广，几个原因： 早期的Phobos/Tango分离，内存安全完全依赖垃圾回收GC，只不过是一个更好的C++。
　　Rust语言是一个系统级的语言，未来也许发展对Web的支持。
| 网站地图 | 设为首页Rustlang语言逐行处理文件的基本方法 - ledao - 博客园
随笔 - 22, 文章 - 0, 评论 - 0, 引用 - 0
将文件中的内容按行读取出来，然后对改行的数据进行处理，最后将处理后的行数据存放到新的文件中。
使用来处理的方法如下。
首先引入需要的标准库：
use std::io::prelude::*;
use std::fs::F
use std::io::BufW
use std::io::BufR
然后将处理函数放到一个函数中，这是我处理小问题的习惯。
定义一个函数，
fn&man()&{
将我们的实现代码放到上述的花括号中，首先试一下读取一个文件，代码如下。
use std::io::prelude::*;
use std::fs::F
use std::io::BufW
use std::io::BufR
fn main() {
let file = File::open("./data.dat").unwrap();
let mut fin = BufReader::new(file);
let mut line = String::new();
fin.read_line(&mut line).unwrap();
println!("{}", line);
首先，通过标准库的一个文件，然后通过获得文件。打开一个文件之后，再定义一个，用于读取文件的内容。读取的东西放到一个中，然后通过函数读取文件的一行。最后打印出来读取的内容，看看是否读取成功。
现在，我们要读取文件的整个行，代码如下。
use std::io::prelude::*;
use std::fs::F
use std::io::BufW
use std::io::BufR
fn main() {
let file = File::open("./data.dat").unwrap();
let mut fin = BufReader::new(file);
for line in fin.lines() {
println!("{}", line.unwrap());
这里，为了读取所有的行，的提供了一个函数，返回迭代器，使用来取出所有的行。需要注意的就是需要通过来释放出来，当然也可以采用别的更加安全的方法。
现在需要的就是将处理过的行，存储到新的文件中，代码如下。
use std::io::prelude::*;
use std::fs::F
use std::io::BufW
use std::io::BufR
fn main() {
let file = File::open("./data.dat").unwrap();
let mut fin = BufReader::new(file);
let file_new = File::create("./data_new.dat").unwrap();
let mut fout = BufWriter::new(file_new);
for line in fin.lines() {
let new_line = ope_line(&line.unwrap());
fout.write_all((new_line + "\n").as_bytes());
fout.flush();
fn ope_line(line: &String) -& String {
line.clone()
我们使用的方法很方便的将处理后的行输出了。
RUST有很强的内存管理，所以在处理数据的时候要小心，编译器很找出所有的关于内存的错误。
注意，如果处理的字符串中有中文，而且使用函数写文件的时候，格式化字符串时一定要用，而不是。内存不足 怎么办啊？？_rust吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0可签7级以上的吧50个
本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：41,919贴子：
内存不足 怎么办啊？？
3D双端东方魔幻网游「大青云」勾魂公测,穿越逆转,封神故事,全新演绎!
大神帮忙啊
你可以等双11打折买条内存
这逼游戏越来越来卡 优化也差 以前8g内存 流畅运行 现在8g内存开一档直接爆内存
8G还不够用怕是你还没开游戏内存就已经占用6-70%了吧。
8G内存开鲁大师自动清理内存
这个问题好好笑= =就和饿了该怎么办 一样
贴吧热议榜
使用签名档&&
保存至快速回贴我眼中的编程语言Rust和GO | 程序师Dropbox 用 Rust 取代 Go 精简内存占用
Dropbox昨天宣布将用户数据从亚马逊迁移到自己的数据中心，它在过去两年半里构建了自己的网络存储和同步基础设施，使用的文件储存系统Magic Pocket由自己的程序员开发。《连线》，
他设计的这套系统允许Dropbox更高效的储存数百PB的数据，Dropbox本质上是构建了自己的 Amazon
S3。报道还提到了一个细节：Dropbox的硬件工程师Rami Aljamal设计了名叫Diskotech的机器去保存1PB数据，但Magic
Pocket与新的硬件不匹配，所以另一位程序员Jamie Turner用全新的语言重新构建了Magic Pocket
，这个语言就是Mozilla开发的Rust。Crowling和Turner等人最早是使用Google的Go语言去构建Magic
Pocket，但Go有个缺陷，它占用的内存对大规模存储系统来说太高了，所以他们在开发中途切换到了Rust语言。
Rust 的详细介绍：
Rust 的下载地址：
转载请注明：文章转载自 开源中国社区
本文标题：Dropbox 用 Rust 取代 Go 精简内存占用
本文地址：
引用来自“冰力”的评论很多人做过实验http://blog.csdn.net/idid1/article/details/9144409自己没有实践下，就乱赋值别人的博客，也不看看时间日期，和现在的go语言的开发程度！！！不懂装懂！！
他们喜欢骂美国，他们用力把沃尔玛、麦当劳、肯德基、iphone、谷歌、福特、通用都骂了一遍。后来骂得口干了，买了瓶可乐，回家打开win7笔记本，连上互联网，开始看新赛季的NBA。他们没有理想，不会思考，却有一个伟大的中国梦。他们身无财权，手无选票，却觉得自己是国家的主人。哈哈哈
要是oschina 评论支持屏蔽或者拉黑功能就好了，作为一个PHPer都看不下去了 via 青衫柏箴
eechen真的很菜，一个冒泡算法都能写如此糟糕,真的很无语, 水平菜就算了，态度这么嚣张、愚昧、自大，难怪这么多年了，还一直这么菜。
引用来自“chenwenli”的评论新版本表现很好引用来自“iSilence”的评论从发布到现在每次都是好,但和无gc比,不管再好,在理论上你是拼不过的,不要和rust比内存,要比语法简单和网络能力引用来自“galaxian”的评论还有工程化能力，比如自带profile， race detector,unit test, benchmark。都极大的提高了生产力。还有编译速度和静态包部署的便利性。引用来自“Neo”的评论静态包部署这个就不要拿出了说了，这个C, C++, RUST, Haskell这些编译型语言都有，不就是一个静态编译嘛。引用来自“galaxian”的评论呵呵了，c++的库依赖问题没有遇到过么，先不说构建时的依赖。让你的c++程序运行时做到我上面的那些工程化功能支持，然后ldd/denpend看看依赖的库够不够你喝一壶，哪怕你用docker，dockerfile里的yum install -y会少么，这和基本只依赖glibc的go是一样的工作量么。别说静态库，人可不推荐这么玩，而且问题一样不少。回过头来说构建，光win32,linux,android(armv7/64/x86)ios(sim,arm/arm64).跨平台就够你嗨一阵了！再说工程组织和编译器，每个compiler特性支持不一样，平台差异性更海了去了，光cmake就可以撸很久了好么。还别说要支持到上面所说功能开源库不一定都是一个构建系统。现在还觉得”不就是一个静态编译“么？ 引用来自“eechen”的评论国人爱特打包的Anmpp(适用于Android和Raspbian)以及Lnmpp(适用于Linux)二进制包,里面包含了Nginx/MySQL/PostgreSQL/PHP这些大型的C项目,部署不也很简单么?我自己打包的PHPDroid,包含了PHP7解释器和BusyBox环境,整个APK包还不到6MB,一场跑在Android上,不也挺简单,而且我还只是一个PHP开发者,不是C开发者:交叉编译+静态链接,C程序便携式打包也很轻松./s/1micZBWc
的逻辑：自己用不起iPhone，所以iPhone是世界上最垃圾的手机；不会Java，所以Java是世界上最垃圾的语言；去不了美帝，所以美帝的人们都生活在水深火热之中。
一切用分代垃圾回收策略的语言，都需要比较大的内存换来更低频次的回收（更高的性能）
引用来自“chenwenli”的评论新版本表现很好引用来自“iSilence”的评论从发布到现在每次都是好,但和无gc比,不管再好,在理论上你是拼不过的,不要和rust比内存,要比语法简单和网络能力引用来自“galaxian”的评论还有工程化能力，比如自带profile， race detector,unit test, benchmark。都极大的提高了生产力。还有编译速度和静态包部署的便利性。引用来自“Neo”的评论静态包部署这个就不要拿出了说了，这个C, C++, RUST, Haskell这些编译型语言都有，不就是一个静态编译嘛。引用来自“galaxian”的评论呵呵了，c++的库依赖问题没有遇到过么，先不说构建时的依赖。让你的c++程序运行时做到我上面的那些工程化功能支持，然后ldd/denpend看看依赖的库够不够你喝一壶，哪怕你用docker，dockerfile里的yum install -y会少么，这和基本只依赖glibc的go是一样的工作量么。别说静态库，人可不推荐这么玩，而且问题一样不少。回过头来说构建，光win32,linux,android(armv7/64/x86)ios(sim,arm/arm64).跨平台就够你嗨一阵了！再说工程组织和编译器，每个compiler特性支持不一样，平台差异性更海了去了，光cmake就可以撸很久了好么。还别说要支持到上面所说功能开源库不一定都是一个构建系统。现在还觉得”不就是一个静态编译“么？ 国人爱特打包的Anmpp(适用于Android和Raspbian)以及Lnmpp(适用于Linux)二进制包,里面包含了Nginx/MySQL/PostgreSQL/PHP这些大型的C项目,部署不也很简单么?我自己打包的PHPDroid,包含了PHP7解释器和BusyBox环境,整个APK包还不到6MB,一场跑在Android上,不也挺简单,而且我还只是一个PHP开发者,不是C开发者:交叉编译+静态链接,C程序便携式打包也很轻松./s/1micZBWc
引用来自“galaxian”的评论go1.6 20G内存 100W左右对象，GC时间2ms以内，如何饱受诟病引用来自“Axel_”的评论http://blog.csdn.net/liigo/article/details/日补记：直到2015年底，Go 1.5新GC发布后数月，仍获知有大陆圈内知名团队因为GC的原因考虑换掉Go语言，颇有感触。当软件系统逐步发展到更庞大更复杂的时候，Go语言的垃圾回收器(GC)就变成了指不定啥时候会出现的拦路虎，让人进退两难。进，暂时没有确切有效的技术手段对付响应延迟和内存暴涨；退，多年开发付出的心血付之东流损失惨重。语言选型之前多做调查分析，如果一定要用Go语言开发，控制系统规模和复杂度，避开底层的核心业务，可能是比较明智的选择。引用来自“galaxian”的评论这哥们典型的rust粉，文章我当年就看过。dropbox在某些模块使用rust是内存占用而不是GC。所以立论就是错的。But Go’s “memory footprint”—the amount of computer memory it demands while running Magic Pocket—was too high for the massive storage systems the company was trying to build这哥们大概是国内第一Go黑了，他的话不是说毫无道理，但必须过滤掉情绪及误导才能看，再说世上哪有适合所有场景的语言。在我看来rust还是处于养肥阶段，go已经可以吃了
引用来自“chenwenli”的评论新版本表现很好引用来自“iSilence”的评论从发布到现在每次都是好,但和无gc比,不管再好,在理论上你是拼不过的,不要和rust比内存,要比语法简单和网络能力引用来自“galaxian”的评论还有工程化能力，比如自带profile， race detector,unit test, benchmark。都极大的提高了生产力。还有编译速度和静态包部署的便利性。引用来自“Neo”的评论静态包部署这个就不要拿出了说了，这个C, C++, RUST, Haskell这些编译型语言都有，不就是一个静态编译嘛。呵呵了，c++的库依赖问题没有遇到过么，先不说构建时的依赖。让你的c++程序运行时做到我上面的那些工程化功能支持，然后ldd/denpend看看依赖的库够不够你喝一壶，哪怕你用docker，dockerfile里的yum install -y会少么，这和基本只依赖glibc的go是一样的工作量么。别说静态库，人可不推荐这么玩，而且问题一样不少。回过头来说构建，光win32,linux,android(armv7/64/x86)ios(sim,arm/arm64).跨平台就够你嗨一阵了！再说工程组织和编译器，每个compiler特性支持不一样，平台差异性更海了去了，光cmake就可以撸很久了好么。还别说要支持到上面所说功能开源库不一定都是一个构建系统。现在还觉得”不就是一个静态编译“么？
引用来自“chenwenli”的评论新版本表现很好引用来自“iSilence”的评论从发布到现在每次都是好,但和无gc比,不管再好,在理论上你是拼不过的,不要和rust比内存,要比语法简单和网络能力引用来自“galaxian”的评论还有工程化能力，比如自带profile， race detector,unit test, benchmark。都极大的提高了生产力。还有编译速度和静态包部署的便利性。静态包部署这个就不要拿出了说了，这个C, C++, RUST, Haskell这些编译型语言都有，不就是一个静态编译嘛。
引用来自“eechen”的评论http://www.csdn.net/article//2822545在第二版抢购系统的开发过程中，我们遇到了HTTP层Go程序内存消耗过多的问题。由于HTTP层主要用于维持住用户的访问请求，每个请求中的数据都会占用一定的内存空间，当大量的用户进行访问时就会导致内存使用量不断上涨。当内存占用量达到一定程度（50%）时，Go中的GC机制会越来越慢，但仍然会有大量的用户进行访问，导致出现“雪崩”效应，内存不断上涨，最终机器内存的使用率会达到90%以上甚至99%，导致服务不可用。2014年 go 才 1.3 版本吧，现在都到了1.6版本了，还拿这些东西出来有什么意义呢，而且之后 go 还会继续快速的迭代，只会越来越好。
引用来自“galaxian”的评论go1.6 20G内存 100W左右对象，GC时间2ms以内，如何饱受诟病引用来自“Axel_”的评论http://blog.csdn.net/liigo/article/details/日补记：直到2015年底，Go 1.5新GC发布后数月，仍获知有大陆圈内知名团队因为GC的原因考虑换掉Go语言，颇有感触。当软件系统逐步发展到更庞大更复杂的时候，Go语言的垃圾回收器(GC)就变成了指不定啥时候会出现的拦路虎，让人进退两难。进，暂时没有确切有效的技术手段对付响应延迟和内存暴涨；退，多年开发付出的心血付之东流损失惨重。语言选型之前多做调查分析，如果一定要用Go语言开发，控制系统规模和复杂度，避开底层的核心业务，可能是比较明智的选择。引用来自“galaxian”的评论这哥们典型的rust粉，文章我当年就看过。dropbox在某些模块使用rust是内存占用而不是GC。所以立论就是错的。But Go’s “memory footprint”—the amount of computer memory it demands while running Magic Pocket—was too high for the massive storage systems the company was trying to build嗯,相对而言go及有内存问题也有GC问题,对这方面应用有要求的就不应该选go
引用来自“galaxian”的评论go1.6 20G内存 100W左右对象，GC时间2ms以内，如何饱受诟病引用来自“Axel_”的评论http://blog.csdn.net/liigo/article/details/日补记：直到2015年底，Go 1.5新GC发布后数月，仍获知有大陆圈内知名团队因为GC的原因考虑换掉Go语言，颇有感触。当软件系统逐步发展到更庞大更复杂的时候，Go语言的垃圾回收器(GC)就变成了指不定啥时候会出现的拦路虎，让人进退两难。进，暂时没有确切有效的技术手段对付响应延迟和内存暴涨；退，多年开发付出的心血付之东流损失惨重。语言选型之前多做调查分析，如果一定要用Go语言开发，控制系统规模和复杂度，避开底层的核心业务，可能是比较明智的选择。哈哈哈，这招好，任你千万种理由，只一条gc回过去，这样确实必胜无疑。我：易用，你：gc烂；我：开发高效，你：gc烂……不过我得说，吐槽归吐槽，至少我这边实践证明，go用于中小规模的游戏服务器研发是很有优势的，并没有受到gc的折磨。每个语言都有长短，用其所长，避其所短才是。单一语言党没什么前途。
引用来自“galaxian”的评论go1.6 20G内存 100W左右对象，GC时间2ms以内，如何饱受诟病引用来自“Axel_”的评论http://blog.csdn.net/liigo/article/details/日补记：直到2015年底，Go 1.5新GC发布后数月，仍获知有大陆圈内知名团队因为GC的原因考虑换掉Go语言，颇有感触。当软件系统逐步发展到更庞大更复杂的时候，Go语言的垃圾回收器(GC)就变成了指不定啥时候会出现的拦路虎，让人进退两难。进，暂时没有确切有效的技术手段对付响应延迟和内存暴涨；退，多年开发付出的心血付之东流损失惨重。语言选型之前多做调查分析，如果一定要用Go语言开发，控制系统规模和复杂度，避开底层的核心业务，可能是比较明智的选择。这哥们典型的rust粉，文章我当年就看过。dropbox在某些模块使用rust是内存占用而不是GC。所以立论就是错的。But Go’s “memory footprint”—the amount of computer memory it demands while running Magic Pocket—was too high for the massive storage systems the company was trying to build