作者tofuflower (无)
看板Soft_Job
标题Re: [讨论] 2018 各语言就业工作前景
时间Sun Dec 24 21:34:47 2017
没想到下面推文意外战起 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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1514122489.A.85C.html
1F：推 imreader: 补充你指出的 thread 问题，我若要做 multi-thread，12/24 21:42
2F：→ imreader: 我会倾向使用 Node JS 的 Async 写法，完全不用担心12/24 21:43
3F：→ imreader: Thread-safe 的问题12/24 21:44
4F：→ imreader: 加上 ES2016 以後有 Async, Await 的终极方案12/24 21:44
可能我表达不够清楚让你误会我意思了
我的意思是 Node 目前本质上是在 application level 的 single thread，
这让他在同时运用多个 CPU 做事情会比 Java 还要有挑战。
这意味着如果你想要榨乾多 CPU 系统效能的话， Node 会比 Java 需要花更多心力。
题外话，这件事 Golang 做的比两者都好 (但还是有些小陷阱)，算是整合两边所长。
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 21:52:42
5F：推 imreader: 另外 Node JS 也可以用 coffeescript 做 transpiler12/24 21:52
6F：→ imreader: 直接写 python like 的排版语法来写作12/24 21:53
7F：→ imreader: 你自已都知道 PM2 了，再配合 async 写法，12/24 21:54
8F：→ imreader: 多 CPU 也能轻松运用12/24 21:54
9F：→ imreader: 对我来讲，这就起多个 node 行程，做 multi-workers 12/24 21:56
10F：推 imreader: 用 python 的 celery 来写 async，远远不及 node js 12/24 22:08
11F：→ imreader: 的 async, await 直觉、易用12/24 22:08
我想我表达得不够清楚，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
12F：→ imreader: python 跟 node js 刚好一个同步、一个非同步互相搭配 12/24 22:09
13F：推 Sirctal: C++不需要GC好吗？？ C++11有smart pointer...12/24 22:14
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 22:25:35
14F：→ x000032001: 虽然不写Java 它在大数据和企业级应用的确占有一块 12/24 22:37
15F：→ x000032001: 一直鄙视而不正视它为何被使用 那是狂热信徒才做的事12/24 22:38
16F：嘘 chiaming0914: 对c++不熟就不要随便乱讲 12/24 22:43
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 22:45:57
对不起，这点的确是我说错，已修正原文。
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 22:50:16
17F：→ elements: smart ptr 比起 GC 有更多眉角，c++ 也有 mark and swe12/24 22:49
18F：→ elements: ep 就是了，只是要另外弄。 12/24 22:49
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 22:52:21
19F：推 backprog: 这边够详细推12/24 22:52
20F：→ remmurds: 某楼怎摸会把async跟multi thread混为一谈...12/24 23:02
21F：推 imreader: 某楼不用指正教学，thread 跟 async 本质有差我知道12/24 23:07
22F：→ imreader: 但能不用 multi-thread 写的话，我会尽量不用 12/24 23:08
23F：推 nbajam: 认同给推12/24 23:09
24F：推 imreader: 对 async, multi-thread 区别有兴趣的话，可以看这篇12/24 23:13
26F：→ imreader: 但对我来讲 thread-safe ，写起来直觉，就很好用了12/24 23:13
27F：推 CGS0: c++ 写的好 就保持习惯 做的比 Java 的 GC 还烂 应该是很快12/24 23:21
28F：→ CGS0: 就不行了12/24 23:21
29F：→ CGS0: 请讲自己写很久的部份就好 不用乱猜其他语言 12/24 23:22
C++ 这点是我疏忽，请其他版友不要被我误导
30F：推 TeddyCaptain: imreader是在供三小，“我若要写multi-thread,会倾12/24 23:28
31F：→ TeddyCaptain: 向使用node的async写法”，这句话逻辑在哪?? 被纠12/24 23:28
32F：→ TeddyCaptain: 正还7pupu 12/24 23:28
※ 编辑: tofuflower (42.77.40.73), 12/24/2017 23:32:24
33F：推 TeddyCaptain: 讲错被纠正像原po那样不是很好ㄇ，硬掰当没人懂node12/24 23:31
34F：→ TeddyCaptain: 腻12/24 23:31
35F：推 imreader: 上面我给的文章先看完，最後有 async callback 的说明12/24 23:32
36F：→ imreader: 这里都要咬文嚼字，用字精准，也太累了 12/24 23:33
37F：→ imreader: 我明确的说，multi-thread 大部份就是要做非同步的作业 12/24 23:33
38F：→ imreader: 像侦测 UI 按键时，还能读取档案I/O12/24 23:33
39F：→ imreader: 档案读取完，直接呼叫 callback function 12/24 23:34
40F：→ imreader: 这种工作，若在 python 就要开 thread 来写 12/24 23:34
41F：→ imreader: 但 node js 就直接 async callback 的写法 12/24 23:34
42F：推 imreader: 好了，来玩电动了，剩下的我就不回了 XD 12/24 23:36
43F：推 TeddyCaptain: 还在凹捏，node在处理io以外的工作没办法做到实质上 12/24 23:49
44F：→ TeddyCaptain: 的multithreading本来就是天生的痛点，这个原po已经 12/24 23:49
45F：→ TeddyCaptain: 讲的很清楚了，你还在那边用async解，看到豆页都痛 12/24 23:49
46F：→ TeddyCaptain: ㄌ说 12/24 23:49
47F：推 s25g5d4: imreader 搞清楚 CPU-bound 跟 IO-bound 差别好吗 12/24 23:56
48F：嘘 kwpn: C++根本就不需要GC 你根本不懂GC是啥吧? 12/24 23:57
我为错误的言致歉，已更改原文
※ 编辑: tofuflower (42.77.40.73), 12/25/2017 00:00:16
49F：→ elements: 现在的 io 大多不用 block，而是用 epoll 交给作业系统 12/24 23:58
50F：→ elements: 去等，只要少少几条专有的执行绪跑事件回圈就可以了。 12/24 23:58
51F：→ elements: 但多执行绪一个很重要的用途是利用多核心，这点如果你 12/24 23:58
52F：→ elements: 自己的code没办法泡在其他 thread 就没办法 12/24 23:58
53F：推 imreader: 就算是 IO-bound 在 python，是不是要用 thread 来写 12/25 00:07
54F：推 TeddyCaptain: 奇怪捏，原po有像imreader一样在那边硬凹ㄇ？第一 12/25 00:08
55F：→ TeddyCaptain: 个帮忙纠错的很好，大家有交流才有进步嘛，啊他不是 12/25 00:08
56F：→ imreader: 光确认 thread-safe，就不是很直觉的事了 12/25 00:08
57F：→ TeddyCaptain: 也修文跟道歉了？後面一堆眼红好像要把人往死里呛 12/25 00:08
58F：→ TeddyCaptain: 的是怎样，而且还是呛一样的东西，一点帮助都没有， 12/25 00:08
59F：→ TeddyCaptain: 是要他下跪腻 12/25 00:08
60F：→ elements: 老实说c++我一直不觉得你讲错什麽，记忆体管理的确是一 12/25 00:09
61F：→ elements: 个很大的痛点，特别是你在专案大又多执行绪的时候，所 12/25 00:09
62F：→ elements: 有权的问题有时候很难厘清。但那就是你要把控制记忆体 12/25 00:09
63F：→ elements: 释放时机的权力拿回手上的代价。 12/25 00:09
64F：→ imreader: CPU bound 我前面不是有写过，就改用 multi-workers 12/25 00:09
65F：→ imreader: 大家好像觉得写 thread 的程式，是很轻松容易的事一样 12/25 00:10
66F：→ imreader: 我可不认为，能不写就不写 12/25 00:10
67F：→ laputaflutin: 非同步跟执行绪的问题本质完全不一样啊，更别说pyt 12/25 00:11
68F：→ laputaflutin: hon也有 async 语法了……这根本不是什麽咬文嚼字 12/25 00:11
69F：→ laputaflutin: ，而是理解有误 12/25 00:11
70F：→ TeddyCaptain: 我也是觉得写db操作好麻烦，应该都in-memory就好， 12/25 00:26
71F：→ TeddyCaptain: 能不写就不写 12/25 00:26
72F：→ ku399999: XD 12/25 00:29
73F：推 sky790312: 现在JS ide都能装coding style不会到CICD才发现;错误@@ 12/25 00:38
谢提醒，修正原文
※ 编辑: tofuflower (42.77.40.73), 12/25/2017 00:49:12
74F：→ alan3100: 我觉得你要认真回他是件很辛苦的事 不会有交集 12/25 00:57
75F：推 s25g5d4: 讲几个补充好了，本公司用 TypeScript 开发，虽然是 12/25 01:09
76F：→ s25g5d4: compile time check 而已，但已经比纯 JS 好太多了 12/25 01:10
77F：→ s25g5d4: 少个 ; 甚至 type 不对的问题都有解，只是很麻烦是真的 12/25 01:10
78F：→ s25g5d4: 有些人认为这样就丧失 JS 灵活的特性了，但我觉得还好， 12/25 01:10
79F：推 TitanEric: 推这篇 学到好多 12/25 01:16
80F：推 chatnoir: 这篇..其实不错！ 12/25 01:29
81F：→ bcew: python也有pylint可以coding时发现语法问题喔 12/25 01:38
82F：推 steve1012: 我感觉修正完还是有点问题啊 建议你把 c++ gc整段移掉 12/25 01:54
83F：→ steve1012: 吧 并不是那样 12/25 01:54
如同前面板友提到的，我不应该对自己不熟的语言妄下评论，因此原文在最前面提醒读者
"这段评论是有问题的"。但在我搞清楚 C++ 的 GC 前，我不会再去对 C++ 的记忆体管理
做其他评论。
84F：推 Shauter: Java好棒喔 就交给各位写了 12/25 01:55
不，因为原文的推文在战 Java，所以这篇文章才会讨论到比较多我觉得 Java 比较占优
势的情境。但 Java 倒没有威猛到可以统一全程式：
1. 论语法简洁，开发速度远不如 Python，Golang
(更别提资份分析领域，Python 的确表现远比 Java 好)
2. 论效能被 C 家族屌打
3. 程式启动速度的确是慢，尤其你用了 spring 系列以後，那启动速度简直令人头痛
(希望 Java9 的模组化有解决这点)
我的想法是每个语言都有擅长处理和不擅长处理的情境，我更倾向是大家一起分享各自
熟悉的语言在什麽情况下有优势，在什麽情况下相对会花更多心思处理。
以 Python 为例，虽然 Python 在处理高并发并不如他在其他领域表现优越，但 IG 工
程师就是热爱他的开发快速，因此花不少心力在调校 Python runtime 效能 (例如关掉
GC)。
因此，单你的使用情境是高并发需求，而你的工程团队又没有 IG 如此强悍时，Python
可能不是你的首选。
反之若高并发并不让你觉得痛 (老子有一票慓悍的工程师 or 老子有本钱在 AWS 开几百
台机器)，在抢开发速度上我也是选 Python。
85F：→ obamina48: imreader 真的懂 JS 吗… 12/25 02:06
86F：推 sorryla: C++引入smart pointer後，记忆体管理早就没那麽难了。 12/25 03:53
87F：→ sorryla: 物件所有权很难厘清，丢给GC就万事解决了吗？你怎麽知道G 12/25 03:56
88F：→ sorryla: C会不会真的帮你解决？物件关系没处理好GC一样帮不了你。 12/25 03:56
89F：→ sorryla: 自己不搞懂只想让GC擦屁股并不是好的作法。 12/25 03:56
GC 的确不是万灵药。我的想法是有一套现成已经通过时间考验的 GC 机制，是 Java
一项优势之一，但不是有了 GC 就无敌了。
物件没处理好的确也会有 memory leak 的问题， Java 相对的优势仅止於他可以让工程
师比较轻松的处理 GC，但不代表工程师可以不用了解 GC。
90F：→ kwpn: 只学半套的才会说C++记忆体很难管理 12/25 08:25
的确我对 C 系列只学半套，因此我对我妄下评论深感道歉。
但同时我是真的觉得大系统的 GC 是件很困难的事。
由於我觉得一篇文章被指出错误，那麽这个错误的地方和讨论错误的评论就应该保留着，
让後来看到这篇文章的读者可以知道 context，因此我选择在原文前面注记这段内容是有
问题的，而不是删除该内容。
※ 编辑: tofuflower (223.140.91.246), 12/25/2017 09:11:05
91F：推 johnny94: 这篇很好啊，讲错点出来就好了，一堆人往死里呛是怎样？ 12/25 08:57
92F：推 Sirctal: 推楼上 我也觉得大家太嗜血了 有错点一下就好 12/25 09:01
93F：→ Sirctal: 只是讨论而已有必要这样?? 自古以来文人总是相轻... 12/25 09:01
94F：推 steve1012: 还好啦 我觉得错的拿掉就好 就不会继续回啦 12/25 09:06
我愿意道歉，并注记这段内容是有问题的，但不会删除原文，原因如上述。
更何况删了原文就吸引不到高手帮我做 C 语言教学了 (欸?
95F：→ alan3100: 这篇不是特别回应某个躲在推文讲大话的人吗? 战火没交集 12/25 09:10
※ 编辑: tofuflower (223.140.91.246), 12/25/2017 09:15:28
96F：→ testPtt: C++因为没批次释放的需要 所以不需要GC 12/25 09:27
97F：嘘 Sidney0503: C++从头到尾就是错的 你改了几次都是错的 12/25 09:58
98F：嘘 Ommm5566: 哈哈哈 做不到就说尽量不用 然後继续鼓吹该语言无敌 12/25 10:12
99F：→ Ommm5566: "不怕神一般的敌人 就怕猪一般的队友"这句话真是经典 12/25 10:15
100F：推 Ommm5566: 语法问题都有lint提示了 coding sytle不是问题 12/25 10:20
101F：→ Ommm5566: python明明就有各种level的multi-thread 12/25 10:21
102F：→ Ommm5566: 可以由使用者选择要不要fork 12/25 10:22
103F：推 loxyz: 愿意分享看法推 12/25 10:26
104F：推 imreader: 我想起来了，之前不用 python thread 的原因 12/25 10:27
105F：→ imreader: 是因为 thread 里用到的 module 也必须是 thread safe 12/25 10:27
106F：→ imreader: 然後就找到 gevent 这种 coroutine 的东西 12/25 10:28
107F：→ imreader: 用起来浑身不自在。然後 node js 开始用了以後 12/25 10:28
108F：→ imreader: 发觉不用理会 thread-safe ，还能做 non-blocking 的 12/25 10:29
109F：→ imreader: 非同步作业。若是要用多 CPU，也能用 PM2 的 cluster 12/25 10:29
110F：推 Sidney0503: 因为我不会malloc和free 所以我都使用不须delete的语 12/25 10:30
111F：→ imreader: 若 thread 用到的 module 也要 thread-safe 这样就 12/25 10:30
112F：→ Sidney0503: c语言真他妈有够废 还要人工free 12/25 10:30
113F：→ imreader: 让 python 丰富模组库的好处尽失 12/25 10:30
114F：→ Sidney0503: 指标有够烂 动不动就跟我报读取非法区间的error 12/25 10:30
115F：→ imreader: 尤其是第三方的，很多都没有 thread safe 12/25 10:31
116F：→ imreader: 基本上我本身是 python, node js 混用的 12/25 10:31
117F：→ Sidney0503: c语言看TIOBE可以看到正在下降 12/25 10:32
118F：→ imreader: node js 我也是开 coffeescript 写 python 的类似语法XD 12/25 10:32
119F：→ Sidney0503: 大家还是不要用c语言好了 没有保证memory safty 12/25 10:32
120F：推 fishlinghu: 怎麽有人不会用怪语言烂啊XDDDD 12/25 10:33
121F：→ Sidney0503: 没有mem-safty的语言用起来浑身不自在 12/25 10:33
122F：→ fishlinghu: 我好像被反串钓到惹XDDD 12/25 10:33
123F：→ Sidney0503: 对我而言要memory safty超不直觉 12/25 10:34
125F：推 rayway30419: 自己注意thread safe不是很合理吗wwwww 12/25 10:38
126F：→ imreader: 目前 node.js 会依 OS 自行选用 epoll、poll、dev/poll 12/25 10:39
127F：→ imreader: select 和kqueue 12/25 10:39
128F：→ imreader: @rayway30419，主要是引用的第三方别人写的 module 12/25 10:40
129F：→ imreader: 也要 thread-safe 12/25 10:40
130F：推 Sidney0503: 我推荐大家使用rust 这才有guaranteed memory safety 12/25 10:44
131F：→ Sidney0503: 大家好像觉得写pointer的程式，是很轻松容易的事一样 12/25 10:46
132F：→ Sidney0503: 我可不认为，能不写就不写 12/25 10:46
133F：→ Sidney0503: 但对我来讲memory safe ，写起来直觉，就很好用了 12/25 10:47
134F：推 imreader: 楼上在开我玩笑，但我认同这点。因为在 python, node js 12/25 10:47
135F：→ imreader: 不需 pointer ，就能做 pointer 能做到的事 12/25 10:47
136F：→ imreader: 动态资料结构都能用 python, node js 来制作 12/25 10:48
137F：推 imreader: 另外，我也来推广一下 coffeescript 12/25 11:15
138F：→ imreader: 不知道有没有 python 的爱好者，梦想有天也能在前端写 12/25 11:15
139F：→ imreader: python 的语法，coffeescript 就是解方 12/25 11:16
140F：→ imreader: 目前还能搭配 es2016 的 module 封装， 12/25 11:16
141F：→ imreader: 还有 async, await 轻松解决 callback hell 12/25 11:17
143F：→ imreader: class 跟 python 特有的缩排对齐都能用 12/25 11:19
144F：推 imreader: coffee 不只能写前端，还能用在 NODE JS 12/25 11:36
145F：嘘 pttuser: C++ 效能并不一定总是能乐胜 Java ？呵呵一堆干话 12/25 12:07
146F：推 vvind: 推 12/25 12:44
147F：推 sssh9300662: 推分享，有错也没关系，怎一堆人一定要抓错酸一下， 12/25 12:55
148F：→ sssh9300662: 有讨论才有进步阿 12/25 12:55
149F：→ sssh9300662: Async跟multi thread完完全全两回事，可以的话我也不 12/25 12:56
150F：→ sssh9300662: 想碰multi thread阿XD 12/25 12:56
151F：→ zenixls2: 这篇内文到推文我到底看了啥... 12/25 12:59
153F：→ alan3100: 推文乱七八糟真的很无言 12/25 13:46
154F：推 dragoncfe168: C#现在已可跨平台了 蛮想专精C#就好 贪多嚼不烂@@ 12/25 13:49
155F：→ dragoncfe168: 人生又不是很长 何不专注把C#学精熟?! 12/25 13:50
156F：推 dragoncfe168: 俗话说:螣蛇无足而飞，梧鼠五技而穷!╮(﹀_﹀")╭ 12/25 13:53
157F：推 wildli0422: 好文给推 谢谢分享 12/25 15:38
158F：推 Bencrie: 呛人才能突显自己念名校的尊爵不凡 XD 12/25 18:07
159F：推 gmoz: 推 12/25 18:11
160F：推 yupog2003: 推原po理性讨论 12/25 22:30
161F：推 Darkautism: 真的假的 我都写c欸 没想到free被大家嫌 12/26 00:53
162F：嘘 jpopaholic: 只要jvm不死的话java就不会死，Hadoop,spark,jsp,甚 12/26 01:06
163F：→ jpopaholic: 至偷改的android,都是base on java 12/26 01:06
164F：推 clairehuei: 瑕不掩瑜,不懂某些人是在崩溃啥... 12/26 11:59
165F：推 DolphinLinn: 我想说的是node本身就有Cluster模组 不需要使用pm2 12/26 15:01
166F：→ DolphinLinn: 也可以... 12/26 15:01
167F：推 aszx4510: 整理的很棒 感谢资讯分享 12/26 15:01
168F：推 Shauter: base on java 好个阿Q想法 XDDDDDDD 12/27 10:48
169F：→ realmeat: 不用IDE开发就好了, 何时IDE也成了原罪, 超级有趣 12/29 09:49