< 返回版块

rust 日报 babpstep 发表于 2024-03-26 20:43

Rust target 目录的磁盘空间问题讨论

一位 Reddit 用户在反映,在他们的 1TB 机器上,一个 target 目录占用了高达 165GB 的空间,总共有近 500GB 的 target 目录空间被占用。

相信不少人也遇到过类似的问题,针对 Rust Target 目录磁盘空间占用过大的问题,网友们展开了激烈的讨论,总结如下:

  • 空间占用分析:一个用户指出,他发现大约 70% 的空间被 crate 元数据占用,包括所有依赖的文档字符串。元数据被存储了两次,一次在 .meta 文件中,一次嵌入在 .rlib 文件中。
  • 清理建议:使用 cargo clean 可以删除所有构建产物,但这意味着需要重新构建。推荐使用 cargo sweep 命令来清除未与当前安装的工具链构建的构建产物,或删除超过 90 天的旧依赖。
  • 性能和优化:讨论了文件系统压缩(如 btrfs + compress-force=zstd:1)和 sccache 的使用,以提高极端情况下的效率。
  • Cargo 团队的计划:Cargo 团队正在开展垃圾收集工作,首先聚焦于全局缓存(如索引、git 依赖等),并对用户目录下的 target 缓存进行优化以减少重复。

reddit原帖链接

使用 Rust 重写 devenv 1.0

devenv 是一个旨在创建快速、声明式、可复现、可组合的开发环境的工具,利用 Nix 实现。

  • 快速与声明式: 使用 devenv 可以迅速地构建出开发环境,并且环境的配置是声明式的,意味着配置是清晰和明确的。
  • 可复现性:通过 Nix 的特性,devenv 创建的开发环境是可复现的,确保了环境的一致性和稳定性。
  • 可组合性:允许开发者组合不同的配置和工具,以满足具体的开发需求。
Tips: 类似的工具还有 Nix, brew-bundle, conda/Poetry 等

近日,devenv 发布了 1.0 版本,这是一个将 CLI 从 Python 重写到 Rust 的重大更新,带来了许多新特性和改进:

  • Process-compose: 现在成为默认的进程管理器。
  • 测试基础设施: 增加了许多功能,以简化测试的编写和运行。
  • Non-root 容器: 生成的容器现在以普通用户身份运行,提高了安全性。
  • DEVENV_RUNTIME 环境变量: 用于处理 socket 路径限制。
  • Python 原生库支持: 改善了使用 pip 等工具时的体验。
  • CLI 改进: 包括输入添加、输入更新、构建属性等功能。

同时,核心开发人员也分享了从 Python 迁移到 Rust 的原因: 原 Python 实现的性能不足以满足需求,而选择 Rust 是因为其性能优势和在 Nix 社区中的逐渐普及。

github项目地址

blog地址

Rust Nightly 实验功能:Postfix Match

Rust Nightly 的最新版本中,加入了一项实验功能:Postfix Match。

这个功能允许开发者在表达式后,通过类似于方法调用的方式使用 match 语法。一些开发者反馈,认为这个特性使得代码更易读,尤其是在链式调用或长表达式中,它允许开发者从左到右顺序阅读代码,提高了代码的连贯性,但也有人担心语法的复杂度越来越高。

示例代码如下:

#![allow(unused)]
#![feature(postfix_match)]

fn main() {
    enum Foo {
        Bar,
        Baz
    }

    fn get_foo() -> Foo {
        Foo::Bar
    }
    
    // old way
    match get_foo(){
        Foo::Bar => {},
        Foo::Baz => {},
    }

    // new way
    get_foo().match {
        Foo::Bar => {},
        Foo::Baz => {},
    }
}

甚至是这样

get_thing().match({
    Thing::Foo => NextObj(1)
    Thing::Bar => NextObj(2)
}).next_func()

rust unstable book 对应章节

-- From 日报小组 RustPlumber

社区学习交流平台订阅:

评论区

写评论
ankoGo 2024-03-28 08:39

比如这样?

get_thing().
    match ({
        Thing::Foo => NextObj(1)
        Thing::Bar => NextObj(2)
    }).
    match ({
        Thing::Foo => NextObj(1)
        Thing::Bar => NextObj(2)
    }).next_func().next_func().
    match ({
        Thing::Foo => NextObj(1)
        Thing::Bar => NextObj(2)
    }).next_func().
    match ({
        Thing::Foo => NextObj(1)
        Thing::Bar => NextObj(2)
    }).next_func().
    match ({
        Thing::Foo => NextObj(1)
        Thing::Bar => NextObj(2)
    }).next_func()
ankoGo 2024-03-28 08:35

感觉没什么差别。 很孔乙己的写法

全称量词 2024-03-27 16:15

如果 get_foo() 不是一句而是一串很长的迭代器链式调用,则尾部 match 的写法更好看一点

--
👇
bestgopher:

match get_foo(){
        Foo::Bar => {},
        Foo::Baz => {},
    }

    // new way
    get_foo().match {
        Foo::Bar => {},
        Foo::Baz => {},
    }

下面这种相比于上面有啥优势?

mu2019 2024-03-27 14:23

感觉没什么差别。 很孔乙己的写法。

--
👇
bestgopher:

match get_foo(){
        Foo::Bar => {},
        Foo::Baz => {},
    }

    // new way
    get_foo().match {
        Foo::Bar => {},
        Foo::Baz => {},
    }

下面这种相比于上面有啥优势?

bestgopher 2024-03-27 12:17
match get_foo(){
        Foo::Bar => {},
        Foo::Baz => {},
    }

    // new way
    get_foo().match {
        Foo::Bar => {},
        Foo::Baz => {},
    }

下面这种相比于上面有啥优势?

1 共 5 条评论, 1 页