台灣人瘋學 Python 是集體走錯路？冷門語言 Elixir 才是高併發時代的真正解答，你的努力方向根本搞反了

當所有人都在刷 LeetCode、上 Python 補習班的時候，真正的高併發戰場早就換了武器。Elixir 和它底下的 BEAM 虛擬機，才是分散式系統工程師夢寐以求的運算模型——但這不代表你該立刻拋棄 Python。問題的本質，比「該學哪個語言」深刻得多。

上個月我在大學部開的分散式系統課上做了個小實驗:問 120 個學生，「你學程式的第一門語言是什麼？」

112 個人說 Python。

剩下 8 個，有幾個說 C，有兩個說 JavaScript。沒有人——一個都沒有——說過任何 functional programming 語言。零。

我不怪他們。打開台灣任何一個程式學習平台，Python 的課程數量大概是其他語言的十倍。補習班、線上課、YouTube 教學，全部都在教你用 Python 做機器學習、寫爬蟲、搞資料分析。好像只要學會 Python，就拿到進入科技業的門票了。

但我想問一個不太舒服的問題:如果你的目標是蓋一棟能扛住地震的大樓，你會只學怎麼用油漆嗎？

Python 的 GIL 是一道隱形天花板

坦白講，Python 是一門非常好的語言。語法乾淨，生態系龐大，拿來做原型設計、資料分析、寫個 script 自動化流程，它幾乎無可取代。但多數人不知道的是，CPython 的 Global Interpreter Lock（GIL）讓你的多執行緒程式在 CPU-bound 任務上基本是假的並行。

你寫了 threading，你以為自己在做平行運算。其實 interpreter 同一時間只讓一個 thread 跑。這在處理 I/O-bound 的場景（比如打 API、讀檔案）還過得去，因為等待的時候可以切換。但在真正需要同時處理十萬個 WebSocket 連線、即時推播、或是高頻交易的場景？GIL 就是那道你看不見的天花板。

（對，我知道 Python 3.13 開始有 free-threaded 模式的實驗。但那還在非常早期。）

BEAM VM:一台四十年前設計、卻為今天而生的機器

這時候我們該聊聊 Elixir 了。

Elixir 本身在 2012 年才誕生，但它跑在 BEAM 虛擬機上——Erlang 的運行環境。而 Erlang 是 1986 年在 Ericsson 為了電信交換機設計的。你沒聽錯，四十年前。

BEAM 的核心哲學是 Actor Model:每個 process 是一個極度輕量的獨立運算單元（大約只佔 2KB 記憶體，不是作業系統的 process），彼此之間零共享狀態，只透過 message passing 溝通。一台普通的機器上，你可以輕鬆跑起幾十萬甚至上百萬個 BEAM process。

這代表什麼？代表高併發不是你「設計」出來的——它是語言的預設行為。你不需要去想 thread pool 要開多大、lock 要怎麼加、race condition 會不會炸掉你的 shared state。BEAM 的 scheduler 會自動把 process 分配到所有可用的 CPU core 上，做 preemptive scheduling，還有 per-process 的 garbage collection（一個 process 的 GC 不會 stop the world）。

這是根本性的架構差異。不是「稍微快一點」的差異。

「那 Go 呢？」

一定有人這樣問。Go 的 goroutine 確實也很輕量，CSP 模型的 channel 通訊也很漂亮。但 Go 有幾個 Elixir/BEAM 做得到、它做不到的事:

容錯。 BEAM 的 supervision tree 讓你可以定義「如果某個 process 掛了，要怎麼重啟」。這不是 try-catch，這是系統層級的自我修復機制——Erlang 社群那句著名的哲學「Let it crash」就是這個意思。你的程式不是不會出錯，而是出錯之後能在毫秒內自動恢復。Go 的 goroutine panic 了？整個程序掰掰（除非你到處寫 recover，但那很醜而且容易漏）。

熱更新。 BEAM 支援 hot code swapping。你可以在系統不停機的情況下更新正在運行的程式碼。電信系統要求 99.9999% uptime（一年只能停機 31.5 秒），這功能不是花俏——是生存需求。

但我要潑一盆冷水

如果你看到這裡覺得「好，我明天就改學 Elixir」——等等。

Elixir 的生態系跟 Python 比起來，差距是數量級的。機器學習？Python 有 PyTorch、TensorFlow、Hugging Face。Elixir 有 Nx 和 Axon，很有潛力但還在早期。資料科學？Python 的 pandas 生態幾乎是產業標準。Web 開發？Phoenix 框架確實非常優秀（Phoenix LiveView 的即時互動體驗令人印象深刻），但工作機會跟 Django、FastAPI 比根本不在同一個量級。

在台灣，用 Elixir 的公司大概用一隻手數得出來。你學了之後，履歷上這行在多數 HR 眼裡等於不存在。

這就是殘酷的現實。

真正的問題不是語言，是思維模型

我真正想說的其實不是「Python 爛、Elixir 好」這種二元對立。那太廉價了。

我想說的是——台灣的程式教育太執著於「語法」，而幾乎完全忽略了「計算模型」。你學 Python 的 for loop 學了一百遍，但你有沒有真正理解 concurrency 跟 parallelism 的差別？你知道 CSP 和 Actor Model 各自在什麼場景下有優勢嗎？你有想過為什麼 WhatsApp 用 Erlang 只靠 32 個工程師就撐住了當時 9 億用戶的即時通訊嗎？

語言是工具。但選錯了計算模型，你的工具箱裡裝的全是螺絲起子，然後你要去釘釘子。

老實說，我希望每個學 Python 的人都至少花兩週碰一下 Elixir 或 Erlang——不是為了轉行，而是為了理解「原來程式可以不這樣寫」。那種 paradigm shift 的衝擊感，會讓你回去寫 Python 的時候變成一個完全不同的工程師。

你不一定要會用 Elixir。但你不能不知道 BEAM 告訴我們的那件事:在真正的分散式世界裡，共享狀態才是萬惡之源。