事情是这样的。楼主NG马上入职一家中厂，hr给了几个组让match。我联系了之前在这家公司工作的一位前辈，他正好在某个team A的隔壁team工作过，向我强烈推荐team A，说team A和他之前所在的隔壁team的大一点的org都是有名的神仙org，整体氛围比较好， 很轻松，几乎没有pip和layoff发生过。
我听了之后马上联系了team A的经理，这个经理之前一直是IC，在公司也10多年了，2年前才转的mgr。这个经理也很好，马上跟我约了meeting，向我介绍组里情况，聊得也很好，后面也保持了联系。不过说实话，如果光看技术栈，我可能不会选择这个组，因为属于内部组，所以技术栈相比有些组不太前沿，比如分布式这些。当然也可能我信息有限还没有太深入了解。
这时候问题出现了。公司说为了帮我onboarding，分配了一位级别很高的mgr给我答疑，比team A的经理大概高两个level。这个经理也很负责，邮件问我倾向于哪个组，我就说了team A。那个经理回邮件说他很熟悉team A，貌似之前也在那个组干过，或者当过经理。然后就是第一次meeting了，介绍完基本情况后，他就说认识team A和隔壁组的经理，听起来确实认识。不过后面他说了一些话，大概就是：这几个组都用C++，但是C++很难自学，选组的时候要看组里有没有懂C++的，否则不利于自己职业成长。而且新人不要想着for fun，要有迎接挑战的准备等等。 说完后让我觉得是针对team A的，当然，也有可能是我多想了。后来，我跟之前的前辈分析了一下，他觉得无所谓，这个经理级别高应该也犯不着得罪我一个ng，而且也影响不了我选组。
如今形势不好，作为没有身份的ng, 选组肯定是求稳，不出意外我应该还是以team A为第一目标。所以想请教有经验的前辈。这个经理的说辞算是pua吗？感觉这个经理人还不错，让我有问题随时联系meeting。以后跟他meeting有啥注意的吗？
1 个赞
你鉴定了吗？
你可以去泥潭翻翻轮子哥的选组看法
然后决定要不要虔诚地变成cpp的形状
（我的感觉是如果你cs本科期间没有变成cpp的形状， 工作可能差不多得了，不要勉强自己为不爱的技术发电
你喜不喜欢是很明显的 喜欢的话第一次看到某个不懂的概念应该就浑身刺挠不搞懂不休息了 要是没这个心态就好好当螺丝钉吧）
1 个赞
收束观测者
3
我还真是带着C天下无敌的心情参加工作然后逐渐变成C艹的形状的 
我印象很深当年我强烈认定BS说的“C++性能比C慢20%的原因是编译器不够好”就是BS
1 个赞
我朋友带着这个心态找了写Linux kernel的工作之后变成铁杆c粉了，天天嘲讽cpp
1 个赞
主要是很多人上完cs本科其实没有觉得任何语言天下无敌（也就是不会任何语言基本语法和crud之外的东西）
收束观测者
6
说实话linux kernel社区里绝大部分人（至少95%吧）能用C活下去是因为写的代码太简单而不是太难
跟硬件和底层打交道只需要短平快而不需要进行复杂的系统设计和处理复杂的功能抽象
这种一律建议去给nouveau当一年的主力维护者再来说C天下无敌
1 个赞
收束观测者
8
其实很简单，nouveau作为可能是唯一一个需要处理复杂系统工程的linux driver，用C把C++的虚函数和继承全部adhoc地实现了一遍然后才能干活
1 个赞
只能说曾经做type system的看到cpp的template也是一头包，还是c更返璞归真一点看着舒服
1 个赞
收束观测者
10
template确实有点奇技淫巧到走火入魔了
但是你不得不承认它真的把编译时能干的事情做到极致了
而且写的时候是真的爽，只不过代码维护火葬场
1 个赞
某个方面太钻牛角尖了也不好，smalltak把运行时能干的事情做到极致了然后呢
不过cpp确实是目前性能向的最优解，还是没办法
1 个赞
收束观测者
12
C艹主要还是历史包袱太重。我觉得放弃后向兼容，砍一砍以前的历史遗留垃圾轻装前进实现限定条件下的内存安全的话，吊打一下rust和golang还是不成问题的
前pl从业人员拒绝承认这个是个编程语言 
历史包袱是主流编程语言甩不开的，Java要是可以不管历史包袱可以解决不知道多少现在被人痛恨的问题
1 个赞
收束观测者
14
讲道理完全可以甩
做成extension，编译器可以选择开不开某个flag即可
你加个flag然后把以前的屎山修到可以编译的程度总比用rust重构要来得简单
实在太万年屎山了还可以选择赖在老版本C艹不动弹
还有pl是啥
programming language
感觉真没那么容易，之前见证某语言的大版本迁移，突出一个鸡飞狗跳 这东西理论到实际之间的坑实在是太多了，再遇上凑巧依赖quirk的library，画美不看，而且还得涉及到把旧的库都给重新编译一遍的问题，想想都是一头包，善待build system team的人吧 
1 个赞
收束观测者
16
只要没有ABI breaking change可以选择不迁移也不重编译
咱虽然没有呆过build system team但是一直是所在team的build system维护者
前司默认官方库稳定API只expose C API是有原因的
那到了整个公司的mono repo之后呢，规模大了之后能遇到的问题真是千奇百怪，ABI change是一方面，依赖quirk的代码咋办呢，历史包袱这东西太重了，没人敢拍板的
做一个东西的人只要考虑自己的东西就好了，改一个language的东西要考虑的可就太多了
1 个赞
收束观测者
18
不迁移，单独封装
《论为什么pImpl是最好的C艹设计模式没有之一》
恭喜你，发明了我最痛恨的场景，然后再隔着套几个library遇到类似的问题，然后又要互相重新重命名一堆symbol，刚看着别人踩完这个坑