- 主题:Goodbye, Rust. I wish you success but I'm back to C++[zz]
rust对我来说在嵌入式这个生态位已经无敌了。
当然，整个嵌入式领域非常大，倒也不能说rust统治了嵌入式，但在最常用的几个点带来了完全不同的风气。可以说这很多方面都碾压了c/cpp生态。
【 在 DreamDreams 的大作中提到: 】
: 暂时看 华为 人才储备和 江湖地位都不够
: 大概率 还不如rust， 如果rust 在Linux Kernel里 玩的好
: 机会 还是 挺大的
: ...................
--
FROM 39.144.244.*
比如4bit mcu，连c语言都没有，只能用它独创的汇编操作它独创的寄存器...
不过现在有了ai都很简单了，这种mcu把spec丢给ai然后给它一段python代码让它自己figure out就行...
【 在 DoorWay 的大作中提到: 】
: 你这个属于碾压了。我知道的一些嵌入式开发，还停留在C语言都用不全的地方，就是操作寄存器设置状态，完了。
--
修改:lvsoft FROM 101.229.189.*
FROM 101.229.189.*
你不懂嵌入式，所以会有这样的想法不奇怪。
你这个想法成立的前提是存在一个类似os的角色去抹平硬件差异。
但嵌入式领域很多场合资源极其有限，到了连一个hal库都嫌太重，或者甚至一个printf都嫌太重的程度。
同时嵌入式的多样性远比你想象的要多的多。
我为啥要夸rust，就是因为rust是第一个把这个事情做的很不错的语言。
【 在 hgoldfish 的大作中提到: 】
: 其实吧。嵌入式领域只需要增加个 crates 或者 pypi 这样的包管理机制，就已经是划时代的进步了。至于类型系统、内存安全这些都比较次要。
: 这个领域的程序员天天闭门造车，实在是浪费青春。
:
--
FROM 101.229.189.*
嵌入式分两种，一种是mcu，没有mmu，rom大概几MB，RAM大概几十到几百KB。
这种一般是no_std，一般来说没有heap（可以有，但通常来说没有）
一般不会用到map。
另一种是soc，有mmu，跑标准linux，这种一般跟pc没啥太大的区别。
当我说嵌入式生态的时候我特指前者
【 在 hgoldfish 的大作中提到: 】
: 顺便问一下，听说 rust 的 map 使用的是 b 树？这个数据结构在嵌入式底下，相对 c/c++ 常用的红黑树会不会更消耗资源？
: b 树有个好处是支持 cow，也就是说可以很方便地支持 immutable，很契合现在搞并行、多核、并发。
:
--
FROM 101.229.189.*
rust在嵌入式下的感受我本版说过不少吧，circuit版应该也有。不过水木现在根本就不是个说这是事情的地方了。
我发帖一半是分享（吐槽），一半是给自己做个记录方便若干年后回来查看。
水木现在不让看老帖，所以我现在很多时候都直接发b站了。
回到你这个问题，其实我这次有个case就是0rust + 0嵌入式经验，但他本人是个c++老手。
直接上手做项目轻松搞定，作为对比他后来用c++跟着官方sdk的例子搞，连个helloworld都搞了2天才点亮led...
所以真别这么想，我是觉得rust没啥问题，在我看来它跟我不太兼容的唯一的问题就是在用它之前需要想的非常清楚。我习惯不想清楚，而是先用python启动项目，边写边想边迭代。rust对这种开发模式是不太友好的。
【 在 DreamDreams 的大作中提到: 】
: rust 我感觉 另一大 问题是，很难 作为 第一语言
: 0 编程基础可能没法学会，尤其嵌入式本来就一堆 要学的 了， 再
: 加上rust 估计劝退率太高
: ...................
--
修改:lvsoft FROM 101.229.189.*
FROM 101.229.189.*
那只是你在用过去的思维想当然。rust在嵌入式下的生态相当丰富而且进化超快，比所谓的官方工具链强了不知道多少。
【 在 esmile 的大作中提到: 】
: 不过很多环境下压根没有提供rust的工具链啊。。。只有c/c++的。
:
--
FROM 101.229.189.*
我招了两个机械工程师，而且毕业的学校连211都不是，对电脑一窍不通，过半年等他们把机械的活能干利索了后我会让他们搞搞嵌入式，到时候就必须上rust了。
我是觉得一张白纸也还好，更重要的是看悟性。
【 在 DreamDreams 的大作中提到: 】
: 你得教会个编程小白把rust作为 第一语言 才能算 有发言权
: 至少凭我的 感觉，我没法给一个 程序都不会写的 人 解释rust这些 概念
: 想想就头疼
: ...................
--
FROM 101.229.189.*
rust是秒过的，c++秒过的只是编译好了固件，但烧上去没有任何反应，然后他就不知道该怎么办了，各种改写cmake一顿折腾。更要命的是我把我的template发给他也没解决问题...我的template里面一切都是我自己写的，也不依赖商业工具链，但还不对我就不明白了，最后他也没说怎么搞定的，应该是哪里配置上的一个小问题卡了他很久。
【 在 DoorWay 的大作中提到: 】
: 亮点是c++老手，照跑通C++例子要两天？哈哈哈哈? 反而Rust快一些。
: 那主要是配置环境吗，还是哪里差了，他有没有讲
--
FROM 101.229.189.*
这就是生态问题啊，他要搞得就是最常见的stm32，但这玩意官方自己都封了至少三个互不兼容又看起来很像的sdk出来。
他一新手自然被迷惑了。不说他，我也是把这个坑踩了几遍才意识到官方sdk是多么的sb的。
另外硬件有很多问题本来就是文档无法100% cover的，他作为配过无数复杂系统的老鸟，他习惯的也是先严格按文档做一遍的风格。我甚至觉得他跟文档跟的过于严格了。比如文档要求他用jlink烧，tm都快2025年了谁还用这个。
【 在 esmile 的大作中提到: 】
: 问题就是很多时候文档不对。
: 还有很多时候有人不知道老老实实按文档做。非要自作聪明。
:
--
FROM 101.229.189.*
有没有可能，是看起来很好的文档有很多呢？
比如stm32这种使用非常普遍，然后低水平使用者很多的场合，自然会产生大量低水平文档。你要找到你以为的那个“好文档”，要先去屎里淘金。而用rust就完全没有这个烦恼，我至今还没见过低水平的rust代码。
【 在 esmile 的大作中提到: 】
: 多半是文档没写好，一个step by step的正确文档的话，无论啥都很快的
:
--
FROM 101.229.189.*