Re: [討論] 2018 各語言就業工作前景

[tofuflower (無)]

沒想到下面推文意外戰起 Java 了。

結論寫在前面，我認為 Java 是一個泛用性很高的語言，各領域都有成熟的生態系支援。
一個新語言的興起往往是因為他解決了舊語言在某些方面的不足，但不代表舊語言原來
擅長的情境可以很好的被新語言解決。

我想工程師若能比較理性的看待每個語言擅長的情境，能少走一些彎路。

下面是我自己對 Java 粗淺認識的討論，若有錯誤的地方也歡迎大家討論。



1. JAVA 一開 Eclipse 開發就佔用大量 Client 資源

自從我換用 intellij 以後就感覺比較沒那麼吃資源了，推薦你試試，另外 Java9
力推的模組化或許可以讓 Java 使用上比以往輕量一點，還需要觀察。


2. node.js, python 都能在樹莓派、MAC、WIN 跑了 優勢在那 ？

如果是但純和這兩個語言比的話，優勢在多執行緒的效能。

Python 在單一執行緒的效能的確是很優越，但只要主流 CPython 沒有解決 GIL 的問題
，Python 永遠不能很好發揮多 CPU 得效能。當然你可以用 multiprocessing，但用
process 資源就是比 thread 重。因此在 concurrency 的情境下，Python 相較 Java
是比較有劣勢的。當然不是無解，只是花心力去研究 Python 底層做性能調校，和直接
用已經可很好支援多 CPU 的語言，就需要工程師自己評估了。題外話，JPython 似乎
沒有 GIL 問題，但相對比較冷門就是了。

至於 Node，眾所皆知 Node 在 Application level 是 single thread。儘管可以用
pm2 這樣的工具起 cluster，但 process 的問題依舊存在。最簡單的例子，當今天某個
Node 的 process loading 過重時，其他 Node 的 process 只能在旁邊發呆。

Java 的 multi thread 相較這兩者比較能發揮多 CPU 的系統效能。


3. 現在 node.js, python 社群還在主動發展中

社群主導這件事好壞很難講，像 Node 每過幾年都要分裂一次，還有去年三月的 npm 的
 left pad 事件，總是讓我在使用 Node 時感覺抖抖的 (囧....


4. 改個小 BUG ，等個兩分鐘編譯完，發現不對，再改一下

經 sky790312 版友補充，可以用支援即時 check style 的 js IDE。
編譯要兩分鐘我更傾向是專案的問題而不是 Java。
我假設你這邊說的是相較 Python 和 Node 這種修改不需要編譯，修改程式比較快。
的確，編譯的確會花一些時間，但不編譯真的會比較好嗎？
我實際上看過一些 Python 和 Node 案例：很快改完小 bug，改完上傳跑 CI 才發現語
法錯誤，不小心多個 ";" 或縮排錯誤之類的。這還是團隊有做 CI，一些連基本 CI 都
沒做的公司我還真不知道要怎麼避免這問題，要知道只要是人就一定會犯錯，很多時候
都是自以為改的只是小地方就忘了先在本地跑測試或 check style 之類的。
另外如果等待編譯是你的痛點的話，建議可以試看看 Golang，編譯超快。


5. 可台灣環境比較保守一些，大部分還停留在上個世紀。

板上還有阿里研究院徵 Java  工程師的文章，我想阿里應該不是保守的公司。


6. 若追求效能，就該用 c++。

修正：經 Sirctal, chiaming0914, elements 指正，GC 這點是我錯誤論述。
下面用雙引號匡起來的內容就是被指正有問題的部分，請不要盡信。
保留爭議原文讓後續讀者知道這裡原先的爭論點是什麼。

"但用 C++ 就要自己處理 GC 問題。而我認為自己刻的 GC 能比 JVM GC 優秀的工程師應
該是少數中的少數，因此把 GC 問題也列入考量再加上 JIT 技術的話， C++ 效能並不
一定總是能樂勝 Java，當然主要還是要看使用情境。"


額外補充一點忘了回
7. 至於原始碼封裝的優點，現在也可以用 docker 來處理了

用 docker 封裝 runtime 環境時，通常選用較小的 image (例如 alpine)， 但你不總
是會用這些環境開發。我之前在 alpine 安裝某些 Python 連 my-sql 相關套件的時候
遇到不少問題(年代久遠，已經忘記是那個替三方套件了)，最後是解法是開發環境和
production 安裝不一致的第三方套件，這件事讓我在做 CI/CD 的時候蠻困擾的。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.77.40.73
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1514122489.A.85C.html
推 imreader: 補充你指出的 thread 問題，我若要做 multi-thread，
→ imreader: 我會傾向使用 Node JS 的 Async 寫法，完全不用擔心
→ imreader: Thread-safe 的問題
→ imreader: 加上 ES2016 以後有 Async, Await 的終極方案
可能我表達不夠清楚讓你誤會我意思了
我的意思是 Node 目前本質上是在 application level 的 single thread，
這讓他在同時運用多個 CPU 做事情會比 Java 還要有挑戰。
這意味著如果你想要榨乾多 CPU 系統效能的話， Node 會比 Java 需要花更多心力。
題外話，這件事 Golang 做的比兩者都好 (但還是有些小陷阱)，算是整合兩邊所長。
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 21:52:42
推 imreader: 另外 Node JS 也可以用 coffeescript 做 transpiler
→ imreader: 直接寫 python like 的排版語法來寫作
→ imreader: 你自已都知道 PM2 了，再配合 async 寫法，
→ imreader: 多 CPU 也能輕鬆運用
→ imreader: 對我來講，這就起多個 node 行程，做 multi-workers
推 imreader: 用 python 的 celery 來寫 async，遠遠不及 node js
→ imreader: 的 async, await 直覺、易用
我想我表達得不夠清楚，application level 的 thread 有幾種狀況不好處理：

1. 假設今天有一個計算類型的任務 (例如一個大陣列的 quick sort實作)，Java 可以
   比較輕鬆的運用多 CPU，拆多個子任務用 thread 就可以了。
   Node 要運多 CPU 做這件事相對會麻煩很多。

2. 誠然，Node 用 cluster 跑多個 process 可以吃多個 CPU。
   假設今天 Node 起了 cluster ，下面有四個 process 分別處理 request，
   如果今天運氣不好，分配給第一個 process 的 requst 比較吃資源，其他則否，
   那過一段時間後你會發現只剩第一個 process 在一個 CPU 上跑，
   其他 process 對此無能為力。

3. process 和 process 間沒有共享記憶體，因此有當你決定要用 pm2 起 cluster
   跑 web 時，就一定要用外部的 storage (ex. redis) 存 session。

當然這些情況是極端了點，我只是想說明用 Java (或 Golang，C#) 可以不用考慮這
些情況，而用 Node 你得依據你的使用情境考慮是否要y處理這些情況。

※ 編輯: tofuflower (42.77.40.73), 12/24/2017 22:24:12
→ imreader: python 跟 node js 剛好一個同步、一個非同步互相搭配
推 Sirctal: C++不需要GC好嗎？？ C++11有smart pointer...
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 22:25:35
→ x000032001: 雖然不寫Java 它在大數據和企業級應用的確佔有一塊
→ x000032001: 一直鄙視而不正視它為何被使用 那是狂熱信徒才做的事
噓 chiaming0914: 對c++不熟就不要隨便亂講
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 22:45:57
對不起，這點的確是我說錯，已修正原文。
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 22:50:16
→ elements: smart ptr 比起 GC 有更多眉角，c++ 也有 mark and swe
→ elements: ep 就是了，只是要另外弄。
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 22:52:21
推 backprog: 這邊夠詳細推
→ remmurds: 某樓怎摸會把async跟multi thread混為一談...
推 imreader: 某樓不用指正教學，thread 跟 async 本質有差我知道
→ imreader: 但能不用 multi-thread 寫的話，我會盡量不用
推 nbajam: 認同給推
推 imreader: 對 async, multi-thread 區別有興趣的話，可以看這篇
→ imreader: https://goo.gl/FZ4ZFX
→ imreader: 但對我來講 thread-safe ，寫起來直覺，就很好用了
推 CGS0: c++ 寫的好 就保持習慣 做的比 Java 的 GC 還爛 應該是很快
→ CGS0: 就不行了
→ CGS0: 請講自己寫很久的部份就好 不用亂猜其他語言
C++ 這點是我疏忽，請其他版友不要被我誤導
推 TeddyCaptain: imreader是在供三小，“我若要寫multi-thread,會傾
→ TeddyCaptain: 向使用node的async寫法”，這句話邏輯在哪?? 被糾
→ TeddyCaptain: 正還7pupu
※ 編輯: tofuflower (42.77.40.73), 12/24/2017 23:32:24
推 TeddyCaptain: 講錯被糾正像原po那樣不是很好ㄇ，硬掰當沒人懂node
→ TeddyCaptain: 膩
推 imreader: 上面我給的文章先看完，最後有 async callback 的說明
→ imreader: 這裡都要咬文嚼字，用字精準，也太累了
→ imreader: 我明確的說，multi-thread 大部份就是要做非同步的作業
→ imreader: 像偵測 UI 按鍵時，還能讀取檔案I/O
→ imreader: 檔案讀取完，直接呼叫 callback function
→ imreader: 這種工作，若在 python 就要開 thread 來寫
→ imreader: 但 node js 就直接 async callback 的寫法
推 imreader: 好了，來玩電動了，剩下的我就不回了 XD
推 TeddyCaptain: 還在凹捏，node在處理io以外的工作沒辦法做到實質上
→ TeddyCaptain: 的multithreading本來就是天生的痛點，這個原po已經
→ TeddyCaptain: 講的很清楚了，你還在那邊用async解，看到豆頁都痛
→ TeddyCaptain: ㄌ說
推 s25g5d4: imreader 搞清楚 CPU-bound 跟 IO-bound 差別好嗎
噓 kwpn: C++根本就不需要GC 你根本不懂GC是啥吧?
我為錯誤的言致歉，已更改原文
※ 編輯: tofuflower (42.77.40.73), 12/25/2017 00:00:16
→ elements: 現在的 io 大多不用 block，而是用 epoll 交給作業系統
→ elements: 去等，只要少少幾條專有的執行緒跑事件迴圈就可以了。
→ elements: 但多執行緒一個很重要的用途是利用多核心，這點如果你
→ elements: 自己的code沒辦法泡在其他 thread 就沒辦法
推 imreader: 就算是 IO-bound 在 python，是不是要用 thread 來寫
推 TeddyCaptain: 奇怪捏，原po有像imreader一樣在那邊硬凹ㄇ？第一
→ TeddyCaptain: 個幫忙糾錯的很好，大家有交流才有進步嘛，啊他不是
→ imreader: 光確認 thread-safe，就不是很直覺的事了
→ TeddyCaptain: 也修文跟道歉了？後面一堆眼紅好像要把人往死裡嗆
→ TeddyCaptain: 的是怎樣，而且還是嗆一樣的東西，一點幫助都沒有，
→ TeddyCaptain: 是要他下跪膩
→ elements: 老實說c++我一直不覺得你講錯什麼，記憶體管理的確是一
→ elements: 個很大的痛點，特別是你在專案大又多執行緒的時候，所
→ elements: 有權的問題有時候很難釐清。但那就是你要把控制記憶體
→ elements: 釋放時機的權力拿回手上的代價。
→ imreader: CPU bound 我前面不是有寫過，就改用 multi-workers
→ imreader: 大家好像覺得寫 thread 的程式，是很輕鬆容易的事一樣
→ imreader: 我可不認為，能不寫就不寫
→ laputaflutin: 非同步跟執行緒的問題本質完全不一樣啊，更別說pyt
→ laputaflutin: hon也有 async 語法了……這根本不是什麼咬文嚼字
→ laputaflutin: ，而是理解有誤
→ TeddyCaptain: 我也是覺得寫db操作好麻煩，應該都in-memory就好，
→ TeddyCaptain: 能不寫就不寫
→ ku399999: XD
推 sky790312: 現在JS ide都能裝coding style不會到CICD才發現;錯誤@@
謝提醒，修正原文
※ 編輯: tofuflower (42.77.40.73), 12/25/2017 00:49:12
→ alan3100: 我覺得你要認真回他是件很辛苦的事 不會有交集
推 s25g5d4: 講幾個補充好了，本公司用 TypeScript 開發，雖然是
→ s25g5d4: compile time check  而已，但已經比純 JS 好太多了
→ s25g5d4: 少個 ; 甚至 type 不對的問題都有解，只是很麻煩是真的
→ s25g5d4: 有些人認為這樣就喪失 JS 靈活的特性了，但我覺得還好，
推 TitanEric: 推這篇 學到好多
推 chatnoir: 這篇..其實不錯！
→ bcew: python也有pylint可以coding時發現語法問題喔
推 steve1012: 我感覺修正完還是有點問題啊 建議你把 c++ gc整段移掉
→ steve1012: 吧 並不是那樣
如同前面板友提到的，我不應該對自己不熟的語言妄下評論，因此原文在最前面提醒讀者
"這段評論是有問題的"。但在我搞清楚 C++ 的 GC 前，我不會再去對 C++ 的記憶體管理
做其他評論。


推 Shauter: Java好棒喔 就交給各位寫了
不，因為原文的推文在戰 Java，所以這篇文章才會討論到比較多我覺得 Java 比較佔優
勢的情境。但 Java 倒沒有威猛到可以統一全程式：
1. 論語法簡潔，開發速度遠不如 Python，Golang
   (更別提資份分析領域，Python 的確表現遠比 Java 好)
2. 論效能被 C 家族屌打
3. 程式啟動速度的確是慢，尤其你用了 spring 系列以後，那啟動速度簡直令人頭痛
   (希望 Java9 的模組化有解決這點)

我的想法是每個語言都有擅長處理和不擅長處理的情境，我更傾向是大家一起分享各自
熟悉的語言在什麼情況下有優勢，在什麼情況下相對會花更多心思處理。

以 Python 為例，雖然 Python 在處理高併發並不如他在其他領域表現優越，但 IG 工
程師就是熱愛他的開發快速，因此花不少心力在調校 Python runtime 效能 (例如關掉
 GC)。

因此，單你的使用情境是高併發需求，而你的工程團隊又沒有 IG 如此強悍時，Python
可能不是你的首選。
反之若高併發並不讓你覺得痛 (老子有一票慓悍的工程師 or 老子有本錢在 AWS 開幾百
台機器)，在搶開發速度上我也是選 Python。

→ obamina48: imreader 真的懂 JS 嗎…
推 sorryla: C++引入smart pointer後，記憶體管理早就沒那麼難了。
→ sorryla: 物件所有權很難釐清，丟給GC就萬事解決了嗎？你怎麼知道G
→ sorryla: C會不會真的幫你解決？物件關係沒處理好GC一樣幫不了你。
→ sorryla: 自己不搞懂只想讓GC擦屁股並不是好的作法。
GC 的確不是萬靈藥。我的想法是有一套現成已經通過時間考驗的 GC 機制，是 Java
一項優勢之一，但不是有了 GC 就無敵了。

物件沒處理好的確也會有 memory leak 的問題， Java 相對的優勢僅止於他可以讓工程
師比較輕鬆的處理 GC，但不代表工程師可以不用了解 GC。


→ kwpn: 只學半套的才會說C++記憶體很難管理
的確我對 C 系列只學半套，因此我對我妄下評論深感道歉。
但同時我是真的覺得大系統的 GC 是件很困難的事。

由於我覺得一篇文章被指出錯誤，那麼這個錯誤的地方和討論錯誤的評論就應該保留著，
讓後來看到這篇文章的讀者可以知道 context，因此我選擇在原文前面註記這段內容是有
問題的，而不是刪除該內容。
※ 編輯: tofuflower (223.140.91.246), 12/25/2017 09:11:05
推 johnny94: 這篇很好啊，講錯點出來就好了，一堆人往死裡嗆是怎樣？
推 Sirctal: 推樓上 我也覺得大家太嗜血了 有錯點一下就好
→ Sirctal: 只是討論而已有必要這樣?? 自古以來文人總是相輕...
推 steve1012: 還好啦 我覺得錯的拿掉就好 就不會繼續回啦
我願意道歉，並註記這段內容是有問題的，但不會刪除原文，原因如上述。
更何況刪了原文就吸引不到高手幫我做 C 語言教學了 (欸?

→ alan3100: 這篇不是特別回應某個躲在推文講大話的人嗎? 戰火沒交集
※ 編輯: tofuflower (223.140.91.246), 12/25/2017 09:15:28
→ testPtt: C++因為沒批次釋放的需要 所以不需要GC
噓 Sidney0503: C++從頭到尾就是錯的  你改了幾次都是錯的
噓 Ommm5566: 哈哈哈 做不到就說盡量不用  然後繼續鼓吹該語言無敵
→ Ommm5566: "不怕神一般的敵人  就怕豬一般的隊友"這句話真是經典
推 Ommm5566: 語法問題都有lint提示了  coding sytle不是問題
→ Ommm5566: python明明就有各種level的multi-thread
→ Ommm5566: 可以由使用者選擇要不要fork
推 loxyz: 願意分享看法推
推 imreader: 我想起來了，之前不用 python thread 的原因
→ imreader: 是因為 thread 裡用到的 module 也必須是 thread safe
→ imreader: 然後就找到 gevent 這種 coroutine 的東西
→ imreader: 用起來渾身不自在。然後 node js 開始用了以後
→ imreader: 發覺不用理會 thread-safe ，還能做 non-blocking 的
→ imreader: 非同步作業。若是要用多 CPU，也能用 PM2 的 cluster
推 Sidney0503: 因為我不會malloc和free 所以我都使用不須delete的語
→ imreader: 若 thread 用到的 module 也要 thread-safe 這樣就
→ Sidney0503: c語言真他媽有夠廢 還要人工free
→ imreader: 讓 python 豐富模組庫的好處盡失
→ Sidney0503: 指標有夠爛  動不動就跟我報讀取非法區間的error
→ imreader: 尤其是第三方的，很多都沒有 thread safe
→ imreader: 基本上我本身是 python, node js 混用的
→ Sidney0503: c語言看TIOBE可以看到正在下降
→ imreader: node js 我也是開 coffeescript 寫 python 的類似語法XD
→ Sidney0503: 大家還是不要用c語言好了 沒有保證memory safty
推 fishlinghu: 怎麼有人不會用怪語言爛啊XDDDD
→ Sidney0503: 沒有mem-safty的語言用起來渾身不自在
→ fishlinghu: 我好像被反串釣到惹XDDD
→ Sidney0503: 對我而言要memory safty超不直覺
推 imreader: https://goo.gl/FLD2Xa 感謝網友提到 epoll 的關鍵字
推 rayway30419: 自己注意thread safe不是很合理嗎wwwww
→ imreader: 目前 node.js 會依 OS 自行選用 epoll、poll、dev/poll
→ imreader: select 和kqueue
→ imreader: @rayway30419，主要是引用的第三方別人寫的 module
→ imreader: 也要 thread-safe
推 Sidney0503: 我推薦大家使用rust 這才有guaranteed memory safety
→ Sidney0503: 大家好像覺得寫pointer的程式，是很輕鬆容易的事一樣
→ Sidney0503: 我可不認為，能不寫就不寫
→ Sidney0503: 但對我來講memory safe ，寫起來直覺，就很好用了
推 imreader: 樓上在開我玩笑，但我認同這點。因為在 python, node js
→ imreader: 不需 pointer ，就能做 pointer 能做到的事
→ imreader: 動態資料結構都能用 python, node js 來製作
推 imreader: 另外，我也來推廣一下 coffeescript
→ imreader: 不知道有沒有 python 的愛好者，夢想有天也能在前端寫
→ imreader: python 的語法，coffeescript 就是解方
→ imreader: 目前還能搭配 es2016 的 module 封裝，
→ imreader: 還有 async, await 輕鬆解決 callback hell
推 imreader: http://coffeescript.org/#classes
→ imreader: class 跟 python 特有的縮排對齊都能用
推 imreader: coffee 不只能寫前端，還能用在 NODE JS
噓 pttuser: C++ 效能並不一定總是能樂勝 Java ？呵呵一堆幹話
推 vvind: 推
推 sssh9300662: 推分享，有錯也沒關係，怎一堆人一定要抓錯酸一下，
→ sssh9300662: 有討論才有進步阿
→ sssh9300662: Async跟multi thread完完全全兩回事，可以的話我也不
→ sssh9300662: 想碰multi thread阿XD
→ zenixls2: 這篇內文到推文我到底看了啥...
→ alan3100: 幫補個java8+ multi-thread簡介 https://goo.gl/qucbaq
→ alan3100: 推文亂七八糟真的很無言
推 dragoncfe168: C#現在已可跨平台了 蠻想專精C#就好 貪多嚼不爛@@
→ dragoncfe168: 人生又不是很長 何不專注把C#學精熟?!
推 dragoncfe168: 俗話說:螣蛇無足而飛，梧鼠五技而窮!╮(﹀_﹀")╭
推 wildli0422: 好文給推 謝謝分享
推 Bencrie: 嗆人才能突顯自己念名校的尊爵不凡 XD
推 gmoz: 推
推 yupog2003: 推原po理性討論
推 Darkautism: 真的假的 我都寫c欸 沒想到free被大家嫌
噓 jpopaholic: 只要jvm不死的話java就不會死，Hadoop,spark,jsp,甚
→ jpopaholic: 至偷改的android,都是base on java
推 clairehuei: 瑕不掩瑜,不懂某些人是在崩潰啥...
推 DolphinLinn: 我想說的是node本身就有Cluster模組 不需要使用pm2
→ DolphinLinn: 也可以...
推 aszx4510: 整理的很棒 感謝資訊分享
推 Shauter: base on java 好個阿Q想法 XDDDDDDD
→ realmeat: 不用IDE開發就好了, 何時IDE也成了原罪, 超級有趣