Zed 是 Atom 编辑器原作者主导的新项目, Atom 是 GitHub 创建的开源文本编辑器。2018 年微软收购 GitHub 后，Atom日渐式微
fish 是适用于 Linux、macOS 的命令行 Shell，其名字取于 “the friendly interactive shell”
https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html
基本没啥动静了.. https://github.com/crablang/crab
rust的vec可以在栈上分配吗
在 Rust 中，Vec<T> 类型是一个可增长的数组，通常分配在堆上。这是因为 Vec<T> 需要能够在运行时动态地改变大小，而堆内存提供了这种灵活性。栈内存相对有限，主要用于固定大小的数据和小的数据结构。
但是，如果你想要一个在栈上分配的类似 Vec 的结构，你可以考虑使用以下替代方案：
数组：固定大小的数组（例如
[T; N]）是在栈上分配的。数组的大小必须在编译时已知，这限制了它们的灵活性。arrayvec或smallvec包：这些第三方库提供了类似于Vec的数据结构，但可以在栈上分配一个固定数量的元素。例如，ArrayVec和SmallVec允许你在栈上分配一个固定数量的元素，只有在超出这个数量时，它们会退回到堆分配。Box<[T; N]>：虽然这仍然是堆分配，但它允许你创建一个固定大小的堆分配数组。这比Vec更接近于在栈上分配固定大小的数据，但仍然涉及堆分配。
总的来说，Rust 的 Vec<T> 本身不能在栈上分配，但你可以使用其他数据结构或第三方库来获得类似的功能，同时保持在栈上分配。
go的slice元素很少，可以在栈上分配吗
在 Go 语言中，slice（切片）是一种引用类型，通常用于表示可变长的序列。切片本身的结构（包含指向底层数组的指针、长度和容量）通常是在栈上分配的，但它指向的底层数组通常是在堆上分配的。这种设计允许切片动态地增长和缩小，而不受栈的大小限制。
对于元素数量非常少的情况，Go 编译器可能会进行逃逸分析（Escape Analysis），并决定将这些小的数组直接在栈上分配，而不是在堆上。逃逸分析是编译器在编译时执行的一种优化，用来决定数据应该存储在堆上还是栈上。如果编译器能确定一个对象的生命周期仅限于其被创建的函数内部，那么这个对象可能就会被分配在栈上。
然而，这种优化完全取决于编译器的具体实现和代码的上下文。编程时，开发者通常不需要（也不应该）显式控制数据是在堆上还是栈上分配，因为 Go 的编译器会自动做出最优选择。编写代码时，应更关注于切片的正确使用和性能优化，而不是它们的内部存储机制。
go的slice,在栈上,指向的底层数组,如果元素很少,也可能分配在堆上,有逃逸分析
而Rust,看起来Vec一定在堆上..Rust本身应该在栈上的吧??
请教一个问题：如果一棵树包含很多节点（指针连接），占用了很多内存，如何快速销毁它，让gc回收内存？是不是也得和c语言free类似，将每个节点置nil？有没有更好的方法？或者树的结构需要某种设计
在像 Go 或 Java 这样的具有垃圾回收（GC）的语言中，销毁大型数据结构（如包含许多节点的树）的主要方法是确保没有活跃的引用指向这个数据结构。一旦没有引用指向该数据结构，垃圾回收器就会在其后续的运行中识别并回收这些不再使用的内存。
为了确保树结构可以被垃圾回收，你可以做以下几点：
移除树的引用：确保所有指向树的引用都被移除或设置为
nil。这可能包括变量、字段或数组/切片中的元素指向该树的根节点。减少跨作用域引用：尽量避免在你的程序中创建跨作用域的引用到树的节点。这样可以确保当包含树根引用的作用域结束时，整个树都能被垃圾回收。
使用局部变量：在可能的情况下，使用局部变量来持有对树的引用。当函数执行完毕，局部变量超出作用域，树的引用将自动被移除。
不同于像 C 语言那样需要手动释放每个节点，GC 语言会自动处理这些工作，只要没有活跃的引用指向这些对象。
如果你发现树结构没有被垃圾回收，原因通常是还有活跃的引用指向树的一部分，这阻止了整个树的回收。在这种情况下，你可能需要仔细检查你的代码，查找并移除这些多余的引用。
在设计树结构时，没有特别的设计是为了便于垃圾回收而创建的。关键是管理好对树的引用，并确保当树不再需要时，可以将所有对它的引用都清除。这通常是通过良好的代码结构和遵循作用域规则来实现的。
原文链接: https://dashen.tech/2023/12/13/Rust新进展/
版权声明: 转载请注明出处.