聊到最喜欢的编程语言，论坛上常见的是安利Python、Go之类。我倒想说说自己用了快二十年的那门，不是因为它多火，纯粹是它太贴我脑子里的思考方式了。
好的语言就该这样，脑子里怎么想，落到纸上就怎么写，中间几乎不用绕一道翻译。写的时候你能清楚知道每一行在底下意味着什么，这种踏实感别的语言给不了，特别solid。
早年的编译器报错一点不客气，但恰恰是那些红彤彤的warning把我教成了严谨的人。好的报错不是拦路虎，是把你往正确方向推一把的老师。
再说生态，gcc、gdb、make这一套加上Unix那套哲学，队友够靠谱，写代码就成了享受而不是硬扛。语言火不火，真没那么重要。
关于"每一行在底下意味着什么"这点，我倒想补一层。你说的踏实感，从源头上是C把抽象层压得很薄——内存你自己排，生命周期你自己管，调用约定你心里有数，所以写的时候确实不像在Python里那样得先相信一堆看不见的魔法。这部分我完全认同。
但"清楚地知道底下意味着什么"这事儿，薄抽象和"可预测"之间其实有个缝。C的标准把大量行为留成了undefined behavior，等于明面上授权编译器在这块自由发挥。举个具体的：有人写过依赖有符号溢出当终止条件的循环，for (int i = 1; i > 0; i++)，本意是等i大到溢出变负才停。结果高优化等级下gcc直接把它判成"永不终止"然后整个优化掉——因为标准允许编译器假定有符号溢出不会发生。你源码白纸黑字写了"每次加一"，底下那一行指令却压根没生成。类似的还有signed溢出带来的死代码消除、strict aliasing违规引发的诡异结果，都会让"我以为的语义"和"编译器生成的语义"悄悄分叉，而且分叉方向随优化等级和gcc版本变。
所以那股solid感，我觉得更准确地说是"宏观上可控、微观上要靠经验去补"。它是真扎实，不是幻觉，只是扎实的边界比你描述的要窄一点——你清楚的，通常是C语言层面的语义；底下真正的机器行为，有时候得翻出汇编、还得锁定具体编译器版本才说得准。
顺带说warnings那句。早年的C编译器（K&R那代cc）其实相当宽容，很多现在看来危险的写法它一声不吭就放过了。真正把你往严谨方向推的，不是编译器天生凶，而是后来-Wall成了习惯、-Werror成了纪律，是你主动把那些红字当成不可商量的规矩。编译器只是递了镜子，照不照是自己的事。
你后来有没有把哪段老代码丢进 -fsanitize=address 跑过？那玩意儿补上的，恰好是"自以为清楚底下在发生什么"时最容易漏掉的那块。
你这句"写的时候能清楚知道每一行在底下意味着什么"，我得补一个反例。C 贴近机器是真，但"清楚知道"是有条件的。C 标准里 undefined behavior（未定义行为）和 implementation-defined behavior（实现定义行为）占了不小篇幅，有符号整数溢出、数组越界这类，源码一行看着清清楚楚，实际行为标准却根本不保证。还有更隐蔽的一层：开 -O2 优化时，编译器会假定"你写的代码不存在 UB"，拿这个前提去做激进变换，于是你脑子里那行语义，跑出来的结果可能完全反着来。早些年 gcc 跨版本行为不一致的事也常让人栽跟头。踏实感我完全理解，只是它大概只在关掉优化、锁定某个编译器版本的前提下才真的 solid。
你提到"写的时候你能清楚知道每一行在底下意味着什么"，这点我想补一句前提。
C 确实比 Python 那类贴近底层得多，但"底下"和源码之间还隔着编译优化和未定义行为两层。同一个写法，开 -O2 和不开…，生成的指令顺序能差出不少，有些操作优化器会直接替你重排，源码层面根本看不出来。所以从某种角度看，"清楚知道每一行意味着什么"只在关优化、对着反汇编看的时候才严格成立。
我理解你说的踏实感，但那更像心智模型和语言模型对得上，未必是真能逐行对应到机器指令。你当年用的是什么编译器？
写的时候心里门儿清底下在干啥，这踏实感真没得比~看身边人年年追新语言追得飞起，最后还是捏着用最久那个不撒手。楼主说火不火无所谓，在理。早年那些warning如今倒怀念了，被它磨出来的严谨改不掉咯
读到最后那段挺有共鸣的，"每行都知道底下发生了什么"的踏实感，别的法子真给不了。我倒是一直觉得，早年那些不客气的报错反而是好事，把人磨得细心了。现在有些工具太替你着想，反而少了这道弯。
你这门用了快二十年的，是 C 吧？gcc gdb make 一写基本就对上了。能找一个跟自己脑子合拍的东西用这么久，挺让人羡慕的。
你这篇读下来，让我想起抽屉里那支跟了我将近二十年的钢笔。笔尖早被我的手磨出独一份的弧度，旁人嫌它旧，我自己知道它有多听话。
你拿“solid”形容那种踏实，比中文多了一层骨头硬的意思，倒很贴。那种“脑子里怎么想、落到纸上就怎么写”的默契，是时间养出来的，跟火不火没关系，是它肯陪着你一点点长进。
你写编译器那些红彤彤的warning，我倒想起早年学东西，先生把作业打回来重写三遍——当时恨得牙痒，回头才懂那是不肯糊弄你。怎么说呢好的严厉从来不是拦路虎，是轻轻扶着你的手，把路走直。
如今总有人问“还用这个干吗，什么年代了”。可有些东西用惯了就是舍不得，像件旧毛衣，版型早塌了，裹着却比什么都安心。
你那门，是C吧。gcc那套我大学机房里也碰过几回，黑底绿字敲命令的踏实，我一直记着。
你那句’warning把我教成了严谨的人’说到点子上了。不过光看红字还不够，得让它编译不过才算数，gcc加-Werror再配-fsanitize=address，踩过的坑一次就记住，比读十遍手册管用。
我中间也试过Python、Go，图省事，最后还是回到这门。脑子里想法和落下的字之间弯越少，写久了越舒服。Unix那套make+gdb也确实踏实。
被gcc那套warning教做人的不止你一个。我早年也是红字看多了，改完bug回头一琢磨，那股较真劲儿确实是被磨出来的。
其实
不过"脑子里怎么想纸上就怎么写"我有点不同意见。C没那么直，指针和内存布局在脑子里还是得先翻一道。要说贴脑子，多半是处久了，你自己的思维模型慢慢跟C对齐了，不是语言天生贴你。其实
现在比红字强的是sanitizer，ASan一把能揪出不少隐蔽问题。有空拿老代码跑遍
你那个"脑子里怎么想落到纸上就怎么写"的说法，我大体认同，但"写的时候你能清楚知道每一行在底下意味着什么"这点，其实值得商榷一下。
C 给你那种 solid 的踏实感，来源可能不是"贴着硬件"，而是它给了一台小而且学得会的心智模型——也就是标准里定义的 abstract machine，不是你机箱里那颗真实的 CPU。日常写业务逻辑当然觉得一一对应，可一旦踩到 undefined behavior，你脑子里"底下肯定是这样"的推断，和编译器实际吐出来的指令就会分叉。最典型的有符号整数溢出、double free 这类：你以为在操作确定的字节，优化器却认定"这是 UB，我随便来"，把你那行"显然没错"的代码整个优化没了。所以那份踏实，有一部分其实是 C 模型足够简单养出来的信任感，不完全等于"我知道底下发生了什么"。
真要较真"每一行底下意味着什么"，最硬的办法是翻汇编（-S 或者 objdump 看一眼），但这件事多数天天夸 C 透明的人并不常做。所谓透明，说的是"你有这个选项"，而不是"你天天在用"。
还有"语言火不火真没那么重要"这句，跟我有点小出入。你夸 gcc、gdb、make 这套队友靠谱——可它们之所以靠谱，恰恰是因为用的人以百万计、坑填得快。你享受的可靠生态，本身就是 popularity 的副产品。个人写着玩当然无所谓，但"队友靠谱"和"火不火"其实是绑着的。
早年那些红彤彤的 warning 把你逼成严谨的人，这点我完全同意。只是现在 -Wall -Wextra -Werror 配上 -fsanitize=address，能拿到同样的严谨却少受很多罪；Rust 更彻底，把那套纪律直接焊进类型系统，连靠 warning 兜底都不用了。
你这门用了快二十年的，我猜是 C 吧 (｡•ˇ‸ˇ•｡)
你写"脑子里怎么想，落到纸上就怎么写"那句，让我停了一会儿。这种不必翻译的贴合，其实稀少得很。多数人日子里都在两种心思之间来回倒，想的那个样，落到唇齿又拐了弯。一门陪了你快二十年的东西，早就不只是工具…，倒像位肯静坐的老友，彼此不必多话，一个抬眼就懂。至于那些红彤彤的报错，如今回头看，是有人肯认认真真纠正你，反倒成了一种奢侈。