作業系統我是沒寫過的，但是我用C語言和組合語言給C51、AVR、STM32等寫了很多的程式， 談點自己的看法。
使用何種語言寫作業系統，很大一部分原因是受到目標平臺硬體的影響，或者更準確地說，是CPU的影響，可以謹慎地講，語言的本質是指令集，而指令集是物理電路的抽象。因此，一個特定的CPU肯定對應了一套特定的指令集，當然考慮到相容性等因素，也有很多不同型別的CPU支援同樣的指令集，例如Intel和AMD的x86-64，ARM中用到的Thumb-2等，我們可以把這套指令集叫做機器語言，就是一些個0和1的組合，如果不考慮開發難易程度和效率，最適合寫作業系統的應該是機器語言。
在有了機器語言之後，因為太複雜而又晦澀難懂，就出現了組合語言，組合語言相當於是把指令集給起了一個名字，透過特定的編譯器，可以把組合語言轉化為對應的機器語言，也就是CPU能夠識別並執行的指令集，因此，組合語言也是可以用來寫作業系統的。組合語言其實和機器語言之間幾乎可以畫上等號了，所有指令（不包括偽指令）都與CPU的指令集對應（所以一般情況下，相對於開發其他高階語言的編譯器，開發組合語言的編譯器是“比較簡單”的工作）。
後來，又出現了Fortran、Pascal、C等語言。而C語言應該是最接近彙編的語言，可能沒有之一，學過彙編之後再去學習C，會發現很多C的資料型別和結構等，例如陣列，指標等，都能夠在彙編中找到對應的定址方法，C語言中的下標從0開始，個人覺得這也是受到彙編的影響。另外，C語言比較容易書寫，例如一個迴圈或者過程，你在彙編中要留意使用到了哪些暫存器、堆疊、甚至PSW等，要保護現場，之後還要恢復現場，保持堆疊平衡等等，稍不留神就會帶來問題，然後就是坑爹的除錯。但是用C語言一個for迴圈，或者一個函式，能省去彙編中很多枯燥麻煩而又容易出錯的工作。如果有興趣，可以試著反編譯一下現代C編譯器（例如gcc）產生的目標檔案，會發現其生成的程式碼和手工寫彙編的程式碼具有相當的指令條數和指令週期，在開啟某些高階選項時，還能利用CPU較新的指令，例如條件傳遞（cmov）等，提升程式的執行效率，因此用C語言開發一個作業系統是很自然的事情。
因此，寫作業系統可以用機器語言，也可以用匯編和C。
雖然說用匯編和C開發作業系統是順其自然的事情，但是說只能用C語言和彙編開發作業系統肯定是不正確的，竊以為，所有能夠生成對應硬體平臺的CPU指令集的語言，都是可以用來開發作業系統的，但是還是會涉及到行業生態環境、相容性、難易程度等多方面的問題，而且目前的幾個作業系統，如UNIX，Windows、Linux等都是用C語言開發的，所以自然而然地這個就成了業界“潛規則”了，而且在拋開演算法和資料結構的差異下，C語言的速度幾乎是最快的了，在某種程度上，透過進行構造的語句和編譯器最佳化，在某種程度上甚至和彙編已經不相上下，雖然C的語法容易帶來quick & dirty的效果，但是對於精通C語言的人來說，這正是C的美妙之處。假設，我們現在有C#語言，其實這種支援.NET的語言會被編譯為中間語言（IL），假如我們開發出一款能將中間語言作為其組合語言，甚至是指令集的CPU的話，那麼.NET程式的開發和執行會更加迅速。
作業系統我是沒寫過的，但是我用C語言和組合語言給C51、AVR、STM32等寫了很多的程式， 談點自己的看法。
使用何種語言寫作業系統，很大一部分原因是受到目標平臺硬體的影響，或者更準確地說，是CPU的影響，可以謹慎地講，語言的本質是指令集，而指令集是物理電路的抽象。因此，一個特定的CPU肯定對應了一套特定的指令集，當然考慮到相容性等因素，也有很多不同型別的CPU支援同樣的指令集，例如Intel和AMD的x86-64，ARM中用到的Thumb-2等，我們可以把這套指令集叫做機器語言，就是一些個0和1的組合，如果不考慮開發難易程度和效率，最適合寫作業系統的應該是機器語言。
在有了機器語言之後，因為太複雜而又晦澀難懂，就出現了組合語言，組合語言相當於是把指令集給起了一個名字，透過特定的編譯器，可以把組合語言轉化為對應的機器語言，也就是CPU能夠識別並執行的指令集，因此，組合語言也是可以用來寫作業系統的。組合語言其實和機器語言之間幾乎可以畫上等號了，所有指令（不包括偽指令）都與CPU的指令集對應（所以一般情況下，相對於開發其他高階語言的編譯器，開發組合語言的編譯器是“比較簡單”的工作）。
後來，又出現了Fortran、Pascal、C等語言。而C語言應該是最接近彙編的語言，可能沒有之一，學過彙編之後再去學習C，會發現很多C的資料型別和結構等，例如陣列，指標等，都能夠在彙編中找到對應的定址方法，C語言中的下標從0開始，個人覺得這也是受到彙編的影響。另外，C語言比較容易書寫，例如一個迴圈或者過程，你在彙編中要留意使用到了哪些暫存器、堆疊、甚至PSW等，要保護現場，之後還要恢復現場，保持堆疊平衡等等，稍不留神就會帶來問題，然後就是坑爹的除錯。但是用C語言一個for迴圈，或者一個函式，能省去彙編中很多枯燥麻煩而又容易出錯的工作。如果有興趣，可以試著反編譯一下現代C編譯器（例如gcc）產生的目標檔案，會發現其生成的程式碼和手工寫彙編的程式碼具有相當的指令條數和指令週期，在開啟某些高階選項時，還能利用CPU較新的指令，例如條件傳遞（cmov）等，提升程式的執行效率，因此用C語言開發一個作業系統是很自然的事情。
因此，寫作業系統可以用機器語言，也可以用匯編和C。
雖然說用匯編和C開發作業系統是順其自然的事情，但是說只能用C語言和彙編開發作業系統肯定是不正確的，竊以為，所有能夠生成對應硬體平臺的CPU指令集的語言，都是可以用來開發作業系統的，但是還是會涉及到行業生態環境、相容性、難易程度等多方面的問題，而且目前的幾個作業系統，如UNIX，Windows、Linux等都是用C語言開發的，所以自然而然地這個就成了業界“潛規則”了，而且在拋開演算法和資料結構的差異下，C語言的速度幾乎是最快的了，在某種程度上，透過進行構造的語句和編譯器最佳化，在某種程度上甚至和彙編已經不相上下，雖然C的語法容易帶來quick & dirty的效果，但是對於精通C語言的人來說，這正是C的美妙之處。假設，我們現在有C#語言，其實這種支援.NET的語言會被編譯為中間語言（IL），假如我們開發出一款能將中間語言作為其組合語言，甚至是指令集的CPU的話，那麼.NET程式的開發和執行會更加迅速。