現在年輕人都不學C語言了嗎

這個我知道，但是乾脆沒人申請，或者簡歷關都不過，我也沒辦法，現在能過簡歷的都不是中國人或華人。
美國公司不會也沒必要把海外的用H1b弄過來，案例極少，有也是L1，最後還是要回去
的。如果他們在海外在別人幫助下能力強，那再好不過了，1/5的工資換來更好的結果
。現在打壓大陸是政治正確，未來這樣的情況會更多，華人不論在美國或是大陸，都將越來越難。

【 在 whyatt (BBQ) 的大作中提到: 】
: 这种很多时候，是各种渠道知道了这个REQ要做什么PROJECT 和JD. 然后简历裁剪的
。
: 简历不能全信啊。现实很残酷，印和国人的简历数量是9:1. 现在VIRTUAL 面试， 其实
: 就算做题也很可能是很多人在帮一个人面试。 就比如OFFSHORE 的合同工，有时候是很
: 多人在幕后帮他做事，觉得他很厉害，帮他H1过来后，才发现有很大落差

我們要求視頻，有快速口答的很多零散問題，不會的很難裝，就像你說的move一樣。
但是我們面試要求不高，白人同事明顯放水，他們更喜歡印度人的交流方式，國人明顯更生硬不討喜。

【 在 bihai (学得不好) 的大作中提到: 】
: 这倒是一个问题，有没有帮助别人面试的方案？没语音，但是可以通过摄像头看到问题
: ，再通过另一个电脑的屏幕提出思考方案？面试一小时一千块如何？
: 。

對，我只要求轉專業的或者CS minor的修完類似的這五門課，但是他們都沒有。修的水課跟C語言和Linux完全無關。讓他們寫course projects頂替，也寫不出來。這些人根
本就不可能一年內上手，進來只會拖後腿，起碼合格的小印不會拖後腿，而且也很拼。

【 在 digua (姚之FAN) 的大作中提到: 】
: 他们需要精通系统软件和C的人。操作系统内核代码的绝大部分是用C写的，工具软件一
: 般用C或C/C++来写。
: 不过澄清一下，不是说突击一下C语言就可以了。一般来说，CS专业系统方向的学生，
: 需要学体系结构，操作系统，编辑原理，计算机网络，很多时候还有高性能计算。这些
: 课程一般都会用到C语言，都修完了自然就精通C了。:-)

【 在 magagop (magagop) 的大作中提到: 】
: 我就不做刺頭了，大老闆自有他的決斷，在美國失敗的項目也不少。
:
: 叫你老板去Google这两个关键词：Intel Whitefield
:

我有接触到不少喜欢C很有天赋的年轻人,不论国籍. 不知你们有没有兴趣探索不同得开发方式.

这是我们的产品: http://www.mitbbs.com/article_t/Programming/31598485.html

【 在 magagop (magagop) 的大作中提到: 】
: 這個我知道，但是乾脆沒人申請，或者簡歷關都不過，我也沒辦法，現在能過簡歷的都
: 不是中國人或華人。
: 美國公司不會也沒必要把海外的用H1b弄過來，案例極少，有也是L1，最後還是要回去
: 的。如果他們在海外在別人幫助下能力強，那再好不過了，1/5的工資換來更好的結果
: 。現在打壓大陸是政治正確，未來這樣的情況會更多，華人不論在美國或是大陸，都將
: 越來越難。
: 。
同义, 但是也未必是坏事. 这能让我们更深入思考事务的本质

我在2017年转行的时候，面试被问了如何遍历一个二叉树。但是一个巴西人可能比较黑就被问了很难的问题。这个巴西人现在在亚麻逊了，能力还是有的。

【 在 magagop (magagop) 的大作中提到: 】
: 我們要求視頻，有快速口答的很多零散問題，不會的很難裝，就像你說的move一樣。: 但是我們面試要求不高，白人同事明顯放水，他們更喜歡印度人的交流方式，國人明顯
: 更生硬不討喜。

【 在 bihai (学得不好) 的大作中提到: 】
: FLAG为啥需要会C的啊？
: Intel
: AMD/

个人看法, 喜爱C人一般有 passion, 成为好开发人员的比例很高.

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 這件事情和老印小印沒關係。
: 中國人擠破頭搞熱點這個傾向，全世界第一這個沒什麼爭議。所以你這個沒machine : learning的關鍵字，中國現在的junior level的都懶得理你。如果是真的找不到活幹，
: 也要說自己是full stack的，至少聽起來流行。問題是C寫出Linux下面不崩的代碼還需
: 要的能力不低，中國人怎麼會來？
: 老印我的觀察在到管理層之前，都處於survive mode，基本上是給什麼就做什麼的，做
: 得好不好另說，但是至少表示要幹。當然不是沒問題，很多infra的項目就是老印給堆
: 了一堆垃圾代碼最後基本上不能用的。但是不管怎麼說，坑肯定是別人占了。
: bend
: EXCEL

非常佩服你对很多事务的见解. 我认为ML很难支撑渐进式改进(incremental
development),商业潜力有限.长期ROI不高.

有一個在大型數據處理方面幹過很多年的人說一個點我覺得很不錯，就是其實現在大部分的ML項目在setup的時候就知道研究這些數據其實沒有revenue，本質上是一堆人在一起開會，大家搞點開發經費然後過日子。

這種場合當然不會去要C這種乾乾淨淨，整個生態就是爲了交付的語言。但是一旦對交
付，部署的要求一高，一個項目唯一不用C的理由是你招不到合適的C開發人員，我這麼多年來從來沒看到過不一樣的情況。
【 在 cstack (cstack) 的大作中提到: 】
: 非常佩服你对很多事务的见解. 我认为ML很难支撑渐进式改进(incremental
: development),商业潜力有限.长期ROI不高.

ML能扩大share。
AB，两个公司竞争一个market。
A做了广告，B没做。则B的share会下降。

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 有一個在大型數據處理方面幹過很多年的人說一個點我覺得很不錯，就是其實現在大部
: 分的ML項目在setup的時候就知道研究這些數據其實沒有revenue，本質上是一堆人在一
: 起開會，大家搞點開發經費然後過日子。
: 這種場合當然不會去要C這種乾乾淨淨，整個生態就是爲了交付的語言。但是一旦對交
: 付，部署的要求一高，一個項目唯一不用C的理由是你招不到合適的C開發人員，我這麼
: 多年來從來沒看到過不一樣的情況。

其实不少学校还是用C教入门基础课. UCF, UCSC, Harvard. etc.
巴西,乌拉,菲律宾,印度,土耳其,英国,德国,希腊, 西班牙,意大利,南非.

【 在 magagop (magagop) 的大作中提到: 】
: 最近招聘，本來想招會說中國話的，結果投的都是轉專業只會用python刷題的。我們要
: 求是精通C在Linux下開發系統軟件，或者Cpp在Linux下開發庫和優化編譯器，結果看了
: 20多個國人的簡歷，沒一個合格的。相反小印合格的簡歷很多，組裡討論後準備招小印
: 了，目前小印在組裡佔比超過70%。
: 我雖然有決定權，但我也不想一票否決，HR關就過不去。

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 有一個在大型數據處理方面幹過很多年的人說一個點我覺得很不錯，就是其實現在大部
: 分的ML項目在setup的時候就知道研究這些數據其實沒有revenue，本質上是一堆人在一
: 起開會，大家搞點開發經費然後過日子。
: 這種場合當然不會去要C這種乾乾淨淨，整個生態就是爲了交付的語言。但是一旦對交
: 付，部署的要求一高，一個項目唯一不用C的理由是你招不到合適的C開發人員，我這麼
: 多年來從來沒看到過不一樣的情況。

现实的情况是: 有不少喜爱C而且有能力的年青人找不到C的职位. 如果能如果能解决这个供需关系就有商机

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 有一個在大型數據處理方面幹過很多年的人說一個點我覺得很不錯，就是其實現在大部
: 分的ML項目在setup的時候就知道研究這些數據其實沒有revenue，本質上是一堆人在一
: 起開會，大家搞點開發經費然後過日子。
: 這種場合當然不會去要C這種乾乾淨淨，整個生態就是爲了交付的語言。但是一旦對交
: 付，部署的要求一高，一個項目唯一不用C的理由是你招不到合適的C開發人員，我這麼
: 多年來從來沒看到過不一樣的情況。

用C做cloud后台开发的优势很大. 我在弯区,不知到有没可合作

十年前我面试一个年轻人，她说用C，我问，你用C写了多少行代码？用什么开发环境?
怎么调试？

都不知道，从来没调试过。看来是我在Windows下习惯了，都不知道有人从来不调试。

【 在 cstack (cstack) 的大作中提到: 】
: 现实的情况是: 有不少喜爱C而且有能力的年青人找不到C的职位. 如果能如果能解决这
: 个供需关系就有商机

恩，可以多交流。
【 在 cstack (cstack) 的大作中提到: 】
: 用C做cloud后台开发的优势很大. 我在弯区,不知到有没可合作

C的本質我一直認爲是free（in spirit)，這東西要求你把整個系統走通。這樣訓練出
來的人能夠真正獨立的開發人員，可惜對把程序員變成螺絲釘沒有好處，所以企業方案用C的越來越少。

但是只要你需要真正build可維護，可擴展系統，其實C還是很平衡的選擇。雖然不是最開發最快的。
【 在 cstack (cstack) 的大作中提到: 】
: 现实的情况是: 有不少喜爱C而且有能力的年青人找不到C的职位. 如果能如果能解决这
: 个供需关系就有商机

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: C的本質我一直認爲是free（in spirit)，這東西要求你把整個系統走通。這樣訓練出
: 來的人能夠真正獨立的開發人員，可惜對把程序員變成螺絲釘沒有好處，所以企業方案
: 用C的越來越少。
: 但是只要你需要真正build可維護，可擴展系統，其實C還是很平衡的選擇。雖然不是最
: 開發最快的。

> 企業方案用C的越來越少。
是的, 这需要一个新的应用. 一旦C变成memory safe, "快速"开发就成了可
能.

你怎么认为 using C+ embedded scripting language 来平衡开发效力,扩展力,运行效力?

nivida大量找。汽车c代码有自己的各种安全标准。
要改c代码，适配各家之标准。

【 在 cstack (cstack) 的大作中提到: 】
: 现实的情况是: 有不少喜爱C而且有能力的年青人找不到C的职位. 如果能如果能解决这
: 个供需关系就有商机

我不認為C可以內存安全，Linux有很多MMIO操作，用C內連彙編直接控制硬件設備寄存
器的物理地址，不用虛擬地址，所以檢測出來的violation不一定是問題。

【 在 cstack(cstack) 的大作中提到: 】

:

【 在 magagop (magagop) 的大作中提到: 】
: 我不認為C可以內存安全，Linux有很多MMIO操作，用C內連彙編直接控制硬件設備寄存
: 器的物理地址，不用虛擬地址，所以檢測出來的violation不一定是問題。
:
:

你是对的, C的应用太广. 我应写 Portable C code 可以內存安全.

谢谢,
【 在 chebyshev (......) 的大作中提到: 】
: nivida大量找。汽车c代码有自己的各种安全标准。
: 要改c代码，适配各家之标准。

做游戏或者Fintech后台应该不错, 以前是C++做这块多

我很久以前用C++, 个人感觉C/C++跟新的这些 Go/Rust 比起来，
主要难用的一点是, tool chain比较难用
build 是外置的 make/cmake. package manager 基本没有.
你要是能把你的C工具做得跟 Go mod, Rust Cargo 一般好用就厉害了.
那样的话，我也愿意回来用 C/C++.
我看你的新compiler用来编译 C libraries 了,
能做个package manager, 再给C弄个易用的 build+package 系统么?

【 在 cstack (cstack) 的大作中提到: 】
: 用C做cloud后台开发的优势很大. 我在弯区,不知到有没可合作

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 做游戏或者Fintech后台应该不错, 以前是C++做这块多
: 我很久以前用C++, 个人感觉C/C++跟新的这些 Go/Rust 比起来，
: 主要难用的一点是, tool chain比较难用
: build 是外置的 make/cmake. package manager 基本没有.
: 你要是能把你的C工具做得跟 Go mod, Rust Cargo 一般好用就厉害了.
: 那样的话，我也愿意回来用 C/C++.
: 我看你的新compiler用来编译 C libraries 了,
: 能做个package manager, 再给C弄个易用的 build+package 系统么?

跟Go/Rust直截竞争不现实,要做他们做不好的. 要提高开发效超过Go/Rust, 嵌入脚本
语言是必须的.

你对fintech 有了解?

fintech你得问TeacherWei啊

游戏后台的话，我懂一点点, 说到C带嵌入脚本
国内的云风做了个skynet (C + Lua): https://github.com/cloudwu/skynethttps://blog.codingnow.com/eo/skynet
给你参考下

【 在 cstack (cstack) 的大作中提到: 】
: 跟Go/Rust直截竞争不现实,要做他们做不好的. 要提高开发效超过Go/Rust, 嵌入脚本
: 语言是必须的.
: 你对fintech 有了解?

cmake编译问题不大，而且公司可以运维指定同样的运行库
c++主要问题还是库设计问题。
iostream设计有问题，性能低下且不方便格式化
string很多其他语言常见的函数都没有
算法库使用iterator看上去更加通用，但显然没有其他语言浅显。
这些问题导致入门门槛高。入门之后，由于c/c++又希望高性能，而性能调优更是伤脑
筋。所以新人如果有其他路径，不必进入这个领域。码码模块简单多了

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 做游戏或者Fintech后台应该不错, 以前是C++做这块多
: 我很久以前用C++, 个人感觉C/C++跟新的这些 Go/Rust 比起来，
: 主要难用的一点是, tool chain比较难用
: build 是外置的 make/cmake. package manager 基本没有.
: 你要是能把你的C工具做得跟 Go mod, Rust Cargo 一般好用就厉害了.
: 那样的话，我也愿意回来用 C/C++.
: 我看你的新compiler用来编译 C libraries 了,
: 能做个package manager, 再给C弄个易用的 build+package 系统么?

是，一般如果需要部署的東西，純C比較困難，都需要用script來幹一些髒活。

不過目前我沒有看到對於C來說特別好用的scripting language，試過很多，python，
lua，之類的，但是最後一般還是回到shell上面來。

python實在是很慢，而且dependency太多，lua速度沒問題，但是dependancy也處理不
好。而且這些東西和shell比最大的問題是對系統作業控制能力低，最後還是得成天調
os的工具。那還不如shell 省事。

shell的問題在於：第一各種shell都有差異，只能認準一個shell，而且需要嚴格保證
環境一致，否則需要的工具都會變。第二shell出錯控制比較差，寫出健壯的script其
實不容易。第三，文本處理，parsing這些不夠straighforward。

【 在 cstack (cstack) 的大作中提到: 】
: 是的, 这需要一个新的应用. 一旦C变成memory safe, "快速"开发就成了可
: 能.
: 你怎么认为 using C+ embedded scripting language 来平衡开发效力,扩展力,运行效
: 力?

C不需要package manager。lib就是copy，頭文件也是copy。恰恰你覺得麻煩的原因是
因爲引入了太多的外部tools，而且過於追求移植性。

過了幾十年，平臺多樣性基本上已經成渣了。現在基本上只有兩種東西，X86_64/ARM, 操作系統只剩下三個，OSX/Windows/Linux. Linux 基本上只用支持Redhat/Ubuntu.

GO/Rust並不是好用，而是當前平臺趨勢導致portability比當年C需要支持的少很多而
已。C其實一樣可以根據這個情況做調整。舉個例子，99%的C項目其實根本不需要
autotool/automake，那些check大部分沒有任何意義，如果你只支持一兩個平臺根本不需要。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 做游戏或者Fintech后台应该不错, 以前是C++做这块多
: 我很久以前用C++, 个人感觉C/C++跟新的这些 Go/Rust 比起来，
: 主要难用的一点是, tool chain比较难用
: build 是外置的 make/cmake. package manager 基本没有.
: 你要是能把你的C工具做得跟 Go mod, Rust Cargo 一般好用就厉害了.
: 那样的话，我也愿意回来用 C/C++.
: 我看你的新compiler用来编译 C libraries 了,
: 能做个package manager, 再给C弄个易用的 build+package 系统么?

相比于python，shell没有测试开发...大规模软件之完整方法论吧？
【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 是，一般如果需要部署的東西，純C比較困難，都需要用script來幹一些髒活。
: 不過目前我沒有看到對於C來說特別好用的scripting language，試過很多，python，
: lua，之類的，但是最後一般還是回到shell上面來。
: python實在是很慢，而且dependency太多，lua速度沒問題，但是dependancy也處理不
: 好。而且這些東西和shell比最大的問題是對系統作業控制能力低，最後還是得成天調
: os的工具。那還不如shell 省事。
: shell的問題在於：第一各種shell都有差異，只能認準一個shell，而且需要嚴格保證
: 環境一致，否則需要的工具都會變。第二shell出錯控制比較差，寫出健壯的script其
: 實不容易。第三，文本處理，parsing這些不夠straighforward。

整個UNIX的啓動都是靠得shell，你覺得是linux啓動崩掉的可能性大，還是你去哪裏搞個python script的可能性大？

不是所有東西都有人有閒工夫成天寫blog，扯東扯西的，越底層的也這樣。活幹完拉到，扯蛋都是浪費時間。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 相比于python，shell没有测试开发...大规模软件之完整方法论吧？

部署用bash可以. dependency 很少.

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 是，一般如果需要部署的東西，純C比較困難，都需要用script來幹一些髒活。
: 不過目前我沒有看到對於C來說特別好用的scripting language，試過很多，python，
: lua，之類的，但是最後一般還是回到shell上面來。
: python實在是很慢，而且dependency太多，lua速度沒問題，但是dependancy也處理不
: 好。而且這些東西和shell比最大的問題是對系統作業控制能力低，最後還是得成天調
: os的工具。那還不如shell 省事。
: shell的問題在於：第一各種shell都有差異，只能認準一個shell，而且需要嚴格保證
: 環境一致，否則需要的工具都會變。第二shell出錯控制比較差，寫出健壯的script其
: 實不容易。第三，文本處理，parsing這些不夠straighforward。

Yes.

1. single header library
2. Linux/x86_64
3. pin the standard libc to get rid off autotool/automake.

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: C不需要package manager。lib就是copy，頭文件也是copy。恰恰你覺得麻煩的原因是
: 因爲引入了太多的外部tools，而且過於追求移植性。
: 過了幾十年，平臺多樣性基本上已經成渣了。現在基本上只有兩種東西，X86_64/ARM,
: 操作系統只剩下三個，OSX/Windows/Linux. Linux 基本上只用支持Redhat/Ubuntu.
: GO/Rust並不是好用，而是當前平臺趨勢導致portability比當年C需要支持的少很多而
: 已。C其實一樣可以根據這個情況做調整。舉個例子，99%的C項目其實根本不需要
: autotool/automake，那些check大部分沒有任何意義，如果你只支持一兩個平臺根本不
: 需要。

你看过Nim吗？

表面上来看优点很多，我没有深入试过

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 是，一般如果需要部署的東西，純C比較困難，都需要用script來幹一些髒活。
: 不過目前我沒有看到對於C來說特別好用的scripting language，試過很多，python，
: lua，之類的，但是最後一般還是回到shell上面來。
: python實在是很慢，而且dependency太多，lua速度沒問題，但是dependancy也處理不
: 好。而且這些東西和shell比最大的問題是對系統作業控制能力低，最後還是得成天調
: os的工具。那還不如shell 省事。
: shell的問題在於：第一各種shell都有差異，只能認準一個shell，而且需要嚴格保證
: 環境一致，否則需要的工具都會變。第二shell出錯控制比較差，寫出健壯的script其
: 實不容易。第三，文本處理，parsing這些不夠straighforward。

多谢解释

不过我更关心易用性，比如C/C++ 没有 Node/Python/Go 那种 CLI package manager
比如在 Go 的 go.mod
运行>go mod tidy,
运行后, 项目文件夹里装上的 lib 都有 hash value lock 版本
这样的话, 设置或重新设置个开发环境就非常简单
肯定比 copy lib 文件简单多了
现代的语言都有这个工具，如果没有，小年轻很难爱用

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: C不需要package manager。lib就是copy，頭文件也是copy。恰恰你覺得麻煩的原因是
: 因爲引入了太多的外部tools，而且過於追求移植性。
: 過了幾十年，平臺多樣性基本上已經成渣了。現在基本上只有兩種東西，X86_64/ARM,
: 操作系統只剩下三個，OSX/Windows/Linux. Linux 基本上只用支持Redhat/Ubuntu.
: GO/Rust並不是好用，而是當前平臺趨勢導致portability比當年C需要支持的少很多而
: 已。C其實一樣可以根據這個情況做調整。舉個例子，99%的C項目其實根本不需要
: autotool/automake，那些check大部分沒有任何意義，如果你只支持一兩個平臺根本不
: 需要。

我用过。nim之语法设计的很好。因为本身是pascal系的。
但是标准库质量与接口稳定性，gc是不是线程安全什么的各种问题，很难说清楚。

因为此类原因。没有资金支持的小语言基本上只能在很小的范围内自用。
nim之实用性。说实话还不如object pascal。
pascal历史悠久，社区稳定。
最近nim又说要在未来要添加move rule。越来越乱了。
【 在 dracodoc (david) 的大作中提到: 】
: 你看过Nim吗？
: 表面上来看优点很多，我没有深入试过

C語言也可以被管理，只不過是基於源代碼的，用git的可以配合repo，需要配合java的用bazel，喜歡python的還有scons，通用一點的可以是cmake，選擇有很多啊

【 在 dumbCoder(HumbleCoder 不懂就问-_-) 的大作中提到: 】

: 多谢解释

: 不过我更关心易用性，比如C/C 没有 Node/Python/Go 那种 CLI package
manager

: 比如在 Go 的 go.mod

: 运行

這種事情很難講。因爲易用性這個事情就是沒有一定的。10分鐘能搞個東西跑，和一週搞個東西出來的易用性不是一種東西。

同樣，你git clone xxx 能夠在一步跑通需要的簡單，和自己真的寫個產品出去賺錢需要的簡單也是不一樣的。

C不流行除了很多別的因素之外，主要是獨立軟件開發者以產品方式買軟件的路現在非
常窄。大部分軟件都是以服務方式收費。販賣拷貝的方式被open source和云給搞得日
子很難過。但是就單純從買軟件角度來說，我真沒看到過比C更好用的。

不過接下來軟件直接對接硬件平臺可能會又popular，所以我覺得C在這些方面還是有機會的。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 多谢解释
: 不过我更关心易用性，比如C/C++ 没有 Node/Python/Go 那种 CLI package manager: 比如在 Go 的 go.mod
: 运行>go mod tidy,
: 运行后, 项目文件夹里装上的 lib 都有 hash value lock 版本
: 这样的话, 设置或重新设置个开发环境就非常简单
: 肯定比 copy lib 文件简单多了
: 现代的语言都有这个工具，如果没有，小年轻很难爱用
: ,

你说这些都没有现在语言的包管理方便, 基本是一两行就把依赖设置好，然后跑起来了.

【 在 magagop (magagop) 的大作中提到: 】
: C語言也可以被管理，只不過是基於源代碼的，用git的可以配合repo，需要配合java的
: 用bazel，喜歡python的還有scons，通用一點的可以是cmake，選擇有很多啊
:
: 多谢解释
:
: 不过我更关心易用性，比如C/C 没有 Node/Python/Go 那种 CLI package
: manager
:
: 比如在 Go 的 go.mod
:
: 运行

首先，這種語言和golang，rust之類的比的優勢是？

第二，我始終覺得爲了讓自己的語言是新的而去改語法是沒有意義的事情。實際上你寫C的時候的煩惱，是類型寫到了前面？還是沒有for x in X這種東西？都不是。

在我看來C的煩惱只有兩個，一是那一堆雜事by default沒有人給你幹了，但是爲了寫
出一個完整軟件又不得不幹的事情。第二就是常常找不到合適的開發人員，你再厲害，最後全手擼也得掛掉。尤其是現在軟件業成了服務行業，很多時候賺錢的點在於讓客戶覺得OK，而不是真的OK。你真金白銀去搞一些客戶本來就是隨便一說的東西肯定虧大了。

【 在 dracodoc (david) 的大作中提到: 】
: 你看过Nim吗？
: 表面上来看优点很多，我没有深入试过

這種東西最後如果一旦有dependency出問題，你花的時間都不是幾個小時可以解決的。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 你说这些都没有现在语言的包管理方便, 基本是一两行就把依赖设置好，然后跑起来了.

你说的这些问题我都非常非常同意

但是现在这些互联网公司就是搞一堆 "快糙猛"+开源项目 把市场都抢占的，
搞得认真polish小而精的程序员没生存空间...

然后就是开高工资，鼓励大家刷题，去当生产线螺丝钉,
这一整套其实跟快餐店里不需要厨师是一样的,
同时配套的还有Agile, 快速迭代，等等一堆的"项目管理模式",
看着挺悲哀的，但是为了讨口(容易的)饭吃, 我也在刷题了... T_T

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 這種事情很難講。因爲易用性這個事情就是沒有一定的。10分鐘能搞個東西跑，和一週
: 搞個東西出來的易用性不是一種東西。
: 同樣，你git clone xxx 能夠在一步跑通需要的簡單，和自己真的寫個產品出去賺錢需
: 要的簡單也是不一樣的。
: C不流行除了很多別的因素之外，主要是獨立軟件開發者以產品方式買軟件的路現在非
: 常窄。大部分軟件都是以服務方式收費。販賣拷貝的方式被open source和云給搞得日
: 子很難過。但是就單純從買軟件角度來說，我真沒看到過比C更好用的。
: 不過接下來軟件直接對接硬件平臺可能會又popular，所以我覺得C在這些方面還是有機
: 會的。

Nim 编译到C，所以基本上C所有的优点都保持了啊
语法简洁像python但实际有pascal血统，macro能力很强

所以这就是能当脚本用的C

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 首先，這種語言和golang，rust之類的比的優勢是？
: 第二，我始終覺得爲了讓自己的語言是新的而去改語法是沒有意義的事情。實際上你寫
: C的時候的煩惱，是類型寫到了前面？還是沒有for x in X這種東西？都不是。
: 在我看來C的煩惱只有兩個，一是那一堆雜事by default沒有人給你幹了，但是爲了寫
: 出一個完整軟件又不得不幹的事情。第二就是常常找不到合適的開發人員，你再厲害，
: 最後全手擼也得掛掉。尤其是現在軟件業成了服務行業，很多時候賺錢的點在於讓客戶
: 覺得OK，而不是真的OK。你真金白銀去搞一些客戶本來就是隨便一說的東西肯定虧大了。

X語言能編譯成Y，不等於it有Y的優點。如果這個Y不是一個能隨便改的Y，其實還是X。

舉個極端例子，這些語言都編譯成匯編，但是他們都有匯編語言的優點嗎？

個人認爲這些語言有兩件事請如果搞不好就很難成爲鏈接C的腳本，第一是OS作業控制
的成本一定要低，這個即使比shell多一層已經劣勢很大了，如果你fork+exec不能直接call binary完成，還要popen然後搞着搞那的，就弱了很多。 第二是，一定要有比較
強的字符串處理能力，函數，數組還有hashtable必須是一等公民，如果這個不行其實
就並沒有彌補C在幹大路貨任務的不足。

很多人覺得FFI重要，我覺得沒錯，但是其實反而不是最重要的，因爲這種地方最重要
的是靠譜，省事，性能其實99%的情況沒人care，因爲就是一些初始化工作，一天跑不
了幾次的。

【 在 dracodoc (david) 的大作中提到: 】
: Nim 编译到C，所以基本上C所有的优点都保持了啊
: 语法简洁像python但实际有pascal血统，macro能力很强
: 所以这就是能当脚本用的C
: 了。

关键看你的系统是干啥用的？

我的应用，OS调用为零。虚拟机沙箱，就是要屏蔽OS的。我的语言和虚拟机选择肯定大不一样。

不过就算是系统管理的，我感觉用typescript写一个也挺好，或者翻译成Lua，直接上
多线程了。不光有字符串函数数组，而且是严格类型检查的。

：-）， 这是商业模式演化的结果，大部码农也只能去适应。

【 在 dumbCoder (HumbleCoder 不懂就问-_-) 的大作中提到: 】
: 你说的这些问题我都非常非常同意
: 但是现在这些互联网公司就是搞一堆 "快糙猛"+开源项目 把市场都抢占的，
: 搞得认真polish小而精的程序员没生存空间...
: 然后就是开高工资，鼓励大家刷题，去当生产线螺丝钉,
: 这一整套其实跟快餐店里不需要厨师是一样的,
: 同时配套的还有Agile, 快速迭代，等等一堆的"项目管理模式",
: 看着挺悲哀的，但是为了讨口(容易的)饭吃, 我也在刷题了... T_T

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 在我看來C的煩惱只有兩個，一是那一堆雜事by default沒有人給你幹了，但是爲了寫
: 出一個完整軟件又不得不幹的事情。
你有没有具体例子

: 第二就是常常找不到合適的開發人員。
其实有不少喜爱C的各国年青人, 需要一个可行的远程开发模式. 开发人员成本反而低

其實國內會C或Cpp語言的開發成本也挺高的，有美國的三分之一吧，也不好招人。算上機會成本，溝通成本，文化差異，國內監管，視同出口許可證等等，也不便宜。跨國大公司在國內真正有研發中心幹實事的不多。

【 在 cstack (cstack) 的大作中提到: 】
: 你有没有具体例子
: 其实有不少喜爱C的各国年青人, 需要一个可行的远程开发模式. 开发人员成本反而低

【 在 cstack (cstack) 的大作中提到: 】
: 标 题: Re: 現在年輕人都不學C語言了嗎
: 发信站: BBS 未名空间站 (Wed Jun 16 00:41:54 2021, 美东)
:
:
: 【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: : 在我看來C的煩惱只有兩個，一是那一堆雜事by default沒有人給你幹了，但是爲
了寫
: : 出一個完整軟件又不得不幹的事情。
: 你有没有具体例子
~~~~~~~~~~~~~~~~~~
很多啊比如說parsing conf file，parsing命令行的輸出，做數據庫查詢之類的，還有隨便要求點什麼出點report啊之類的功能。這些東西，都可以搞，但是如果很多時候就是投標的時候客戶隨口一說，用C寫個robust的，別人never even 會try，或者對性能
要求基本上等於0，肯定是不划算的。
我一般來說有一堆自己的開發kit基本上是可以用，不過很多事情，客觀來說走這條路
還是慢了。當然我覺得開發週期在3個月以上的，用C並沒有問題，而且質量高。

:
: : 第二就是常常找不到合適的開發人員。
: 其实有不少喜爱C的各国年青人, 需要一个可行的远程开发模式. 开发人员成本反而低
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C如果開發後臺程序，尤其是週期大於3個月的，成本不高，如果能招到合適的開發人員。問題在於如果產品要能賣還需要前端之類的，如果你還需要招一些專門做這個的，前期成本容易被拉高。

實際上，所謂前端，很多人現在也是fullstack，就是前端JS framework+後端Python/
node.js/java什麼的，這些人其實如果你要他們和乾乾淨淨的C代碼對接，其實超過他
們的能力，所以其實能和C對接的前端的開發人員其實人更少。

遠程倒是一個方向，現在很多大公司現在也都看到了這一點都在歐洲插管吸血，一年給個10萬刀的global pay給這些人，然後唉幹點啥幹點啥，當地吃香喝辣就行，別沒事做項目和我們的東西競爭。

:
:
:
:
:
:
: --

這些工具，說實話，我覺得是C推廣的障礙。對99%的C程序其實只需要一個好用點的
makefile，別的真的不需要。

當然一定要跨平臺，就是autoconf/automake，說真的，別的不管是Cmake還是scon這些，一旦你要支持一堆平臺，都立馬現原型。

【 在 magagop (magagop) 的大作中提到: 】
: C語言也可以被管理，只不過是基於源代碼的，用git的可以配合repo，需要配合java的
: 用bazel，喜歡python的還有scons，通用一點的可以是cmake，選擇有很多啊
:
: 多谢解释
:
: 不过我更关心易用性，比如C/C 没有 Node/Python/Go 那种 CLI package
: manager
:
: 比如在 Go 的 go.mod
:
: 运行

我经历过的。C最大之限制就是动态特性堆积如山的应用程序。
最后会malloc太多，无法设计程序。

就好比你写了个一只小鸟的游戏程序。放到市场后，需求会变。最后可能
鸟的皮肤种类，几只鸟，，吃啥喝啥，。。。。
这些特性每一个都是一个或者一组新的malloc。更重要的是，这些特性不是可以事先预料和设计的。
市场会经常提出新问题。然后就得加千奇百怪的动态特性或者设置什么的。
简言之，需求会随着市场接触面之扩大而变化，这种
情况用C写程序是最麻烦的。

再有就是c标准库不是web时代设计的。有很多具体问题。
例如c的spec没有线程安全的要求。所以不同os或者版本之c标准库实现里，
哪些函数是线程安全的是不同的。得查手册查代码。这属于另一种undefine行为。

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 這些工具，說實話，我覺得是C推廣的障礙。對99%的C程序其實只需要一個好用點的
: makefile，別的真的不需要。
: 當然一定要跨平臺，就是autoconf/automake，說真的，別的不管是Cmake還是scon這些
: ，一旦你要支持一堆平臺，都立馬現原型。

表面上翻译成功了。但是不能保证其应有的属性能配套。
例如不差手册和源代码，你恐怕很难确保nim写的程序是线程安全的。
所以自己玩玩也就算了。做产品不能考虑用的。除非你就是nim compiler的开发维护人员。
【 在 dracodoc (david) 的大作中提到: 】
: Nim 编译到C，所以基本上C所有的优点都保持了啊
: 语法简洁像python但实际有pascal血统，macro能力很强
: 所以这就是能当脚本用的C
: 了。

【 在 magagop (magagop) 的大作中提到: 】
: 其實國內會C或Cpp語言的開發成本也挺高的，有美國的三分之一吧，也不好招人。算上
: 機會成本，溝通成本，文化差異，國內監管，視同出口許可證等等，也不便宜。跨國大
: 公司在國內真正有研發中心幹實事的不多。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
同义,中国不算低成本. 不要限制国和地区就好多啦, 很多地区的英文都很好.

【 在 chebyshev (......) 的大作中提到: 】
: 我经历过的。C最大之限制就是动态特性堆积如山的应用程序。
: 最后会malloc太多，无法设计程序。
: 就好比你写了个一只小鸟的游戏程序。放到市场后，需求会变。最后可能
: 鸟的皮肤种类，几只鸟，，吃啥喝啥，。。。。
: 这些特性每一个都是一个或者一组新的malloc。更重要的是，这些特性不是可以事先预
: 料和设计的。
: 市场会经常提出新问题。然后就得加千奇百怪的动态特性或者设置什么的。
: 简言之，需求会随着市场接触面之扩大而变化，这种
: 情况用C写程序是最麻烦的。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C是不适合做这些, 需要有GC的嵌入脚本语言来做.
C对嵌入脚本语言的支撑是最直截的

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 實際上，所謂前端，很多人現在也是fullstack，就是前端JS framework+後端Python/
: node.js/java什麼的，這些人其實如果你要他們和乾乾淨淨的C代碼對接，其實超過他
: 們的能力，所以其實能和C對接的前端的開發人員其實人更少。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
和rest API對接也很难么?

你都走rest API這個問題相對好一些。

但是真正的C開發人員很多時候並不想用rest API，你也知道那一旦開始用rest API C
的優勢就不明顯了。另外一個角度來說，如果你到處都是rest API你又何必用C呢？

【 在 cstack (cstack) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 和rest API對接也很难么?

Rest也沒有用。你不能期待一個前端做HTML/CSS的，懷疑後端「可能」出現了問題，然後下載後端全部C代碼，改幾行，編譯，打包，部署，驗證吧？然後因為不熟悉C語言，改一行但是整個core了，還不是core在自己改的那行，並且服務器是Linux headless，普通前端估計都不知如何下手。如果後端是Javascript或Python，改幾行都不需要編譯，也不容易core。如果C語言裡面有RDMA跟硬件加速器相關的，還可能kernel panic，
打印一堆寄存器hex和莫名其妙的kernel backtrace，服務器一下子freeze，估計新手
就流汗了。

如果是Cpp後端，可能改一行然後編譯錯誤上千行，任何前端都會呵呵。

【 在 cstack (cstack) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 和rest API對接也很难么?

這個Cpp可以解決，abseil和folly都有

【 在 chebyshev (......) 的大作中提到: 】
: 我经历过的。C最大之限制就是动态特性堆积如山的应用程序。
: 最后会malloc太多，无法设计程序。
: 就好比你写了个一只小鸟的游戏程序。放到市场后，需求会变。最后可能
: 鸟的皮肤种类，几只鸟，，吃啥喝啥，。。。。
: 这些特性每一个都是一个或者一组新的malloc。更重要的是，这些特性不是可以事先预
: 料和设计的。
: 市场会经常提出新问题。然后就得加千奇百怪的动态特性或者设置什么的。
: 简言之，需求会随着市场接触面之扩大而变化，这种
: 情况用C写程序是最麻烦的。
: 再有就是c标准库不是web时代设计的。有很多具体问题。
: ...................

是的，很多(大厂)前端还是文科/设计妹子转行, 肯定搞不定的

【 在 magagop (magagop) 的大作中提到: 】
: Rest也沒有用。你不能期待一個前端做HTML/CSS的，懷疑後端「可能」出現了問題，然
: 後下載後端全部C代碼，改幾行，編譯，打包，部署，驗證吧？然後因為不熟悉C語言，
: 改一行但是整個core了，還不是core在自己改的那行，並且服務器是Linux headless，
: 普通前端估計都不知如何下手。如果後端是Javascript或Python，改幾行都不需要編譯
: ，也不容易core。如果C語言裡面有RDMA跟硬件加速器相關的，還可能kernel panic，
: 打印一堆寄存器hex和莫名其妙的kernel backtrace，服務器一下子freeze，估計新手
: 就流汗了。
: 如果是Cpp後端，可能改一行然後編譯錯誤上千行，任何前端都會呵呵。

【 在 netghost (Up to Isomorphism) 的大作中提到: 】
: 你都走rest API這個問題相對好一些。
: 但是真正的C開發人員很多時候並不想用rest API，你也知道那一旦開始用rest API
C
: 的優勢就不明顯了。另外一個角度來說，如果你到處都是rest API你又何必用C呢？
~~~~~~~~~~~~~~~~~~~~~~~~
rest API 好调试. 那C開發人員用什么protocol做.

【 在 magagop (magagop) 的大作中提到: 】
: Rest也沒有用。你不能期待一個前端做HTML/CSS的，懷疑後端「可能」出現了問題，然
: 後下載後端全部C代碼，改幾行，編譯，打包，部署，驗證吧？然後因為不熟悉C語言，
: 改一行但是整個core了，還不是core在自己改的那行，並且服務器是Linux headless，
: 普通前端估計都不知如何下手。如果後端是Javascript或Python，改幾行都不需要編譯
: ，也不容易core。如果C語言裡面有RDMA跟硬件加速器相關的，還可能kernel panic，
: 打印一堆寄存器hex和莫名其妙的kernel backtrace，服務器一下子freeze，估計新手
: 就流汗了。

如果设置好了, 没这么难.
1. 用我们的compiler编译, core dump 都有 backtrace. 很容易修改
2. gdb 和 browser debugger 同时用, 两面加 breakpoints, 调试非常快.
3. 用 clion 当前内存的值都显示出来, 都不用加print statement.
直接可以看到 execution state, 非常直观. 因为C的数据一般都没有抽象化.

HTTP協議太靈活了。一般要靠譜最好都是直接用二進制協議。

【 在 cstack (cstack) 的大作中提到: 】
: C
: ~~~~~~~~~~~~~~~~~~~~~~~~
: rest API 好调试. 那C開發人員用什么protocol做.

Linux kernel只能用GCC，clang都不行，用了很多intrinsics。
Kernel很難用breakpoints，我們直接用JTAG和Trace。
不知道Clion用在Linux kernel上好不好，我們都是Vim remote ssh環境，不能本機
debug，因為筆記本沒有dGPU
根據https://blog.jetbrains.com/clion/2020/07/clion-2020-2-makefile-cpp20-
doctest/#makefiles
Clions支持Linux kernel很差，本身Linux kernel是很小眾的方向，只有搞硬件的、性能的、安全的才喜歡，普通工程師和轉專業人士玩不了。

【 在 cstack (cstack) 的大作中提到: 】
: 如果设置好了, 没这么难.
: 1. 用我们的compiler编译, core dump 都有 backtrace. 很容易修改
: 2. gdb 和 browser debugger 同时用, 两面加 breakpoints, 调试非常快.
: 3. 用 clion 当前内存的值都显示出来, 都不用加print statement.
: 直接可以看到 execution state, 非常直观. 因为C的数据一般都没有抽象化.
: