存在一種完美的編程語言嗎？
存在一種完美的編程語言嗎？
Rust 語言因其并發(fā)安全性而深受眾多開發(fā)者的喜愛，曾在多個(gè)榜單上獲評(píng)最受歡迎編程語言。然而，現(xiàn)在有人花費(fèi)大量時(shí)間編寫 10 萬行 Rust 代碼之后，撰寫博客闡明 Rust 語言的一系列缺點(diǎn)，以下是博客的主要內(nèi)容。 我深入研究 Rust 是為了改進(jìn)由 Xobs 編寫的 Xous 操作系統(tǒng)。Xous 是一個(gè)用純 Rust 編寫的微內(nèi)核消息傳遞操作系統(tǒng)，是為了輕量級(jí) (IoT / 嵌入式規(guī)模) 的安全優(yōu)先平臺(tái)（例如 Precursor）而編寫的，用于 MMU 的硬件強(qiáng)制型頁面級(jí)內(nèi)存保護(hù)。
一年來，我們?yōu)?Xous 操作系統(tǒng)添加了許多功能，包括網(wǎng)絡(luò) (TCP/UDP/DNS)、用于模態(tài)和多語言文本的中間件圖形抽象、存儲(chǔ)（以加密的形式）、PDDB、可信啟動(dòng)（trusted boot）以及密鑰管理庫等。
我們決定編寫自己的操作系統(tǒng)而不是使用 SeL4、Tock、QNX 或 Linux 等現(xiàn)有實(shí)現(xiàn)，是因?yàn)槲覀兿胝嬲嗽O(shè)備中每一行代碼都在做什么。特別是對(duì)于 Linux，它的源代碼庫非常龐大且動(dòng)態(tài)，即使開源，也不可能搞清其內(nèi)核中的每一行代碼。
因此，Xous 僅支持我們的平臺(tái)，以盡可能避免內(nèi)核不必要的復(fù)雜性。 這樣減少應(yīng)用范圍還意味著我們還可以充分利用 CPU 在 FPGA 中運(yùn)行的優(yōu)勢(shì) 。因此，Xous 以一種不尋常的 RV32-IMAC 配置為目標(biāo)：具有 MMU + AES 擴(kuò)展的配置。 FPGA 意味著我們有能力在硬件級(jí)別上修復(fù) API 錯(cuò)誤，從而使內(nèi)核更加精簡(jiǎn)。
這對(duì)于從 RAM 中處理諸如掛起和恢復(fù)之類的抽象破壞（abstraction-busting）進(jìn)程尤其重要。 我們創(chuàng)建 Xous 時(shí)研究了大量的系統(tǒng)編程語言，最終 Rust 脫穎而出。當(dāng)時(shí)它剛剛開始支持 `no-std`，它的特點(diǎn)是強(qiáng)類型、內(nèi)存安全，具有良好的工具和新型生態(tài)系統(tǒng)。我個(gè)人是強(qiáng)類型語言的忠實(shí)擁護(hù)者，而內(nèi)存安全性不僅有利于系統(tǒng)編程，還能使優(yōu)化器更好地生成代碼，并且 Rust 適用于并發(fā)。
實(shí)際上，我希望 Precursor 有一個(gè)支持標(biāo)記指針和內(nèi)存功能的 CPU，類似于 CHERI。于是我們和 CHERI 研發(fā)團(tuán)隊(duì)進(jìn)行了一些討論，但顯然他們非常專注于 C 語言，也沒有足夠的帶寬來支持 Rust。
總體而言，C 比 Rust 需要 CHERI 多得多，他們的選擇是符合資源優(yōu)先原則的。我們不使用 C 語言，但出于安全性考慮，我希望有一天 Rust 中會(huì)存在硬件強(qiáng)制型胖指針（fat pointer）。
然而，Rust 語言絕不是完美的，甚至給我們的開發(fā)帶來了很多問題。下面我列舉一下 Rust 的缺點(diǎn)。
語法混亂復(fù)雜
我發(fā)現(xiàn) Rust 語法密集、繁重且難以閱讀，例如：
再比如，Rust 宏的可讀性也存在問題——即使是我自己編寫的一些 Rust 宏也「只是勉強(qiáng)工作」。
一種可靠的語言不應(yīng)該存在這些語法問題。 Rust 的確很強(qiáng)大，它的標(biāo)準(zhǔn)庫中包含 HashMaps、Vecs 和 Threads 等數(shù)據(jù)結(jié)構(gòu)，豐富且可用性高。然而，Rust 的「std」庫并沒有為我們構(gòu)建可審計(jì)的代碼庫帶來任何好處。
Rust 不夠完善
我們編寫 Xous 的代碼時(shí)，引入了一個(gè)叫作「const generic」的新類型。在此之前，Rust 沒有原生能力來處理多于 32 個(gè)元素的數(shù)組，這個(gè)限制令人抓狂。 在編寫 Xous 的過程中，Rust 的內(nèi)聯(lián)匯編、工作空間等功能逐漸成熟，這意味著我們需要重新審視已經(jīng)寫好的代碼，以使關(guān)鍵的初始啟動(dòng)代碼集成進(jìn)我們構(gòu)建的系統(tǒng)。
Xous 開發(fā)的第一年都是使用’no-std’完成的，代價(jià)是占用大量?jī)?nèi)存空間且復(fù)雜性高。盡管可以編寫一個(gè)只有預(yù)先分配的、靜態(tài)大小的數(shù)據(jù)結(jié)構(gòu)的操作系統(tǒng)，但為了適應(yīng)最壞情況下的元素?cái)?shù)量，因此我們不得不推出一些自己的數(shù)據(jù)結(jié)構(gòu)。 大約一年前，Xobs 將 Rust 的 `std` 庫移植到 Xous，這意味著我們可以在穩(wěn)定的 Rust 中訪問堆，現(xiàn)在 Xous 與特定版本的 Rust 綁定。 `std` 庫從根本上將內(nèi)存分配、線程創(chuàng)建等「不安全」的硬件結(jié)構(gòu)轉(zhuǎn)變成了「安全」的 Rust 結(jié)構(gòu)。
然而，我必須不斷提醒自己，擁有 `std` 庫并不能消除關(guān)鍵代碼中的安全漏洞風(fēng)險(xiǎn)——它只是將許多關(guān)鍵代碼移動(dòng)到標(biāo)準(zhǔn)庫中。 Rust 有固定的更新周期，這意味著我們也必須定期更新 Xous ，以保持與語言的兼容性。 但這可能是不可持續(xù)的。
最終，我們需要鎖定代碼庫，但我沒有明確的退出策略。也許我們可以考慮仍然使用 `no-std` 以獲得穩(wěn)定的 `alloc` 功能來訪問堆。但這樣我們就還需要使用 Vec、HashMap、Thread 和 Arc/Mutex/Rc/RefCell/Box 構(gòu)造等，以使 Xous 能夠被有效編碼。
Rust 在供應(yīng)鏈安全方面堪憂
在 rustup.rs 安裝文件中有如下代碼：
Crates.io 也存在一種拼寫錯(cuò)誤，很難確定哪些 crate 是好或壞；一些完全按照用戶想要的名稱命名的 crate 放棄提供所需功能，而積極維護(hù)的 crate 必須采用不太直觀的名稱。當(dāng)然，這不是 Rust 獨(dú)有的問題。 還有一個(gè)事實(shí)是，依賴項(xiàng)是鏈?zhǔn)降?。也就是說當(dāng)你從 crates.io 拉入一個(gè)東西時(shí)，你也會(huì)拉入該 crate 的所有從屬依賴項(xiàng)，以及它們所有的 build.rs (http://build.rs/) 腳本，這些最終都將在你的機(jī)器上運(yùn)行。
因此，僅審核 Cargo.toml 文件中明確指定的 crate 是不夠的——您還必須審核所有相關(guān) crate 是否存在潛在的供應(yīng)鏈攻擊。 幸運(yùn)的是，Rust 確實(shí)允許您使用 Cargo.lock 文件將 crate 固定在特定版本，并且可以完全指定依賴 crate 。我們?cè)噲D在 Xous 中通過發(fā)布 Cargo.lock 文件并將我們所有的一階相關(guān) crate 指定為次要修訂的策略來緩解這個(gè)問題。
然而，我們的大部分調(diào)試和測(cè)試框架都依賴于一些相當(dāng)花哨和復(fù)雜的 crate，這些 crate 引入了大量的依賴項(xiàng)，即使我嘗試為我們的目標(biāo)硬件運(yùn)行構(gòu)建，在主機(jī)上運(yùn)行的依賴 crate 和 build.rs 腳本還是被構(gòu)建。 針對(duì)這個(gè)問題，我編寫了一個(gè)名為「crate-scraper」的小工具，它為我們的 Cargo.toml 文件中指定的每個(gè)源下載源包，并且將它們存儲(chǔ)在本地，這樣我們就可以獲得用于構(gòu)建 Xous 版本的代碼快照。
它還運(yùn)行一個(gè)快速的「分析」程序——搜索名為 build.rs 的文件并將它們整理到一個(gè)文件中，這樣我就可以更快地通過 grep 查找明顯的問題。
當(dāng)然，手動(dòng)審查并不是檢測(cè)嵌入在 build.rs (http://build.rs/) 文件中巧妙偽裝的惡意軟件的實(shí)用方法，但它至少讓我了解了我們正在處理的攻擊面的規(guī)模。令人驚訝的是，我們審查出來自各種第三方的大約 5700 行代碼，用于操作文件、目錄和環(huán)境變量，并在我的計(jì)算機(jī)上運(yùn)行其他程序。 我不確定這個(gè)問題是否有更好的解決方案，但是，如果你的目標(biāo)是構(gòu)建可信賴的固件，請(qǐng)警惕 Rust 廣泛的軟件供應(yīng)鏈攻擊面。
無法復(fù)現(xiàn)別人的 Rust 構(gòu)建
我對(duì) Rust 的最后一點(diǎn)看法是，一臺(tái)計(jì)算機(jī)上的構(gòu)建無法在另一臺(tái)上復(fù)現(xiàn)。我認(rèn)為這主要是因?yàn)?Rust 將源代碼的完整路徑作為內(nèi)置到二進(jìn)制文件中調(diào)試字符串的一部分。
這導(dǎo)致了一些糟糕的情況，例如我們?cè)?Windows 上構(gòu)建的工作成功了，但在 Linux 下卻失敗了，因?yàn)槎叩穆窂矫浅２煌@會(huì)導(dǎo)致一些內(nèi)存對(duì)象在目標(biāo)內(nèi)存中被轉(zhuǎn)移。 公平地講，這些失敗是由于 Xous 中存在錯(cuò)誤，這些錯(cuò)誤已經(jīng)得到修復(fù)。
但是，最終仍會(huì)有用戶向我們報(bào)告我們無法復(fù)現(xiàn)，因?yàn)樗麄冊(cè)跇?gòu)建系統(tǒng)上的路徑與我們的不同。
最后，我想說盡管這里列出了所有的怨言，但如果能重來，Rust 仍然是我們用于構(gòu)建 Xous 所用語言的有力競(jìng)爭(zhēng)者。我用 C、Python 和 Java 完成了很多大型項(xiàng)目，所有這些項(xiàng)目最終都背負(fù)著「不斷增加的技術(shù)債務(wù)」，而 Rust 可以規(guī)避這些問題。
審核編輯 ：李倩
Rust 語言因其并發(fā)安全性而深受眾多開發(fā)者的喜愛，曾在多個(gè)榜單上獲評(píng)最受歡迎編程語言。然而，現(xiàn)在有人花費(fèi)大量時(shí)間編寫 10 萬行 Rust 代碼之后，撰寫博客闡明 Rust 語言的一系列缺點(diǎn)，以下是博客的主要內(nèi)容。 我深入研究 Rust 是為了改進(jìn)由 Xobs 編寫的 Xous 操作系統(tǒng)。Xous 是一個(gè)用純 Rust 編寫的微內(nèi)核消息傳遞操作系統(tǒng)，是為了輕量級(jí) (IoT / 嵌入式規(guī)模) 的安全優(yōu)先平臺(tái)（例如 Precursor）而編寫的，用于 MMU 的硬件強(qiáng)制型頁面級(jí)內(nèi)存保護(hù)。
一年來，我們?yōu)?Xous 操作系統(tǒng)添加了許多功能，包括網(wǎng)絡(luò) (TCP/UDP/DNS)、用于模態(tài)和多語言文本的中間件圖形抽象、存儲(chǔ)（以加密的形式）、PDDB、可信啟動(dòng)（trusted boot）以及密鑰管理庫等。
我們決定編寫自己的操作系統(tǒng)而不是使用 SeL4、Tock、QNX 或 Linux 等現(xiàn)有實(shí)現(xiàn)，是因?yàn)槲覀兿胝嬲嗽O(shè)備中每一行代碼都在做什么。特別是對(duì)于 Linux，它的源代碼庫非常龐大且動(dòng)態(tài)，即使開源，也不可能搞清其內(nèi)核中的每一行代碼。
因此，Xous 僅支持我們的平臺(tái)，以盡可能避免內(nèi)核不必要的復(fù)雜性。 這樣減少應(yīng)用范圍還意味著我們還可以充分利用 CPU 在 FPGA 中運(yùn)行的優(yōu)勢(shì) 。因此，Xous 以一種不尋常的 RV32-IMAC 配置為目標(biāo)：具有 MMU + AES 擴(kuò)展的配置。 FPGA 意味著我們有能力在硬件級(jí)別上修復(fù) API 錯(cuò)誤，從而使內(nèi)核更加精簡(jiǎn)。
這對(duì)于從 RAM 中處理諸如掛起和恢復(fù)之類的抽象破壞（abstraction-busting）進(jìn)程尤其重要。 我們創(chuàng)建 Xous 時(shí)研究了大量的系統(tǒng)編程語言，最終 Rust 脫穎而出。當(dāng)時(shí)它剛剛開始支持 `no-std`，它的特點(diǎn)是強(qiáng)類型、內(nèi)存安全，具有良好的工具和新型生態(tài)系統(tǒng)。我個(gè)人是強(qiáng)類型語言的忠實(shí)擁護(hù)者，而內(nèi)存安全性不僅有利于系統(tǒng)編程，還能使優(yōu)化器更好地生成代碼，并且 Rust 適用于并發(fā)。
實(shí)際上，我希望 Precursor 有一個(gè)支持標(biāo)記指針和內(nèi)存功能的 CPU，類似于 CHERI。于是我們和 CHERI 研發(fā)團(tuán)隊(duì)進(jìn)行了一些討論，但顯然他們非常專注于 C 語言，也沒有足夠的帶寬來支持 Rust。
總體而言，C 比 Rust 需要 CHERI 多得多，他們的選擇是符合資源優(yōu)先原則的。我們不使用 C 語言，但出于安全性考慮，我希望有一天 Rust 中會(huì)存在硬件強(qiáng)制型胖指針（fat pointer）。
然而，Rust 語言絕不是完美的，甚至給我們的開發(fā)帶來了很多問題。下面我列舉一下 Rust 的缺點(diǎn)。
語法混亂復(fù)雜
我發(fā)現(xiàn) Rust 語法密集、繁重且難以閱讀，例如：
Trying::<&'aheavy>(syntax,|like|{this.can_be(maddening)}).map(|_|())?;
簡(jiǎn)單來說，上面的代碼類似于在對(duì)象（實(shí)際上是 `struct`）上調(diào)用一個(gè)名為「to_read」的方法。 還有一種不遵循 Rust 語法規(guī)則的宏和指令也能運(yùn)行：
#[cfg(all(not(baremetal),any(feature=“hazmat”,feature=“debug_print”)))]
上面的語句中最令我困惑的是使用‘=’來表示等價(jià)而不是賦值，因?yàn)榕渲弥噶钪械膬?nèi)容不是 Rust 代碼，它就像一個(gè)完全獨(dú)立的元語言。再比如，Rust 宏的可讀性也存在問題——即使是我自己編寫的一些 Rust 宏也「只是勉強(qiáng)工作」。
一種可靠的語言不應(yīng)該存在這些語法問題。 Rust 的確很強(qiáng)大，它的標(biāo)準(zhǔn)庫中包含 HashMaps、Vecs 和 Threads 等數(shù)據(jù)結(jié)構(gòu)，豐富且可用性高。然而，Rust 的「std」庫并沒有為我們構(gòu)建可審計(jì)的代碼庫帶來任何好處。
Rust 不夠完善
我們編寫 Xous 的代碼時(shí)，引入了一個(gè)叫作「const generic」的新類型。在此之前，Rust 沒有原生能力來處理多于 32 個(gè)元素的數(shù)組，這個(gè)限制令人抓狂。 在編寫 Xous 的過程中，Rust 的內(nèi)聯(lián)匯編、工作空間等功能逐漸成熟，這意味著我們需要重新審視已經(jīng)寫好的代碼，以使關(guān)鍵的初始啟動(dòng)代碼集成進(jìn)我們構(gòu)建的系統(tǒng)。
Xous 開發(fā)的第一年都是使用’no-std’完成的，代價(jià)是占用大量?jī)?nèi)存空間且復(fù)雜性高。盡管可以編寫一個(gè)只有預(yù)先分配的、靜態(tài)大小的數(shù)據(jù)結(jié)構(gòu)的操作系統(tǒng)，但為了適應(yīng)最壞情況下的元素?cái)?shù)量，因此我們不得不推出一些自己的數(shù)據(jù)結(jié)構(gòu)。 大約一年前，Xobs 將 Rust 的 `std` 庫移植到 Xous，這意味著我們可以在穩(wěn)定的 Rust 中訪問堆，現(xiàn)在 Xous 與特定版本的 Rust 綁定。 `std` 庫從根本上將內(nèi)存分配、線程創(chuàng)建等「不安全」的硬件結(jié)構(gòu)轉(zhuǎn)變成了「安全」的 Rust 結(jié)構(gòu)。
然而，我必須不斷提醒自己，擁有 `std` 庫并不能消除關(guān)鍵代碼中的安全漏洞風(fēng)險(xiǎn)——它只是將許多關(guān)鍵代碼移動(dòng)到標(biāo)準(zhǔn)庫中。 Rust 有固定的更新周期，這意味著我們也必須定期更新 Xous ，以保持與語言的兼容性。 但這可能是不可持續(xù)的。
最終，我們需要鎖定代碼庫，但我沒有明確的退出策略。也許我們可以考慮仍然使用 `no-std` 以獲得穩(wěn)定的 `alloc` 功能來訪問堆。但這樣我們就還需要使用 Vec、HashMap、Thread 和 Arc/Mutex/Rc/RefCell/Box 構(gòu)造等，以使 Xous 能夠被有效編碼。
Rust 在供應(yīng)鏈安全方面堪憂
在 rustup.rs 安裝文件中有如下代碼：
`curl--proto'=https'--tlsv1.2-sSfhttps://sh.rustup.rs|sh`
用戶可以下載腳本并在運(yùn)行之前對(duì)其進(jìn)行檢查，這似乎比 vscode 的 Windows .MSI 安裝程序好得多。但是，這種做法遍及整個(gè)構(gòu)建生態(tài)系統(tǒng)，讓我對(duì)通過 crates.io 生態(tài)系統(tǒng)發(fā)起的軟件供應(yīng)鏈攻擊的可能性感到不安。 Crates.io 也存在一種拼寫錯(cuò)誤，很難確定哪些 crate 是好或壞；一些完全按照用戶想要的名稱命名的 crate 放棄提供所需功能，而積極維護(hù)的 crate 必須采用不太直觀的名稱。當(dāng)然，這不是 Rust 獨(dú)有的問題。 還有一個(gè)事實(shí)是，依賴項(xiàng)是鏈?zhǔn)降?。也就是說當(dāng)你從 crates.io 拉入一個(gè)東西時(shí)，你也會(huì)拉入該 crate 的所有從屬依賴項(xiàng)，以及它們所有的 build.rs (http://build.rs/) 腳本，這些最終都將在你的機(jī)器上運(yùn)行。
因此，僅審核 Cargo.toml 文件中明確指定的 crate 是不夠的——您還必須審核所有相關(guān) crate 是否存在潛在的供應(yīng)鏈攻擊。 幸運(yùn)的是，Rust 確實(shí)允許您使用 Cargo.lock 文件將 crate 固定在特定版本，并且可以完全指定依賴 crate 。我們?cè)噲D在 Xous 中通過發(fā)布 Cargo.lock 文件并將我們所有的一階相關(guān) crate 指定為次要修訂的策略來緩解這個(gè)問題。
然而，我們的大部分調(diào)試和測(cè)試框架都依賴于一些相當(dāng)花哨和復(fù)雜的 crate，這些 crate 引入了大量的依賴項(xiàng)，即使我嘗試為我們的目標(biāo)硬件運(yùn)行構(gòu)建，在主機(jī)上運(yùn)行的依賴 crate 和 build.rs 腳本還是被構(gòu)建。 針對(duì)這個(gè)問題，我編寫了一個(gè)名為「crate-scraper」的小工具，它為我們的 Cargo.toml 文件中指定的每個(gè)源下載源包，并且將它們存儲(chǔ)在本地，這樣我們就可以獲得用于構(gòu)建 Xous 版本的代碼快照。
它還運(yùn)行一個(gè)快速的「分析」程序——搜索名為 build.rs 的文件并將它們整理到一個(gè)文件中，這樣我就可以更快地通過 grep 查找明顯的問題。
當(dāng)然，手動(dòng)審查并不是檢測(cè)嵌入在 build.rs (http://build.rs/) 文件中巧妙偽裝的惡意軟件的實(shí)用方法，但它至少讓我了解了我們正在處理的攻擊面的規(guī)模。令人驚訝的是，我們審查出來自各種第三方的大約 5700 行代碼，用于操作文件、目錄和環(huán)境變量，并在我的計(jì)算機(jī)上運(yùn)行其他程序。 我不確定這個(gè)問題是否有更好的解決方案，但是，如果你的目標(biāo)是構(gòu)建可信賴的固件，請(qǐng)警惕 Rust 廣泛的軟件供應(yīng)鏈攻擊面。
無法復(fù)現(xiàn)別人的 Rust 構(gòu)建
我對(duì) Rust 的最后一點(diǎn)看法是，一臺(tái)計(jì)算機(jī)上的構(gòu)建無法在另一臺(tái)上復(fù)現(xiàn)。我認(rèn)為這主要是因?yàn)?Rust 將源代碼的完整路徑作為內(nèi)置到二進(jìn)制文件中調(diào)試字符串的一部分。
這導(dǎo)致了一些糟糕的情況，例如我們?cè)?Windows 上構(gòu)建的工作成功了，但在 Linux 下卻失敗了，因?yàn)槎叩穆窂矫浅２煌@會(huì)導(dǎo)致一些內(nèi)存對(duì)象在目標(biāo)內(nèi)存中被轉(zhuǎn)移。 公平地講，這些失敗是由于 Xous 中存在錯(cuò)誤，這些錯(cuò)誤已經(jīng)得到修復(fù)。
但是，最終仍會(huì)有用戶向我們報(bào)告我們無法復(fù)現(xiàn)，因?yàn)樗麄冊(cè)跇?gòu)建系統(tǒng)上的路徑與我們的不同。
最后，我想說盡管這里列出了所有的怨言，但如果能重來，Rust 仍然是我們用于構(gòu)建 Xous 所用語言的有力競(jìng)爭(zhēng)者。我用 C、Python 和 Java 完成了很多大型項(xiàng)目，所有這些項(xiàng)目最終都背負(fù)著「不斷增加的技術(shù)債務(wù)」，而 Rust 可以規(guī)避這些問題。
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請(qǐng)聯(lián)系本站處理。
舉報(bào)投訴
-
cpu
+關(guān)注
關(guān)注
68文章
10863瀏覽量
211781 -
操作系統(tǒng)
+關(guān)注
關(guān)注
37文章
6825瀏覽量
123333 -
編程語言
+關(guān)注
關(guān)注
10文章
1945瀏覽量
34740
原文標(biāo)題：編寫完10萬行代碼，我發(fā)了篇長(zhǎng)文吐槽Rust
文章出處：【微信號(hào)：CVSCHOOL，微信公眾號(hào)：OpenCV學(xué)堂】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
Triton編譯器支持的編程語言
編寫和優(yōu)化深度學(xué)習(xí)代碼。Python是一種廣泛使用的高級(jí)編程語言，具有簡(jiǎn)潔易讀、易于上手、庫豐富等特點(diǎn)，非常適合用于深度學(xué)習(xí)應(yīng)用的開發(fā)。 二、領(lǐng)域特定語言（DSL） Triton也提供
編程語言的誤區(qū)與常見問題
： 選擇編程語言時(shí)，應(yīng)考慮項(xiàng)目需求、個(gè)人興趣以及語言的適用性。例如，如果你對(duì)Web開發(fā)感興趣，那么學(xué)習(xí)JavaScript可能是一個(gè)好選擇。 認(rèn)識(shí)到?jīng)]有
MCU編程語言和開發(fā)環(huán)境介紹
MCU編程語言 MCU編程語言是用于編寫MCU程序的高級(jí)編程語言，它們使得開發(fā)者能夠更高效地開
C語言與其他編程語言的比較
C語言作為一種歷史悠久的編程語言，自其誕生以來，一直在軟件開發(fā)領(lǐng)域扮演著重要角色。它以其高效、靈活和可移植性強(qiáng)的特點(diǎn)，成為了系統(tǒng)級(jí)
CNC系統(tǒng)一般可用幾種編程語言
是一種用于數(shù)控機(jī)床編程的編程語言，廣泛應(yīng)用于CNC系統(tǒng)。G代碼是一種文本格式的編程
labview是什么編程語言寫的
的一種圖形化編程語言。它并不是用傳統(tǒng)的文本編程語言（如C++、Python等）編寫的，而是采用了一種
一種無透鏡成像的新方法
使用OAM-HHG EUV光束對(duì)高度周期性結(jié)構(gòu)進(jìn)行成像的EUV聚光顯微鏡 為了研究微電子或光子元件中的納米級(jí)圖案，一種基于無透鏡成像的新方法可以實(shí)現(xiàn)近乎完美的高分辨率顯微鏡。 層析成像是一種強(qiáng)大的無
abb工業(yè)機(jī)器人的編程語言是什么
ABB工業(yè)機(jī)器人的編程語言主要是RAPID（Robot Application Programming Interface for Development），它是一種高級(jí)編程
PLC編程語言和C語言的區(qū)別
在工業(yè)自動(dòng)化和計(jì)算機(jī)編程領(lǐng)域中，PLC（可編程邏輯控制器）編程語言和C語言各自扮演著重要的角色。盡管兩者都是
cnc系統(tǒng)一般可用幾種編程語言
。CNC系統(tǒng)廣泛應(yīng)用于機(jī)械制造、汽車制造、航空航天等領(lǐng)域。 CNC系統(tǒng)的編程語言是實(shí)現(xiàn)CNC系統(tǒng)控制功能的關(guān)鍵技術(shù)之一。以下是對(duì)CNC系統(tǒng)可用編程語
verilog與其他編程語言的接口機(jī)制
Verilog是一種硬件描述語言，用于描述數(shù)字電路的行為和結(jié)構(gòu)。與其他編程語言相比，Verilog具有與硬件緊密結(jié)合的特點(diǎn)，因此其接口機(jī)制也有一
大語言模型中的語言與知識(shí)：一種神秘的分離現(xiàn)象
自然語言處理領(lǐng)域存在著一個(gè)非常有趣的現(xiàn)象：在多語言模型中，不同的語言之間似乎存在著
發(fā)表于 02-20 14:53
?526次閱讀
plc編程語言與c語言的聯(lián)系 c語言和PLC有什么區(qū)別
PLC編程語言與C語言的聯(lián)系 PLC（可編程邏輯控制器）是一種針對(duì)自動(dòng)化控制系統(tǒng)的特殊計(jì)算機(jī)。PLC編程
四種編程語言之間的區(qū)別和聯(lián)系
編程語言是一種人與計(jì)算機(jī)之間進(jìn)行交流的方式，不同的編程語言有著不同的特點(diǎn)和用途。本文將對(duì)四種常見
plc編程語言有幾種,一般常用有哪些
PLC（可編程邏輯控制器）是一種用于自動(dòng)化控制系統(tǒng)的電子設(shè)備，它使用特定的編程語言來控制和監(jiān)視機(jī)器或過程。常見的PLC編程
工商網(wǎng)監(jiān)
評(píng)論