- 主题:都说十年成就一个专家,为啥很多人20年C语言经验还是菜鸟?
因为年龄是啥都不干,只要躺着就会自动增长的东西。
【 在 xiakem 的大作中提到: 】
: 为何?
:
--
FROM 117.89.220.*
现在有ai,学rust没啥难度了。
到今天为止我猛写了3天的rust代码,每天都很专注的写14小时的那种。我已经可以确定我后面可以完全用rust开发了,我终于把用了20年的python+c组合,升级到python+rust了~
前几年我尝试过转rust,但都浅尝则止了。主要的问题是我学语言都是放到实际项目里学,都是先看半小时语言介绍然后直接开始撸代码,遇到问题google解决,边撸边学的搞。但rust用这种方式学起来很困难,在初学阶段遇到问题很难彻底弄清楚。然后项目进度摆在这里我也不可能停下来先去系统性的学习,很容易就放弃半途而废了。
现在有ai之后啥问题都能解答的清清楚楚,不用怕遇到问题解决不了。反而是遇到的问题越多对语言的理解就越深刻,所以就这几天的时间,一下子就完全掌握了。
现在我可以理解为啥之前学起来困难了。我之前的风格是pythonic的,喜欢的就是走一步瞧一步快速试错。我的这种学习方式是很依赖反馈的,而rust这门语言会逼着你必须把一切都想的清清楚楚明明白白,rust只要有点问题就不让你编译过,这样我就没有了正反馈。别说正反馈了,一次反馈都很难...这样学起来自然觉得难了。
掌握之后我可以说rust这门语言并不复杂,也没啥好陶醉的,但它确实是一门很好的语言。非常值得投资,来把一起加入rust教~
【 在 philbloo 的大作中提到: 】
: Rust 啊,社区作风是好为人师。
: 入门有点难度,所以上手之后容易自我陶醉。
:
--
修改:lvsoft FROM 117.89.220.*
FROM 117.89.220.*
没你想的那么夸张,你肯定没我老,但我也就是2天启动,猛写3天,然后感觉就掌握的很不错了。
你别说一周时间的投资都不愿意拿出来,那这确实是无解了。
【 在 philbloo 的大作中提到: 】
: 老了 没那精力了 现在的时间和脑力都用在想数学题上了
:
:
--
FROM 117.136.66.*
rust是一门综合来说设计的相当好的语言。在很多细节的取舍上平衡感把握的很好。
【 在 zeus2615 的大作中提到: 】
: 最近在看rust,它的各种特质让我觉得很可能是最适合我的语言。
--
FROM 117.89.220.*
我基本上排名前20的语言都能写。但我主力就追求2个极端,
一个是c,追求最高的执行效率和最广的运行环境。另一个是python,追求最高的写代码效率和最广泛的应用场景。
至于c++,我认为是浪费脑细胞的行为,不值得投入。至于scheme,haskell这样的FP,我也认为算是coder必须会的语言,但主要是思维上的拓展,我不认为在实践中用它干活有啥特别的好处。
大部分情况下我的这套c+python的组合干的还不错,但项目复杂之后就会存在需求交叉的中间地带。倒也不是说无法解决,只是两者都有各自的力不从心的地方,解决的比较dirty。
比如c缺乏强大的抽象能力,也更容易犯错,需要砸不少时间在debug里面;python在复杂项目的场景下开发效率会迅速退化,退到跟其他语言开发效率差不多,就失去了它的价值。
所以我一直在寻找能取代这套模式的更好的语言。我之前的想法是rust+go的组合,但之前rust这块一直没啃下来,加上ai生态基本上也没go啥事,所以就一直没升级。
我目前的感觉是rust在c这一端可以做到完美取代,并且还能往python那一端延伸一大截。这种情况下似乎rust+python就足够了。
【 在 philbloo 的大作中提到: 】
: 我写c的时候是当汇编来写的 从硬件开始设计 到软件就全都是读写寄存器
: python是用来写原型 computational group theory
: c++用在需要强类型 和数据架构比较复杂的地方 比如编译器中端
: ...................
--
FROM 117.89.220.*
我前面说rust这门语言平衡的非常好,就是这种感觉。
在核心设计思路上,rust走的是组合的路线,而不是OOP一堆继承的路线。这个就比OOP高明的多。我是感觉OOP这种模型有点太学院派了,rust的组合+trait的方式有点实践派的感觉,我从中感觉看到很多c的影子。这一点我可太喜欢了。
rust的问题我目前感受来说,主要是这种trait的组合很破碎。不像OOP,虽然OOP会搞出很深看了就烦的继承关系,但起码大家可以追根溯源找亲戚。当然OOP这种一切都要从root一层层派生下来的设计哲学我是很讨厌的,我认为就是脱裤子放屁。所以我超喜欢python的duck typing这种简单直接的方式。
但反过来,我现在理解了rust其实用了一种很巧妙的方式缝合了这种破碎感。比如rust里想把任何东西暴露出去都必须显式的加pub。而且这个pub不会继承,你得一个个大量的加。我刚开始学rust的时候对这个设计怨念很大,我甚至想用rust的宏来让我不用敲一堆pub自动把所有东西都pub出去。但我现在就理解了,这其实是让你尽量把各种相关的trait组合在同一个文件中。简单的说你想写出很破碎的代码它也不拦着你,但如果你不想敲一堆pub让代码看起来很丑,你就得自己去组织好它们的关系,把相关的东西放在同一个上下文里。
这个想法就相当的实践派。理解了这一点之后我发现rust里面有很多设计哲学都是在贯彻这个思路。比如到处都是的unwrap是在逼你去组织好错误处理机制。
我只能说,这个设计太天才了。所以我为啥一直在说rust的平衡感很好,而不是它的xxx多么的nb,就跟c++那样xxx啥都有啥都能干,我听到这种说法就想吐。
【 在 beep 的大作中提到: 】
: rust最坑爹的地方不在于所有权和生命期这些玩意儿,这些学起来材料太多了,最坑爹的地方我觉得在于你要是不熟悉库函数,连最常用的Option Result都用的跌跌撞撞的
: 然后就是从OOP范式出身的人,看到别人把trait用得出神入化,感觉无法望其项背
:
--
修改:lvsoft FROM 117.89.220.*
FROM 117.89.220.*
我的感觉是,rust是少有的能消除个性的语言。
上一个把这点做得很好的语言是java。但java是谁来写都写的跟裹脚布一样又臭又长。我觉得java写起来就特别的放松,我完全没有心智负担反正怎么写都是一泡屎谁来写都差不了太多~~
但rust是谁来写都会写的很好,都会有很好的设计,都会有很高的代码质量。它的很多底层设计会逼着你必须把事情做对...
比如我今天为了让代码能编译过,不得不飞线改硬件...因为我硬件上的设计有一处不合理的gpio功能共享,设计的时候我知道这是一个潜在的小问题,但我当时也没太在意放它过去了。结果这个共享带到rust里,因为所有权问题把代码搞的很麻烦。也不是不能解决但就是会让代码很丑,而且这个丑会扩散到整个系统,到处都是变得全方位的丑...最后我实在是看不下去了改硬件从源头解决....
这种根植于底层的消除问题,消除个性的能力,意味着它是一门彻彻底底为工程,为团队服务的语言。我实在是太看好它的前景了。
【 在 jyw 的大作中提到: 】
: 全文严重赞同。
: 跟 pub 写起来麻烦这点类似的,还有 mut。因为 Rust 更推荐慎重 pub、少用 mut。这样做一定程度上强迫开发者写出比放任不管更好的代码。
:
--
修改:lvsoft FROM 117.89.220.*
FROM 117.89.220.*
准确的说,其实也不能算是硬件设计的问题,而是rust在倒逼一切,逼到硬件设计上也得遵循它的生命周期管理的规范...
我这个问题其实很简单,比如我有几个同构的模块需要驱动,在固件里肯定是把它们封装起来的。
但这些模块有一个enable pin,因为虽然你也不能排除单独启动其中一个关闭另一个的需求,但一般是所有模块都要启动的。刚好这块板子gpio口很紧张,我就把几个模块的enable pin合并到一块去了。
然后在固件里封装自然就遇到问题了...因为rust不让我很轻松的share这个pin...
其实我本来是想的挺好的,我就写个sharedpin,在里面做了个引用计数,减到0才会disable这个pin。这样share 1个en的时候跟直接使用一模一样,而多次share也不会产生恶性问题,一切都挺合理。然后首先这样搞肯定是mutable了,多重mutable引用肯定是不可以的。那么规范的做法就是arc/rc + mutex。但嵌入式环境是no_std会有很多限制。虽然这些不依赖std但也会依赖alloc,我也不太想在嵌入式系统中动态分配内存所以否决。然后我用refcell封装了一下把sharedpin对外变成immutable。然而虽然消除了多重可变引用问题,但毕竟还是需要引用的,那封装的时候就必须要声明生命周期...然后因为这个pin相当的底层,这个生命周期声明就被传播的到处都是...其实本来我也是想捏着鼻子就这么算了,反正standalone版本编译也过了。但后面还有个用rtic框架的版本,这个时候rtic又不允许我这么搞了,因为它有它自己的资源管理机制,不允许我声明生命周期...所以如果要在rtic下用,我就得迭代设计,把这个sharedpin做成一个独立的task拎出来单独管理...想了想为了share一个pin这尼玛实在是太杀鸡用牛刀了。我抄起板子改了下线,每个模块一人一个enable这样就消停了....
讲真,用c写会觉得共享个pin多大事,虽然有点小问题,也就是留个心眼的事嘛。谁想到rust下会引出这么多的麻烦...但你想怪rust吧,它也没任何问题,恰恰相反它正确的很,实在是太tm正确了... standalone版本虽然丑,但人家把生命周期管理的好好的,没任何毛病啊。然后换rtic框架之后就不再是简单的standalone了,自然得按照rtic的设计把它分离成一个task重新设计架构,也非常的合理...
所以搞了一天我有点脱力...要么en一人一个,要么不要封en...
但en一人一个如果来10个模块那岂不是要浪费10个pin;反过来不封en,哪有调用一个库还需要在外面单独使能下的...这叫啥鸡毛封装嘛...
所以我一直想找个各方面都完美的方法。结果折腾了一天还是回到了起点...
【 在 jyw 的大作中提到: 】
: Rust 前景非常看好,相信以后会有越来越多项目从 c++ 甚至 c 转向 Rust,系统编程语言这块最有前景,除此之外系统工具领域也不输 Go,需要高性能的其他业务场景应该也能也能有一席之地。
: 通过他还能发现硬件设计的问题,这个一般还真想不到,意外的惊喜……
:
--
修改:lvsoft FROM 117.89.220.*
FROM 117.89.220.*
最近又高强度写了几天rust,又有些新的体会。
rust的严谨这个东西可能还是只能在实践中才能100%的体会。
这几天我被逼成了我最讨厌的人...就是能把一个泛型写出好几行的那种...
这种代码我看到了都是要喷的,谁想到我自己会写出来...
可能我在python下养成的习惯和风格,在rust里确实不太兼容。rust下架构真的得严肃的对待...不然强行编译过也是这种很丑的代码...
不过总的来说感觉还是很不错的,另外我觉得rust开发效率是更高的,并不存在比别的语言需要多投入精力的问题。我目前总的来说还是在脑波对齐中,有点波折也正常...
【 在 zeus2615 的大作中提到: 】
: 我是觉得rust的严谨性,筛选了人员,对我很有价值。
: 写java,反正怎么都能过,再菜的人也能写出能work的代码。c类的,即使容易炸,但大多数人也能写出个勉强能跑的东西。
: 我写东西是比较严谨的,那结合rust相当于就是我投入相同的精力,或者略多一点,能产出更高效的东西,相当于我单位产出大幅提升了。
--
FROM 117.89.220.*