V2EX › fawdlstty 的所有回复 › 第 1 页 / 共 3 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3

❮

❯

2025 年 11 月 22 日

回复了 fawdlstty 创建的主题 › Rust › 推荐一款我写的动态配置语言： Faml

@nebkad 刚写了篇文档，这里面提了一些应用场景，这里用法暂时没有发现除 faml 以外的库支持（用其他库都得手写，也可能是我还没见到过）。此应用场景也许更能说明 faml 的优势？
https://faml.fawdlstty.com/guide/05_advanced_usage.html

2025 年 11 月 10 日

回复了 mightybruce 创建的主题 › Rust › Rust 的安全神话？为何在关键系统如数据库、大模型代码中仍选 C++

rust 并不是用了 unsafe 就不安全，rust 的优势在于通过 safe 限制了内存问题的范围。如果把栈搞崩了需要查问题，只需要看带 unsafe 的代码就行了。unsafe 代码块通常很少，如果一个系统里有 1%的 unsafe ，那么内存问题排查范围就在这 1%的代码里，而不像 c 艹那样整个系统任一行都可能有问题，得整个系统排查

2025 年 11 月 10 日

回复了 fawdlstty 创建的主题 › Rust › 推荐一款我写的动态配置语言： Faml

@lisxour 没有热重载这回事呀。程序生命周期只加载一次配置。关于“万一配置不小心写错了什么东西”，这个问题有点像编程里“万一写错了一行代码”，或者 yaml 配置里“万一配错了值”。用户写的逻辑，该怎样就怎样呗，有啥语言能自动处理这种问题嘛？

2025 年 11 月 10 日

回复了 IIInsomnia 创建的主题 › Rust › Rust Web 开发脚手架 v0.6 发布啦！

我也想写一个类似的东西，核心思想是极简，但我还没做到那一步。第一步是 http 框架
https://github.com/fawdlstty/potato
目前做到了比通用 web 框架都更简单（至少比 axum 、salvo 等更简单，handler 不需要手动注册）（当然离这俩的完善程度还差很远）。
第二步是 orm 框架，市面上的 sea-orm 和 diesel 都不好用，想写个类似 sqlsugar 那样好用的 orm 框架，但一方面受限于 rust 语法，需要多写很多语法噪音，一方面工作量比较大，所以迟迟没动工
如果有兴趣交流欢迎联系，联系方式在 github 首页

2025 年 11 月 10 日

回复了 fawdlstty 创建的主题 › Rust › 推荐一款我写的动态配置语言： Faml

@CEBBCAT 感谢建议，我研究研究

2025 年 11 月 10 日

回复了 fawdlstty 创建的主题 › Rust › 推荐一款我写的动态配置语言： Faml

@lisxour 为什么危险？如果你指的是 faml 里带恶意代码，那设计上是安全的，faml 里只能计算，不能执行恶意指令（比如加载文件、写文件或联网啥的）；如果你指的是 faml 源码里很多 unsafe ，那只能说抱歉了，我设想的需求不用 unsafe 写不出来，不过这个点不一定说明它危险，得利用 unsafe 造成的漏洞才算；再者如果你指的是一个数据修改导致其他数据发生非预期变化，这个点上危险，那我就不知道说啥了，毕竟这是用户自己写的代码，写了啥那就执行了啥

2025 年 11 月 10 日

回复了 fawdlstty 创建的主题 › Rust › 推荐一款我写的动态配置语言： Faml

@pingdog 不带保存功能噢。只加载一次，后续就在读取的示例上进行修改。因此不存在破坏数据的问题

2025 年 11 月 10 日

回复了 BigChengzi 创建的主题 › Rust › 如何看待 Rust？

@mightybruce 如果此处 AI 时代指的是 Vibe Coding ，那 Rust 还是有优势的，至少截至目前 AI 写的代码都不可靠，Rust 至少从语法层面限制住了一些问题

2022 年 8 月 5 日

回复了 fawdlstty 创建的主题 › 求职 › 八年开发者在线求职，广州或远程

感谢各位抬爱，求老兄们别捧杀，我还没找到工作呐

2022 年 8 月 4 日

回复了 fawdlstty 创建的主题 › 求职 › 八年开发者在线求职，广州或远程

@zh6335901 感谢抬爱

2022 年 8 月 4 日

回复了 fawdlstty 创建的主题 › 求职 › 八年开发者在线求职，广州或远程

@zh6335901 学历低，带砖，大厂进不去

2022 年 5 月 1 日

回复了 DIO 创建的主题 › Windows › 最近逛病毒吧，很多用 windows 自带和火绒的都被勒索了

@Cytion 可能是我不熟悉导致，不过这也是严重的用户体验问题。我也知道网上说火绒多好多好，我也是网上那些听多了才去试的。总的来说，如果不是流氓，那么火绒团队技术实力存疑，还得再等他们优化几年再说

2022 年 5 月 1 日

回复了 DIO 创建的主题 › Windows › 最近逛病毒吧，很多用 windows 自带和火绒的都被勒索了

@Cytion 在我看来，火绒比较流氓。火绒给我最大的用户体验是，装完 cpu 就稳定 20%+，不管让它待多久还一直这么跑，像是在挖币一样，设置里也没找到怎么设置回去，网上没搜到有效的解决方案，一小时后实在受不了然后卸了。360 感觉还好，主要问题是偶尔来个弹框，只要在控制面板里双击（假装卸载），然后点去广告弹窗就好了。

2022 年 4 月 27 日

回复了 a523 创建的主题 › Python › 为什么面试官喜欢问某一门语言（比如 go 或者 Python ）的内存回收机制？

1 、crud boy 工作是不需要知道 gc 内容的，不过面试官通常考虑到可能因为项目扩展需要，有一些深度方面的知识的人来写 crud ，能比只会最简单那帮人靠谱。因此一般都需要问这个
2 、写了 8 年不了解 gc 啥的其实没啥问题，技术有两个发展方向，一个是架构，一个是应用，前者就要求一些很深的技术，后者要求能把极简单的技术整合一下，做成有用或有意思的东西，能在 github 收千星，我猜测你走的后者，不过你得判断一下你走的路子
3 、写八年 crud 也可以，不过这是个人选择，别人问 gc 啥的是他们的路子，道不同不相为谋

2022 年 4 月 27 日

回复了 fawdlstty 创建的主题 › C++ › libfv：基于 C++20 的异步 HTTP 库

@hez2010 找到一篇文章 https://zhuanlan.zhihu.com/p/395250667
里面有句话“实际上，Future/Promise 并不适合性能要求很高的生产环境，比如游戏引擎任务框架等”
co_await 也是 Future/Promise 吧。中间数据传递的类型都被擦除了（有状态，但编译器在优化时没法和 continue 方法一一对应），从 awaitable 对象外部看来也只知道返回类型是什么类型。使得这关键字从目前设计看来，没法优化

2022 年 4 月 26 日

回复了 holmes1412 创建的主题 › C › 分享新思路：一个逻辑完备的线程池

勘误：“通过系统提供的 pthread 或者 std::thread 创建线程，就可以实现多线程并发执行我们的代码”
首先 pthread 和 std::thread 都不是系统提供的，系统提供的函数比如 windows 平台，api 叫 CreateThread （或类似名称比如 NtCreateThread ）。其次，“并发”应该改为“并行”（并发代表同时发生，并行代表同时运行）。
“但是 CPU 的核数是固定的”这句联系上下文不太准确，cpu 并行线程数不等于核心数，所以这儿应该把核数改为线程数。

2022 年 4 月 26 日

回复了 fawdlstty 创建的主题 › C++ › libfv：基于 C++20 的异步 HTTP 库

https://www.zhihu.com/question/475282755/answer/2209455717

2022 年 4 月 26 日

回复了 fawdlstty 创建的主题 › C++ › libfv：基于 C++20 的异步 HTTP 库

@ysc3839 好吧，我没认真看过，凭理解我感觉有 stackful 和 stackless 方案，然后默认它是 stackful 方案了

2022 年 4 月 25 日

回复了 fawdlstty 创建的主题 › C++ › libfv：基于 C++20 的异步 HTTP 库

@ysc3839 你是对的。我记错了。co_yield 涉及保存 /加载现场

2022 年 4 月 25 日

回复了 fawdlstty 创建的主题 › C++ › libfv：基于 C++20 的异步 HTTP 库

@hez2010 赞同你的观点，原理上非常高效，并且通用。不过，回调在汇编层面，寄存器或线程栈里存入参数，call 就行了； co_await 复杂很多，一方面涉及保存 /加载现场（ pushad/popad ），另一方面还得有状态机等等。在具有真正需要等待的任务面前实际上没法做比较明显的优化，顶多也就是 llvm 的那一套，逻辑一句也少不了。c#在异步这一块往前跑了很多年了，基于 Task<>的优化方案是通过 ValueTask<>，实际原理是没有真正异步等待的优化为同步调用实现。它也没法优化真正需要异步等待的情况

1 2 3

❮

❯