s*****w
发帖数: 1527 | |
s*****w
发帖数: 1527 | |
n******t
发帖数: 4406 | 3 Java發明者: 因爲C沒有好用的字符串library,所以你需要 xxxx等20種語言特性.
C++發明者：因爲C的字符串 library很難用，所以你需要xxxx等200種語言特性。
C的傳人：我草，比cheap是吧，玩死你丫的。
結果有了go.
【在 s*****w 的大作中提到】
: golang不是又走回c那一套了吗？
|
s*****w
发帖数: 1527 | 4 如果能操死java，那是好事
【在 n******t 的大作中提到】
: Java發明者: 因爲C沒有好用的字符串library,所以你需要 xxxx等20種語言特性.
: C++發明者：因爲C的字符串 library很難用，所以你需要xxxx等200種語言特性。
: C的傳人：我草，比cheap是吧，玩死你丫的。
: 結果有了go.
|
g****t
发帖数: 31659 | 5 有没有gc区别很大的。后端逻辑很复杂得情况下、还要搞内存、开发容易失败的。
: Java發明者: 因爲C沒有好用的字符串library,所以你需要 xxxx等20種語
言特性.
: C 發明者：因爲C的字符串 library很難用，所以你需要xxxx等200種語
言特性。
: C的傳人：我草，比cheap是吧，玩死你丫的。
: 結果有了go.
【在 n******t 的大作中提到】
: Java發明者: 因爲C沒有好用的字符串library,所以你需要 xxxx等20種語言特性.
: C++發明者：因爲C的字符串 library很難用，所以你需要xxxx等200種語言特性。
: C的傳人：我草，比cheap是吧，玩死你丫的。
: 結果有了go.
|
n***p
发帖数: 110 | |
n******t
发帖数: 4406 | 7 我其實這一點是真的不懂的，稍微複雜點的程序，內存管理只是要care的N件事情中的
一件，而且還是相對簡單的一件，爲啥所有人都盯住這麼一件事？
再說，C有gc，link一個庫就好了。
【在 g****t 的大作中提到】
: 有没有gc区别很大的。后端逻辑很复杂得情况下、还要搞内存、开发容易失败的。
:
:
: Java發明者: 因爲C沒有好用的字符串library,所以你需要 xxxx等20種語
: 言特性.
:
: C 發明者：因爲C的字符串 library很難用，所以你需要xxxx等200種語
: 言特性。
:
: C的傳人：我草，比cheap是吧，玩死你丫的。
:
: 結果有了go.
:
|
g****t
发帖数: 31659 | 8 (1)
哪个gc的库可以link?我看看。这事可不是那么简单。
GC, leak detector, stack 分析软件... 这些东西本身也有技巧
和知识要学，有经验要积累。全学会，用上，成本很高。
(2)
自己管内存，会导致开发很慢。因为各种情况很多。写的快了，出问题难查。还不如开
发放慢。
例如：
第一种是从一个malloc开始，要确保到这块内存结束，一路上的逻辑不出错。
第二种是确保没有未初始化的指针。
第三种是各种memory buff要够用，不越界。
第四种是structure，数组等传递给函数做参数要注意的问题。
,etc
应用逻辑一复杂，函数调用的路线很难事先设计好。会导致这上面的任意一条都很难查。
C好用与否取决于你对软件的严格性的要求。有的错误会导致汽车自动加速，有的错误只
是桌面软件闪退。写法也是不同的。
有的内存泄漏不是问题，例如浏览器都是越用越慢。重启动就完事。但有的就是很大的
问题。例如传感器持续收集和处理数据，需要程序连续跑几个月，几年都常见。
我有一个Axioms of C的cheat sheet。要写c code的时候就拿出来用。总结了各种情况
，以及有效的写法，以及其背后的合理性，sample code，有道理的blog link等等。
: 我其實這一點是真的不懂的，稍微複雜點的程序，內存管理只是要care的
N件事
情中的
: 一件，而且還是相對簡單的一件，爲啥所有人都盯住這麼一件事？
: 再說，C有gc，link一個庫就好了。
【在 n******t 的大作中提到】
: 我其實這一點是真的不懂的，稍微複雜點的程序，內存管理只是要care的N件事情中的
: 一件，而且還是相對簡單的一件，爲啥所有人都盯住這麼一件事？
: 再說，C有gc，link一個庫就好了。
|
T********i
发帖数: 2416 | 9 GC语言，除了latency无法保证以外，throughput不差。应该比average programmer用
无GC语言写的要好。
golang GC基本是毫秒级的latency。
真正微秒级别的系统，设计思路根本不一样，属于用空间换取确定性。额外成本能不能
justify那个需求？ |
g****t
发帖数: 31659 | 10 GC起还是不起，是在用户掌控之外的。这点不确定性是我最不喜欢的。因为它会引起一
些复杂的算法问题。
例如我最近看到的对redis的一个分布式锁的质疑：（我认为有道理）
http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
Background和redis人的回复：
https://redis.io/topics/distlock
但起还是不起gc,这个不确定性是无法完全排除的。
: GC语言，除了latency无法保证以外，throughput不差。应该比average
programmer用
: 无GC语言写的要好。
: golang GC基本是毫秒级的latency。
: 真正微秒级别的系统，设计思路根本不一样，属于用空间换取确定性。额
外成本
能不能
: justify那个需求？
【在 T********i 的大作中提到】
: GC语言，除了latency无法保证以外，throughput不差。应该比average programmer用
: 无GC语言写的要好。
: golang GC基本是毫秒级的latency。
: 真正微秒级别的系统，设计思路根本不一样，属于用空间换取确定性。额外成本能不能
: justify那个需求？
|
|
|
x****u
发帖数: 44466 | 11 非动态
【在 s*****w 的大作中提到】
: golang不是又走回c那一套了吗？
|
x****u
发帖数: 44466 | 12 没有GC就没有真正的OOP
【在 g****t 的大作中提到】
: GC起还是不起，是在用户掌控之外的。这点不确定性是我最不喜欢的。因为它会引起一
: 些复杂的算法问题。
: 例如我最近看到的对redis的一个分布式锁的质疑：（我认为有道理）
: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
: Background和redis人的回复：
: https://redis.io/topics/distlock
: 但起还是不起gc,这个不确定性是无法完全排除的。
:
:
: GC语言，除了latency无法保证以外，throughput不差。应该比average
: programmer用
|
n******t
发帖数: 4406 | 13 我們能不能不要自說自話？我的point從來就不是內存管理難不難的問題。
1) 最早的GC實現之一就是 Boehm-Demers-Weiser detector,已經有N年了。
而且大公司還有很多閉源的實現。
2) 我的point是，內存管理有難度，但是這個對於一個複雜系統來說，是很少的
一部分麻煩。如果你說的兩個情況都覺得無比痛苦，你怎麼去維持一堆鏈接，
管理一堆線程，合併I/O，我覺得都不行。也就是說，你都得用現成寫好的框架。
3）開發慢大部分情況不是由語言導致的，而是有架構的問題導致的。（當然喜歡用
某種語言的人容易產生架構上面的問題）
【在 g****t 的大作中提到】
: (1)
: 哪个gc的库可以link?我看看。这事可不是那么简单。
: GC, leak detector, stack 分析软件... 这些东西本身也有技巧
: 和知识要学，有经验要积累。全学会，用上，成本很高。
: (2)
: 自己管内存，会导致开发很慢。因为各种情况很多。写的快了，出问题难查。还不如开
: 发放慢。
: 例如：
: 第一种是从一个malloc开始，要确保到这块内存结束，一路上的逻辑不出错。
: 第二种是确保没有未初始化的指针。
|
g****t
发帖数: 31659 | 14 你说的第二点里的那些别的麻烦不因为使用无gc而消失。
你说的第二点里的那些麻烦，程序员反而容易找。
你要找个习惯好的，不容易出指针越界空指针之类问题的程序员那是很难的。
: 我們能不能不要自說自話？我的point從來就不是內存管理難不難的問題
。
: 1) 最早的GC實現之一就是 Boehm-Demers-Weiser detector,已經有N年
了。
: 而且大公司還有很多閉源的實現。
: 2) 我的point是，內存管理有難度，但是這個對於一個複雜系統來說，是
很少的
: 一部分麻煩。如果你說的兩個情況都覺得無比痛苦，你怎麼去維持一堆鏈
接，
: 管理一堆線程，合併I/O，我覺得都不行。也就是說，你都得用現成寫好
的框架。
: 3）開發慢大部分情況不是由語言導致的，而是有架構的問題導致的。（
當然喜
歡用
: 某種語言的人容易產生架構上面的問題）
【在 n******t 的大作中提到】
: 我們能不能不要自說自話？我的point從來就不是內存管理難不難的問題。
: 1) 最早的GC實現之一就是 Boehm-Demers-Weiser detector,已經有N年了。
: 而且大公司還有很多閉源的實現。
: 2) 我的point是，內存管理有難度，但是這個對於一個複雜系統來說，是很少的
: 一部分麻煩。如果你說的兩個情況都覺得無比痛苦，你怎麼去維持一堆鏈接，
: 管理一堆線程，合併I/O，我覺得都不行。也就是說，你都得用現成寫好的框架。
: 3）開發慢大部分情況不是由語言導致的，而是有架構的問題導致的。（當然喜歡用
: 某種語言的人容易產生架構上面的問題）
|
i******l
发帖数: 270 | |
i******l
发帖数: 270 | 16 内存永远是 C 的痛
很多重要的基础软件的内存问题完全没希望解决
这哥们儿说的挺好:
https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
We live in a world where all software is broken. And while I wish
maintainers of some projects would be more diligent, it would not fix the
underlying problems: that complexity of practical codebases exceeds the
human ability to reason about it, and that humans inevitably make mistakes.
【在 n******t 的大作中提到】
: 我其實這一點是真的不懂的，稍微複雜點的程序，內存管理只是要care的N件事情中的
: 一件，而且還是相對簡單的一件，爲啥所有人都盯住這麼一件事？
: 再說，C有gc，link一個庫就好了。
|
n******t
发帖数: 4406 | 17 你還是沒懂，或者是你不願意懂。別的麻煩不會因爲屋gc而消失，但是能夠處理那些
麻煩的人，不會care有沒有gc。而那些問題都是需要解決的。
不要去扯容不容易找了，那個根本不是自己都沒解決內存管理的人能幹的事。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
顯然你不做系統開發，所以你的容易找，就是找用現有framework的人，換句話說
就是並不知道怎麼處理這些麻煩的人。
【在 g****t 的大作中提到】
: 你说的第二点里的那些别的麻烦不因为使用无gc而消失。
: 你说的第二点里的那些麻烦，程序员反而容易找。
: 你要找个习惯好的，不容易出指针越界空指针之类问题的程序员那是很难的。
:
:
: 我們能不能不要自說自話？我的point從來就不是內存管理難不難的問題
: 。
:
: 1) 最早的GC實現之一就是 Boehm-Demers-Weiser detector,已經有N年
: 了。
:
: 而且大公司還有很多閉源的實現。
:
: 2) 我的point是，內存管理有難度，但是這個對於一個複雜系統來說，是
|
g****t
发帖数: 31659 | 18 会处理别的麻烦的人不care有没有gc ?
你找个有经验的java并发多线程io啥的老师傅。一多半他
用c写个能读大csv文件的editor都难。in long term,语言决定思维，而不是反过来。
这跟做系统开发与否有什么关系。上次我给你列过了。
Hack news上多少二十年经验的人，C的字符串啥的这点事隔几年冒出来一次。没有一致
意见。你觉得c的内存管理简单，这个看法我无法接受。
这个问题跟别的事也没啥关系。
: 你還是沒懂，或者是你不願意懂。別的麻煩不會因爲屋gc而消失，但是能
夠處理
那些
: 麻煩的人，不會care有沒有gc。而那些問題都是需要解決的。
: 不要去扯容不容易找了，那個根本不是自己都沒解決內存管理的人能幹的
事。
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 顯然你不做系統開發，所以你的容易找，就是找用現有framework的人，
換句話說
: 就是並不知道怎麼處理這些麻煩的人。
【在 n******t 的大作中提到】
: 你還是沒懂，或者是你不願意懂。別的麻煩不會因爲屋gc而消失，但是能夠處理那些
: 麻煩的人，不會care有沒有gc。而那些問題都是需要解決的。
: 不要去扯容不容易找了，那個根本不是自己都沒解決內存管理的人能幹的事。
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 顯然你不做系統開發，所以你的容易找，就是找用現有framework的人，換句話說
: 就是並不知道怎麼處理這些麻煩的人。
|
g****t
发帖数: 31659 | 19 应用软件也一样。哪个浏览器开一个星期不关，不变慢？
这不仅是开发者的问题。
: 内存永远是 C 的痛
: 很多重要的基础软件的内存问题完全没希望解决
: 这哥们儿说的挺好:
: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-
b8f2ee5db4e6
: We live in a world where all software is broken. And while I
wish
: maintainers of some projects would be more diligent, it would
not fix
the
: underlying problems: that complexity of practical codebases
exceeds
the
: human ability to reason about it, and that humans inevitably
make
mistakes.
【在 i******l 的大作中提到】
: 内存永远是 C 的痛
: 很多重要的基础软件的内存问题完全没希望解决
: 这哥们儿说的挺好:
: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
: We live in a world where all software is broken. And while I wish
: maintainers of some projects would be more diligent, it would not fix the
: underlying problems: that complexity of practical codebases exceeds the
: human ability to reason about it, and that humans inevitably make mistakes.
|
n******t
发帖数: 4406 | 20 這明顯是Rust Evangelism Strikeforce的人寫的文章。
首先我覺得任何一個想別人take it seriously的技術文章，攻擊libcurl這樣非常成熟的
library的同時，應該附上測試代碼。
還有這人對segfault的態度非常搞笑，segfault是系統告訴你something wrong，
結果他覺得這東西不看到最好。屬於感冒了，不想發燒的。
說實話，我不知道這些rust粉絲的人是怎麼想的，不去好好寫程序，成天花時間去
攻擊一個和自己沒什麼關係的語言。這種人群，很少有出產高質量項目的情況。
【在 i******l 的大作中提到】
: 内存永远是 C 的痛
: 很多重要的基础软件的内存问题完全没希望解决
: 这哥们儿说的挺好:
: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
: We live in a world where all software is broken. And while I wish
: maintainers of some projects would be more diligent, it would not fix the
: underlying problems: that complexity of practical codebases exceeds the
: human ability to reason about it, and that humans inevitably make mistakes.
|
|
|
g****t
发帖数: 31659 | 21 Rust这条路谁也不知道通不通。
: 這明顯是Rust Evangelism Strikeforce的人寫的文章。
: 首先我覺得任何一個想別人take it seriously的技術文章，攻擊libcurl這樣非
常成熟的
: library的同時，應該附上測試代碼。
: 還有這人對segfault的態度非常搞笑，segfault是系統告訴你something wrong，
: 結果他覺得這東西不看到最好。屬於感冒了，不想發燒的。
: 說實話，我不知道這些rust粉絲的人是怎麼想的，不去好好寫程序，成天花時間去
: 攻擊一個和自己沒什麼關係的語言。這種人群，很少有出產高質量項目的情況。
【在 n******t 的大作中提到】
: 這明顯是Rust Evangelism Strikeforce的人寫的文章。
: 首先我覺得任何一個想別人take it seriously的技術文章，攻擊libcurl這樣非常成熟的
: library的同時，應該附上測試代碼。
: 還有這人對segfault的態度非常搞笑，segfault是系統告訴你something wrong，
: 結果他覺得這東西不看到最好。屬於感冒了，不想發燒的。
: 說實話，我不知道這些rust粉絲的人是怎麼想的，不去好好寫程序，成天花時間去
: 攻擊一個和自己沒什麼關係的語言。這種人群，很少有出產高質量項目的情況。
|
i******l
发帖数: 270 | 22 有 security bugs 的报告和统计的，很多都同内存有关系
segfault 如果相当于感冒，那最好也别在控制核电站的软件上感冒。换句话说，如果
要死，最好也是受控的死，在设计的地方死。
不管你怎么看待这人的观点，C 的内存问题绝对是根深蒂固的，靠老师傅和仔细是解决
不了的
熟的
【在 n******t 的大作中提到】
: 這明顯是Rust Evangelism Strikeforce的人寫的文章。
: 首先我覺得任何一個想別人take it seriously的技術文章，攻擊libcurl這樣非常成熟的
: library的同時，應該附上測試代碼。
: 還有這人對segfault的態度非常搞笑，segfault是系統告訴你something wrong，
: 結果他覺得這東西不看到最好。屬於感冒了，不想發燒的。
: 說實話，我不知道這些rust粉絲的人是怎麼想的，不去好好寫程序，成天花時間去
: 攻擊一個和自己沒什麼關係的語言。這種人群，很少有出產高質量項目的情況。
|
n******t
发帖数: 4406 | 23 csv是個文本文件，"用C寫個能讀大csv文件的editor",
和"用C寫個能讀大文本文件的editor”的區別是？
C 字符串是用來淘汰不適合寫程序的人非常好的分水嶺。有什麼問題嗎？
hackernews上大部分comment的人是我招人絕對不會用的人。
【在 g****t 的大作中提到】
: 会处理别的麻烦的人不care有没有gc ?
: 你找个有经验的java并发多线程io啥的老师傅。一多半他
: 用c写个能读大csv文件的editor都难。in long term,语言决定思维，而不是反过来。
: 这跟做系统开发与否有什么关系。上次我给你列过了。
: Hack news上多少二十年经验的人，C的字符串啥的这点事隔几年冒出来一次。没有一致
: 意见。你觉得c的内存管理简单，这个看法我无法接受。
: 这个问题跟别的事也没啥关系。
:
:
: 你還是沒懂，或者是你不願意懂。別的麻煩不會因爲屋gc而消失，但是能
: 夠處理
|
n******t
发帖数: 4406 | 24 拿代碼來，不用代碼說別人不行的話，沒有credit。
就好象你說別人丑，不上照片，這算啥？
【在 i******l 的大作中提到】
: 有 security bugs 的报告和统计的，很多都同内存有关系
: segfault 如果相当于感冒，那最好也别在控制核电站的软件上感冒。换句话说，如果
: 要死，最好也是受控的死，在设计的地方死。
: 不管你怎么看待这人的观点，C 的内存问题绝对是根深蒂固的，靠老师傅和仔细是解决
: 不了的
:
: 熟的
|
i******l
发帖数: 270 | 25 我说的 C 内存问题很难解决，这很容易证实。随便找个重要的 C project，
libcurl, kernel，你看看他的 issue list，bugs report，看看和内存相关的。
你觉得 C 内存管理简单，倒是你应该举个例子，找个有点重要性的 C 项目，
让我们看看，它基本没出过内存问题。
好比你说你漂亮的很，但是没图，我们只好一律按照韩红处理。
【在 n******t 的大作中提到】
: 拿代碼來，不用代碼說別人不行的話，沒有credit。
: 就好象你說別人丑，不上照片，這算啥？
|
g****t
发帖数: 31659 | 26 是我写错了。“读”字应为操作。我认为：
能操作大文件的csv editor用c写是很麻烦的。
: csv是個文本文件，"用C寫個能讀大csv文件的editor",
: 和"用C寫個能讀大文本文件的editor”的區別是？
: C 字符串是用來淘汰不適合寫程序的人非常好的分水嶺。有什麼問題嗎？
: hackernews上大部分comment的人是我招人絕對不會用的人。
【在 n******t 的大作中提到】
: 拿代碼來，不用代碼說別人不行的話，沒有credit。
: 就好象你說別人丑，不上照片，這算啥？
|
n******t
发帖数: 4406 | 27 問題是這裏是有人說libcurl有毛病，結果不說毛病是啥。
我可沒說C語言不會出bug，你要給你證明看啥？
你如果還作過開發，就知道這種kernel, libcurl絕對是代碼質量非常高的項目。
issue能讓你看到，是因爲都列出來了，不是別人的東西爛好不好。
不信你去搞一個項目，可能3年一個issue都沒有，你叫別人用用看看有沒有人敢用？
你當全世界那麼多項目，depending on這些你覺得一堆issue的項目，別人
是白癡嗎？很多什麼rust這種東西，不是沒屎，是根本沒有人用。
【在 i******l 的大作中提到】
: 我说的 C 内存问题很难解决，这很容易证实。随便找个重要的 C project，
: libcurl, kernel，你看看他的 issue list，bugs report，看看和内存相关的。
: 你觉得 C 内存管理简单，倒是你应该举个例子，找个有点重要性的 C 项目，
: 让我们看看，它基本没出过内存问题。
: 好比你说你漂亮的很，但是没图，我们只好一律按照韩红处理。
|
g****t
发帖数: 31659 | 28 他说的是内存问题在c 项目里的bug占比。这点应无争议。
: 問題是這裏是有人說libcurl有毛病，結果不說毛病是啥。
: 我可沒說C語言不會出bug，你要給你證明看啥？
: 你如果還作過開發，就知道這種kernel, libcurl絕對是代碼質量非常高的項目。
: issue能讓你看到，是因爲都列出來了，不是別人的東西爛好不好。
: 不信你去搞一個項目，可能3年一個issue都沒有，你叫別人用用看看有沒有人敢
用？
: 你當全世界那麼多項目，depending on這些你覺得一堆issue的項目，別人
: 是白癡嗎？很多什麼rust這種東西，不是沒屎，是根本沒有人用。
【在 n******t 的大作中提到】
: 問題是這裏是有人說libcurl有毛病，結果不說毛病是啥。
: 我可沒說C語言不會出bug，你要給你證明看啥？
: 你如果還作過開發，就知道這種kernel, libcurl絕對是代碼質量非常高的項目。
: issue能讓你看到，是因爲都列出來了，不是別人的東西爛好不好。
: 不信你去搞一個項目，可能3年一個issue都沒有，你叫別人用用看看有沒有人敢用？
: 你當全世界那麼多項目，depending on這些你覺得一堆issue的項目，別人
: 是白癡嗎？很多什麼rust這種東西，不是沒屎，是根本沒有人用。
|
n******t
发帖数: 4406 | 29 沒區別啊，還是一個文本文件，你要怎麼操作呢？無非就是編輯唄。
unix從最先的ed,vi到emacs都是C寫的。
【在 g****t 的大作中提到】
: 是我写错了。“读”字应为操作。我认为：
: 能操作大文件的csv editor用c写是很麻烦的。
:
:
: csv是個文本文件，"用C寫個能讀大csv文件的editor",
:
: 和"用C寫個能讀大文本文件的editor”的區別是？
:
: C 字符串是用來淘汰不適合寫程序的人非常好的分水嶺。有什麼問題嗎？
:
: hackernews上大部分comment的人是我招人絕對不會用的人。
:
|
i******l
发帖数: 270 | 30 闹半天你不知道讨论重点是什么？ 有内存问题就是烂项目的稻草人是你立的。
有人说 libcurl 和 kernel 是烂 code 吗？
libcurl 的 bug 在那列着，你要代码不如看这个
https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=proj&colspec=ID%20Type
%20Component%20Status%20Proj%20Reported%20Owner%20Summary&num=100&q=-status%
3AWontFix%2CDuplicate%20-Infra%20proj%3Acurl&can=1
事实上，一句话，就是说你的什么 C 内存管理简单都是谬论
【在 n******t 的大作中提到】
: 問題是這裏是有人說libcurl有毛病，結果不說毛病是啥。
: 我可沒說C語言不會出bug，你要給你證明看啥？
: 你如果還作過開發，就知道這種kernel, libcurl絕對是代碼質量非常高的項目。
: issue能讓你看到，是因爲都列出來了，不是別人的東西爛好不好。
: 不信你去搞一個項目，可能3年一個issue都沒有，你叫別人用用看看有沒有人敢用？
: 你當全世界那麼多項目，depending on這些你覺得一堆issue的項目，別人
: 是白癡嗎？很多什麼rust這種東西，不是沒屎，是根本沒有人用。
|
|
|
n******t
发帖数: 4406 | 31 你隨便找個大點的C項目看看唄，有多少是因爲segfault和內存越界之類的事情吧。
不要想當然。
程序就是會出問題的，任何告訴你用了XXX語言就沒問題的人，都是在賣神油。
目。
【在 g****t 的大作中提到】
: 他说的是内存问题在c 项目里的bug占比。这点应无争议。
:
:
: 問題是這裏是有人說libcurl有毛病，結果不說毛病是啥。
:
: 我可沒說C語言不會出bug，你要給你證明看啥？
:
: 你如果還作過開發，就知道這種kernel, libcurl絕對是代碼質量非常高的項目。
:
: issue能讓你看到，是因爲都列出來了，不是別人的東西爛好不好。
:
: 不信你去搞一個項目，可能3年一個issue都沒有，你叫別人用用看看有沒有人敢
: 用？
:
: 你當全世界那麼多項目，depending on這些你覺得一堆issue的項目，別人
:
: 是白癡嗎？很多什麼rust這種東西，不是沒屎，是根本沒有人用。
|
n******t
发帖数: 4406 | 32 我問的是，這個人說他用curl發生了segfault，那麼是什麼情況下發生的。
大家都知道，你隨便curl一下是不會出segfault的，所以他到底經歷了什麼，還有
爲什麼他相信是libcurl的問題，nobody knows。扣屎盆子不是這麼扣的。
你給我看libcurl的issue list有什麼用？
20Type
status%
【在 i******l 的大作中提到】
: 闹半天你不知道讨论重点是什么？ 有内存问题就是烂项目的稻草人是你立的。
: 有人说 libcurl 和 kernel 是烂 code 吗？
: libcurl 的 bug 在那列着，你要代码不如看这个
: https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=proj&colspec=ID%20Type
: %20Component%20Status%20Proj%20Reported%20Owner%20Summary&num=100&q=-status%
: 3AWontFix%2CDuplicate%20-Infra%20proj%3Acurl&can=1
: 事实上，一句话，就是说你的什么 C 内存管理简单都是谬论
|
g****t
发帖数: 31659 | 33 我不熟悉開源社區。但我有自己的項目經歷。他说的和我的经历符合。
其他方面的bug容易找容易改。release之後的內存相关bug是主流。导致全球recall的
我也見過。
Buff尺寸没给对，换个应用环境导致越界，这种更常见。但是是相对来说容易修改的。
: 你隨便找個大點的C項目看看唄，有多少是因爲segfault和內存越界之類
的事情
吧。
: 不要想當然。
: 程序就是會出問題的，任何告訴你用了XXX語言就沒問題的人，都是在賣
神油。
: 目。
【在 n******t 的大作中提到】
: 我問的是，這個人說他用curl發生了segfault，那麼是什麼情況下發生的。
: 大家都知道，你隨便curl一下是不會出segfault的，所以他到底經歷了什麼，還有
: 爲什麼他相信是libcurl的問題，nobody knows。扣屎盆子不是這麼扣的。
: 你給我看libcurl的issue list有什麼用？
:
: 20Type
: status%
|
n******t
发帖数: 4406 | 34 大部分內存的bug,和別的bug一樣是設計的問題。
如果你的程序內存頻繁地出問題，或者這麼說吧，如果你一寫程序就segfault，
說明你腦子一團糊塗，應該做的不是繼續寫程序，而是去寫文檔。
【在 g****t 的大作中提到】
: 我不熟悉開源社區。但我有自己的項目經歷。他说的和我的经历符合。
: 其他方面的bug容易找容易改。release之後的內存相关bug是主流。导致全球recall的
: 我也見過。
: Buff尺寸没给对，换个应用环境导致越界，这种更常见。但是是相对来说容易修改的。
:
:
: 你隨便找個大點的C項目看看唄，有多少是因爲segfault和內存越界之類
: 的事情
: 吧。
:
: 不要想當然。
:
: 程序就是會出問題的，任何告訴你用了XXX語言就沒問題的人，都是在賣
|
g****t
发帖数: 31659 | 35 假如一个内存问题是频繁出现的，用工具也就查出来了。测试也容易发现。release之
前也就解决了。我说的是release之后的issues。
: 大部分內存的bug,和別的bug一樣是設計的問題。
: 如果你的程序內存頻繁地出問題，或者這麼說吧，如果你一寫程序就
segfault，
: 說明你腦子一團糊塗，應該做的不是繼續寫程序，而是去寫文檔。
【在 n******t 的大作中提到】
: 大部分內存的bug,和別的bug一樣是設計的問題。
: 如果你的程序內存頻繁地出問題，或者這麼說吧，如果你一寫程序就segfault，
: 說明你腦子一團糊塗，應該做的不是繼續寫程序，而是去寫文檔。
|
i******l
发帖数: 270 | 36 这人解释了，而且那是 2014 年的事情
By that time I was already disillusioned in the security of software written
in C and the willingness of maintainers to fix it, so I never followed up
on the bug.
这个问题并不重要，他可以完全不提这事儿，根本不影响文章主题。
rust 虽然没有什么有影响力的项目，但是有尝试解决内存问题的努力，这很好。你要
说 rust 没有那种所有人都用的软件，那是对的。不过 rust 也才稳定下来没几年，来
日方长。
【在 n******t 的大作中提到】
: 我問的是，這個人說他用curl發生了segfault，那麼是什麼情況下發生的。
: 大家都知道，你隨便curl一下是不會出segfault的，所以他到底經歷了什麼，還有
: 爲什麼他相信是libcurl的問題，nobody knows。扣屎盆子不是這麼扣的。
: 你給我看libcurl的issue list有什麼用？
:
: 20Type
: status%
|
x****u
发帖数: 44466 | 37 月薪5000块招人还有那么严格要求啊。。。
来。
一致
是能
【在 n******t 的大作中提到】
: csv是個文本文件，"用C寫個能讀大csv文件的editor",
: 和"用C寫個能讀大文本文件的editor”的區別是？
: C 字符串是用來淘汰不適合寫程序的人非常好的分水嶺。有什麼問題嗎？
: hackernews上大部分comment的人是我招人絕對不會用的人。
|
x****u
发帖数: 44466 | 38 现在有一种技术是直接把文档转化为程序
【在 n******t 的大作中提到】
: 大部分內存的bug,和別的bug一樣是設計的問題。
: 如果你的程序內存頻繁地出問題，或者這麼說吧，如果你一寫程序就segfault，
: 說明你腦子一團糊塗，應該做的不是繼續寫程序，而是去寫文檔。
|
