关于创建「更小的」Rust的思考
#rust
官方核心团队成员无船大佬新博文，针对社区中有些人喜欢Rust但还没有真正热爱Rust的人提出的看法「能否创造一个更小化更简单的更易于使用的Rust呢」所做的回应？
发出此类问题的人，最想改变Rust的一个想法就是给Rust增加垃圾回收，但其实这是错误的。因为他们根本不明白Rust语言的本质。Rust的核心是：代数数据类型、RAII、「别名 xor 可变」，换句话说，就是所有权和借用。如果试图摆脱这个核心，就是错过真正的Rust。
如果Rust不以「系统」语言为目标，如何才能设计它才能变得更简单呢？无船大佬给出了以下思考：
- 放弃变量是在栈上还是堆上分配的任何保证。Rust为开发者做了这种保证，这是Rust复杂性的独特来源。
- 使trait对象成为多态的主要形式，不再单态化，泛型只用于创建容器类型，而不去创建函数。
- 将Rust的承诺放在并发性上，并使所有可用的原语线程安全。 没有Rc，没有Cell和RefCell。 内部可变性仅允许通过互斥锁类型，并且所有内容都可以跨线程Move。 Send和Sync仅作为对所有权相关类型的一些内置检查存在。
- 闭包/数组/Vecs/切片也可以通过不保证任何被分配的位置来简化。
- 会使用绿色线程，并且拥有像Go这样的简单CSP/Actor模型。
- 还有很多其他地方可以简化，比如元编程、错误处理等。
- 会小心地设计编译器，以便它可以嵌入到不同的运行时，有两个主要的编译目标：基于LLVM的和WASM的。
无船大佬说，（假如要实现的话）他会用Rust实现这种语言及其运行时。
「视频」facebook Libra听证会关于为什么选择Rust语言的两分钟精华问答
#video #libra
到目前为止，Rust编译器的速度已经全面提高了30-40%
#Rustc
从2019-01-01到2019-07-17，Rust编译器的速度已经全面提高了30-40%，一些项目的速度提高了45%以上
HOWTO: mem::MaybeUninit代替 mem::uninitialized
#std
Rust 1.36稳定了mem::MaybeUninit，本帖教你如何使用它来替代mem::uninitialized。使用uninitialized()函数容易出现UB。一般是在FFi的时候需要使用uninitialized()，因为在C/C++中允许创建未初始化的变量，而Rust不允许。
可以参考该贴作者给自己维护的库升级MaybeUninit的PR来查看如何使用。
「视频」使用 RISC-V 和 Rust 来构建安全的系统
#RiscV
rustarok： 适合开发多人快节奏Moba风格游戏的框架
#game
「非官方」用于收集Rust孤儿规则设计问题的仓库
#orphan
Pushrod 0.4.1 发布
#GUI
Pushrod 是一個利用piston_window做GUI库。
「讨论」现在Rust语言招聘要求三年Rust经验是否合理？
这是来自于Reddit的一个讨论贴，作者十分喜欢Rust，但是看到很多招聘广告要求三年Rust经验，所以他想问，是否有适合Rust新手的工作。然后评论里有一个回复我觉得挺有道理，我贴出来：
There are no language X job advertisements.
I think there is a misunderstanding here; you see an advertisement asking for C++ experience and conclude that not knowing C++ you are unfit. There's a slim possibility that you are right, and a near overwhelming possibility that you misunderstood the ad.
Now, before going further, there are possibly some places where "X years of experience in Y" is a sacrosanct requirement; the company may be looking for an expert in Y for some reasons. And there are cases where HR may even believe it is sacrosanct, if they have no idea what they are doing.
In the vast, overwhelming, majority of cases though, "X years of experience in Y" is really a rough guideline:
X aims at giving a hint of the seniority required; 0-1 is aimed at beginners, 2-4 at juniors, 5-10 at regulars and 10+ at seniors. The varying level of seniority is also a hint at the kind of work (senior may imply mentorship, technological/architecture decisions, ...) and compensation.
Y aims at giving a hint at the domain, for example C++ could mean: systems programming (kernel, driver, embedded), high-performance computing (numerical, scientific, machine-learning), real-time (embedded, audio/video), low-latency, ... A technical interviewer would understand that anybody with experience in C or Rust in the same domains would be able to adapt relatively quickly.
The only quasi-certainty in "X years of experience in Y" is that the job involves working with Y; if you don't like it, or do not want to work with it, better pass your way.
Learning
X developers are pointless.
I've never seen a job which required me to only ever program with a single language. There's usually a main language, certainly, but:
My first job was mainly C++, with some SQL, HTML, CSS, JavaScript, and Python/Bash.
My second job was mainly C++, with a lot of SQL, and some Python/Bash.
My current job is mainly C++, with some x64 assembly (debugging), Java, and some Python/Bash. The occasional glance at Systems Verilog too.
Furthermore, the more languages you see, the more your realize just how much in common those languages have. The first time you see a concept, you'll struggle with it, but the fourth or fifth time, it's just like getting back on a bicycle after a couple years, it just comes back instantly.
My advice, therefore, is NOT to make the mistake of focusing on learning a single language in depth and instead aim for breadth:
Computer Science is awesome: data-structures and algorithms are not something you code daily, but understanding them and applying complexity analysis is great.
Languages have a lot of different programming paradigms, in no particular order: C/C++/Rust, Java/C#, JavaScript, Haskell, Python/Ruby, Lisp, Forth, Eiffel, ... Each of these groups bring something novel to the mix.
Real world != assignments: assignments tend to be small, well-defined, and immediately forgotten. The real-world has large code-bases which grew organically for decades and have high-level functional requirements that are only defined on a coarse-grained level (and even then, there's often leeway). If you want early experience with the real world, either find a part-time job at a programming shop or an existing open-source project -- insisting on existing, as it means already large and laden with technical debt.
You could read books, like Clean Code, etc... but honestly, you'll only appreciate their advice after experiencing the mess of the real world first-hand ;)
Broader Learning
Also, just in case you are under the misconception that a programming job is about coding; it's a lot more than that.
Programming also involves:
Communication: English. If your first language is not English, that's your first priority in University -- take extra courses if needed, start reading/writing in English daily, start watching movies in English. If your first language is English (lucky you), but you're not too good at it, then it's also your first priority. Spelling mistakes are an embarrassment in any professional e-mail, fumbling for words in a conversation is always awkward, and having to repeat because you mumble makes you wonder how many times you were misunderstood.
Communication: Clarity & Concision. Remember when I mentioned coarse-grained specifications? Guess who it falls onto to clarify them? YOU! It means listening/speaking and reading/writing, of course. It also means communicating with technical peers and non-technical clients. It means rephrasing to ensure you understood. It means summarizing discussions to leave a trace you can come back to.
Planning. At the very least, planning your work, knowing how to divide a large task in small chunks, understanding business priorities, ...
In Parting
Learning a programming language in depth should be the least of your worries.
Instead you should learn programming in the broad sense: puzzle-solving, navigating large code-bases, communicating clearly and efficiently, and getting comfortable with a variety of programming paradigms and syntax so as to be flexible.
Oh, and if you're looking to get your feet wet by contributing to open-source, may I suggest the Rust community? It's welcoming, and there are a lot of exciting projects on a broad variety of topics ;)
From 日报小组 Chaos
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：
1
共 0 条评论, 1 页
评论区
写评论还没有评论