没啥c/c++不能做的。

c抽象程度低，c++抽象机制多规则少自由度高，rust抽象能力好又有足够规则限制，然后就是各种取舍。喜欢自由就不适合rust，要限制复杂度rust能帮些忙。

实话说rust写unsafe代码弄指针有那么点臭长，个别语法比如没有 p->a 运算只能 (*p).a 我就不理解，自己没有稳定abi（可以用c abi），做偏底层的部分有时候不适应。但稍稍不那么底层的代码就比c舒服了，no_std 也比 c 强。

我也就在几M内存的linux写过小东西，bsd配工具链就有点费劲，bare metal没玩过。
【 在 horkoson 的大作中提到: 】
: mcu这些跑裸机或者freertos老老实实用C，linux这些用C和cpp都可以。。。
: 请问有是什么业务场景是C/C++搞不定，必须上rust的？
:
: ...................
--
修改:milksea FROM 114.249.220.*
FROM 114.249.220.*

谢谢科普，相信rust肯定有一套很完整的工具，否则您也不会这样推崇。

我得抽时间看看，跟上时代。哈哈哈

不过总觉得C已经是很直接的语言了。再抽象的前提下肯定需要解析，这类语言从内存到目标文件的flash占用，在工控领域这样的单片机横行的地方，估计很难。比如128KB flash 32KB的ram，这样比较经典的stm32F3、stm32F4系列处理器上，我用C已经各种节省才勉强能实现功能。rust恐怕不太现实吧？

【 在 milksea 的大作中提到: 】
: no_std 和裸 c 是一样的；有堆分配器实现个 alloc 还能用容器挺好；有 std 的话 rust 要依赖 c runtime，占用和 c++ 应该相当。
: 工具链方面，llvm能支持就差不多。rust c book 有一章是支持的目标列表。rtos这种可能是不支持的，bare metal反而有一些支持。
--
FROM 114.255.72.*

能问下，为什么你这样大力推rust吗？

【 在 z16166 的大作中提到: 】
: no_std时，直接调用HAL，stm32f3xx-hal、stm32f4xx-hal等都是开源的，代码也可以很小
: 试了才知道
:
--
FROM 114.255.72.*

rust 其实只要一个改变。就能大火:

把 unsafe 删了，编译器直接编译 .c 代码。类似于 zig 一样，zig 的编译器同时也是 c 编译器。

【 在 milksea 的大作中提到: 】
: 没啥c/c++不能做的。
: c抽象程度低，c++抽象机制多规则少自由度高，rust抽象能力好又有足够规则限制，然后就是各种取舍。喜欢自由就不适合rust，要限制复杂度rust能帮些忙。
: 实话说rust写unsafe代码弄指针有那么点臭长，个别语法比如没有 p->a 运算只能 (*p).a 我就不理解，自己没有稳定abi（可以用c abi），做偏底层的部分有时候不适应。但稍稍不那么底层的代码就比c舒服了，no_std 也比 c 强。
: ...................
--
FROM 27.154.93.*

llvm是编译期的，占用有什么夸张的？和gcc差不多啊。
【 在 hgoldfish 的大作中提到: 】
: 我一直没想明白，为啥 llvm 的占用会那么夸张。上百兆。
:
: 【 在 milksea 的大作中提到: 】
: ...................
--
FROM 114.246.238.*