tx-rs - 一个提供 wrtie ahead 的原子交易库

刚出来，仅供了解，这里的“交易”是指业务的原子性，常见于数据库中。与区块链或密码学中的交易，是不同的概念。类似于 STM。

Repo

duang - 使用宏来提供默认参数和命名参数

一看就是国人的项目。命名有点玩耍的味道，但是思路和设计可以借鉴。

use duang::duang;

duang!(
pub fn foo<T>(a: T, b: f64 = 13.0, c: T = a * a) -> (T, f64, T)
where
  T: std::ops::Mul<T, Output = T>,
  T: std::fmt::Display,
  T: Copy,
{
  (a, b, c)
}
);

// ----

use demo_duang::foo;
// pass
assert_eq!(foo!(1, c = 30, b = -2.0), (1, -2.0, 30));
// pass
assert_eq!(foo!(a = 10), (10, 13.0, 100));
// fail
// foo!(1,c=30,c=2);

Repo

dua-cli - 用于查看当前目录下的磁盘容量使用情况

这个工具发布 v2.0 了。就是 du 的升级版。先看下效果图。

Repo

coffee 2D游戏引擎推出了响应式UI

不过这个UI是用于游戏内的UI。

Repo

stale-rs - 用于找出项目工程中，没有被链接的rs文件

对于这些文件，就可以放心删除。这在重构的时候很有用。来看一下效果图：

Repo

Rust不好的地方有哪些？

作者说，在网上，总是听到说Rust这里好那里好，那么，Rust不好的地方有哪些？

这里就简单汇总一下人们的吐槽：

• Compile times for large projects

• Crate ecosystem is still very young, volatile and sparse

• Because the community is young and still largely curiosity-driven, some essential crates have inconsistent maintenance since there aren't many maintainer organizations yet

• Orphan rules make the glue-package approach (like Java uses) intractable and thus it's difficult to combine different parts of the ecosystem or factor libraries as much as one would like

• Related to the above, we're probably still several years or editions away from a good dynamic linking/plugin story (but for good reason, related to the below)

• The language's real potential still always seems one unimplemented RFC away (e.g., async, const generics, GATs, unsized rvalues, etc.)

• A lot of the features really essential to write libraries of the quality one would like are still unstable (e.g., specialization)

• Many crates have not yet reached version 1.0. This can make them more "scary" to use, as the API could change at any point.

• std::net is quite lacking. For example, you can't perform a non-blocking connect. There is net2, but it has its own set of issues. Then there's socket2 to address net2's issues, but its API is a bit clunky. It's also not very popular, so it remains to be seen for how long it will stick around.

• I think only recently was mirroring of crates.io introduced in a more sane way, though I don't remember exactly in what state.

• Async IO is still clunky. MIO seeks to provide a nice API, but it's not zero-cost by any means. It also has some issues with Windows. I ended up having to use my own wrappers for epoll and kqueue, and used wepoll for Windows.

• No crate namespacing, so you end up with crates like "yorickpeterse-socket2", "billy-bob-socket2", etc. This also means name squatting is more annoying.

• This is not an issue with Rust itself, but is worth mentioning: I really can't stand Clippy. More often than not I upgrade it, and it introduces really annoying lints. For example, if you define len it will complain if you don't also define is_empty. This makes sense for a library, but when writing a self-contained application where you'd never use this it's annoying. Of course you can disable it, but I don't want to sprinkle Clippy directives all over the place.

• No (computed) goto, or something that is guaranteed to compile down to it. This means interpreters won't be able to make use of them, slowing them down a bit (depending on the hardware)

Read More

用 Rust, Haskell, C++, Python, Scala 和 OCaml 实现同一个工程的比较

要比较语言，莫过去用它们实现同一个项目/工程了。作者是一个学生，他们被布置实现一个Jave的子集到x86的编译器。不同的组用了不同语言自行实现。不过，这次这篇文章只是比较了实现同一个编译器需要用到的代码量。其实这个很不客观，因为不同小组实现同一个目标的设计思路和算法都不同。但是这还是能给人一点参考意义，至少知道一个大概的量级和复杂度。