Nugine0

Nugine0

V2EX 第 362983 号会员,加入于 2018-11-14 08:45:06 +08:00
根据 Nugine0 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
Nugine0 最近回复了
8 天前
回复了 hongchaodeng 创建的主题 程序员 He3: 开发者必备的万能工具箱
electron 过重了,换 tauri 可能更好
33 天前
回复了 jsun969 创建的主题 程序员 看看程序员鱼皮的嘴脸
@mysalt 我觉得挺好,玩不起的人自会被别人玩
38 天前
回复了 DTCPSS 创建的主题 Rust 一个 Rust 小玩具,命令行听 Code Radio 音乐电台
我怎么就想不到这种玩法
题目假设任何决议通过后都能立即 100%执行到位,如果这个假设成立,五年内实现人类命运共同体都不是问题。
45 天前
回复了 YadongZhang 创建的主题 程序员 The future is turbopack
前端工具链领域的优化空间是真的大。用 Rust 写过一轮后,未来也不太可能有几百倍的速度提升了。换句话说,像这样悬殊的性能对比是空前绝后的。
46 天前
回复了 RTSmile 创建的主题 Rust Rust 是否有稍微成熟一点的定时任务的包
实在没有的话,可以把别的语言的包移植过来用
49 天前
回复了 v2defy 创建的主题 程序员 rust 真的是硬盘杀手
rust 不会自动清除无用的编译产物,要定期删掉 target 。
一些编译设置(高等级优化,增量编译,lto 等)会保存额外的中间信息。
debug 和 release 会产生两遍编译产物,有的 c/c++绑定会下载两遍预编译文件,没事可以删删 target/debug 。
交叉编译时对每个目标平台分别编译,有多少个就乘几倍……
有工具(sccache)可以跨工作区复用编译产物。上面有人说的透明压缩也能缓解。
rust 默认全部静态链接,手动设成动态链接可以减少中间产物体积,不过既麻烦又对泛型没用。
rust 的包管理和 nodejs 一样鼓励复用,导致动不动上百个间接依赖,也是膨胀得很厉害。
74 天前
回复了 iwdmb 创建的主题 程序员 Azure CTO 认为应以 Rust 代替 C/C++
@dbskcnc
@mirrorman

Cloudflare 团队选择 Rust 是因为它可以在不妥协性能的前提下以内存安全的方式完成 C 语言所能做的事情。

"We chose Rust as the language of the project because it can do what C can do in a memory safe way without compromising performance."

快速安全地发布功能很困难,尤其是在我们的规模下。很难预测在每秒处理数百万个请求的分布式环境中可能发生的每个边缘情况。模糊测试和静态分析只能缓解这么多。Rust 的内存安全语义保护我们免受未定义行为的影响,让我们确信我们的服务将正确运行。
有了这些保证,我们可以更多地关注我们的服务更改将如何与其他服务或客户来源进行交互。我们可以以更高的节奏开发功能,而不会受到内存安全问题和难以诊断崩溃的负担。
当崩溃确实发生时,工程师需要花时间来诊断它是如何发生的以及是什么原因造成的。自 Pingora 成立以来,我们已经处理了数百万亿个请求,并且还没有因为我们的服务代码而崩溃。
事实上,Pingora 崩溃是如此罕见,当我们遇到一个问题时,我们通常会发现不相关的问题。最近,我们的服务开始崩溃后不久,我们发现了一个内核错误。我们还发现了一些机器上的硬件问题,过去排除了由我们的软件引起的罕见内存错误,即使在几乎不可能进行重大调试之后也是如此。

"Shipping features quickly and safely is difficult, especially at our scale. It's hard to predict every edge case that can occur in a distributed environment processing millions of requests a second. Fuzzing and static analysis can only mitigate so much. Rust's memory-safe semantics guard us from undefined behavior and give us confidence our service will run correctly.
With those assurances we can focus more on how a change to our service will interact with other services or a customer's origin. We can develop features at a higher cadence and not be burdened by memory safety and hard to diagnose crashes.
When crashes do occur an engineer needs to spend time to diagnose how it happened and what caused it. Since Pingora's inception we’ve served a few hundred trillion requests and have yet to crash due to our service code.
In fact, Pingora crashes are so rare we usually find unrelated issues when we do encounter one. Recently we discovered a kernel bug soon after our service started crashing. We've also discovered hardware issues on a few machines, in the past ruling out rare memory bugs caused by our software even after significant debugging was nearly impossible."
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2829 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 08:11 · PVG 16:11 · LAX 00:11 · JFK 03:11
Developed with CodeLauncher
♥ Do have faith in what you're doing.