Re: [討論] 為什麼不要用c++寫網站

其實也沒有那麼陌生，經歷過php, Rails時代的人都有被cgi折磨過

只不過現代server side都轉向JavaEE那個樣子，類似Asp.net那樣依附個CGI還是
蠻少見的。
現代的web無論是spring還是go那邊都是走向自己從network connection開始管。
（我知道Spring有內置Tomcat）

其實C/C++這種可以編譯爲native code的還是快，但是一般的編寫方式用用不上。
網路連線其實沒有那麼burst的，一堆時間都在idle，不然poll(), coroutines發明
出來做什麼。也畢竟是HTTP/2以前的連線非常沒有效率，每段msg，先是廢話一堆。
gRPC也只是把header的廢話個壓縮掉。

這也是爲什麼有javascript來拉json這樣的東西出現，web中一堆沒有用的資料都是
css這樣的東西，真實有用的資料用類似out of band的手段丟一丟還比較快。

就算這個protocol進化到gRPC protobuf那麼沒有浪費，抱歉現在的socket編程根本
跳不開CPU copy，從Transport layer過來那邊kernel給你copy到userspace去，
然後reply的時候又userspace 給copy到kernel去包一包。

我前一段時間想弄個VPN程式看到這邊都要吐血了，是有DMA方案啦，DPDK。
沒幾個平臺支援，想要部署到Android或者iOS都不可能。

native code的東西對這種memory boundary就很煩，有debug的人會發現，比如在
一個64bits memory的OS上，兩個32bits變數我只watch一個，結果旁邊variable
動一下，我這邊給拉起來。

string判斷size一不小心沒有null terminator就crash了，string類的function
用之前一定要看看有沒有n version, strnlen()就解決問題了沒有？

在ptt這樣不支援UTF-8的可沒有這種好事。
Jave就沒有這種煩惱了，也沒有Pass by reference這樣這的煩惱。

寫C++的時候要經常看看是不是move還是copy這種屁事.

ART講記憶體處理不好是還可以，GraalVM就沒這個問題了
至於ready time這個您有load過一堆c++ libraries，要處理symbols也很慢

C還好，C++真是痛苦，template每次展開都是毀天滅地般的時間。
還好有更糟的rust

--
你比較喜歡哪一個?

--