IT之家 9 月 12 日消息，有IT之家網友發現，深度開源社區之前已經在 Github 和 gitee 公布了旗下自研程式語言 ——Unilang，同時還包括相關解釋器，講解了 Unilang 文檔和參考實現方式。
官方在庫中的描述是「新程式語言」，是「為適應更有效和靈活開發桌面環境應用的提出的通用目的程式語言項目」，旨在更好地幫助當前桌面應用開發者，宿主環境為 MSYS2 MinGW32 和 Linux。
據介紹，深度團隊由於 C / C++、ECMAScript 等最流行的一些標準化語言具有沉重的歷史包袱，且不具有足夠擴展語言自身的能力以兼顧其需求；Dart 等專為類似方案設計的語言在一些基本設計上的決策（如依賴全局 GC ）使之無法完全適合一些重要場景；其它的一些通用目的語言，如 Rust 和 Go ，並沒有配套提出 GUI 解決方案。
因此，他們希望在能滿足需求的基礎上，帶來一種新的語言，使它能以更深刻的方式真正地實現通用性 —— 通過減少為個別問題領域準備的原生的特設的 (ad-hoc) 特性，而以更普遍的基本特性集取而代之的方式。
Unilang 是為了統籌解決現有不足的新的方案中的語言部分，主要特色有：
作為動態語言，提供相對其它語言更強的語言層次上的可擴展性。
通過用戶定製語言的功能，可以有效限制非預期的動態特性，最終得到和大多數靜態語言接近的開發體驗上的優勢，同時避免靜態語言核心規則帶來的不便。
允許在已部署 Unilang 程序的環境中通過添加庫補全現有語言特性，而不需要重新部署工具鏈的實現。
提供一個基礎語言，並以庫的形式擴展這個語言而得到實用的特性集。庫預期由本項目和用戶提供。
大多數語言中需要修改語言核心規則提供的特性，在 Unilang 中預期只需要用戶使用 Unilang 語言編寫的庫解決，例如靜態類型檢查可以通過用戶程序提供。
類似 C 和 C++ 而不同於 Java ，不明確要求或假定翻譯和執行的具體形式。實現使用編譯、解釋和何種映像格式加載等實現細節對核心語言規則透明。
不預設如 C 和 C++ 那樣明確的翻譯階段 (phases of translation) 。不需要單獨階段展開的宏 —— 配合支持一等環境的函數即可取代宏。
支持同像性 (homoiconicity) ，允許代碼即數據 (code as data) 的方式編程。
函數是一等對象 (first-class object) 。
環境 (environment) 對變量綁定具有所有權。支持作為一等對象的一等環境 (first-class environment) 。
支持類似 C++ 的對象模型和（當前不被檢查的）不安全所有權語義。
和 C# 或 Rust 等不同，不提供一種特設的 unsafe 關鍵字標記「不安全」的代碼段落，最基礎的特性默認是「不安全」的。
安全性並非由語言唯一地定義，允許用戶通過擴展類型系統等方式實現自定義的不同種和程度的安全性。
不要求全局 GC ，同時語言的一個子集允許和 C++ 同等層次的「不安全」但能確保確定性的資源分配。
沒有原生提供針對不安全操作的靜態檢查，但是語言的可擴展性允許直接實現類型系統或者自動證明更強的內存安全。未來可能作為庫一併提供。
語言規則仍然允許引入依賴 GC 的互操作。特別地，允許引入多個非全局的 GC 示例。
支持正式意義上的 PTC ，而不需要用戶程序內對棧溢出等未定義行為進行變通。
主流語言中，沒有依賴全局 GC 的語言實現都沒有提供類似的保證。
使用隱式的潛在類型 (latent typing) 而非顯式的清單類型 (manifest typing) 。
在擴展前，作為實現細節，已允許蘊含類型推斷 (type inference) 消除一些類型檢查而不影響程序語義。
允許用戶程序擴展類型標註 (type annotation) 的語法和相關檢查。
這自然地避免用戶擴展的類型系統和原生規則衝突，而保持可擴展性。
表達式和 C++ 類似但略有不同的值類別 (value category) ；但和 C++ 不同，不是靜態確定的表達式的屬性，而是跟隨對象的動態元數據。
類似 C++ 的 const 類型限定符，通過左值引用的對象允許標記為不可修改（只讀），而不是如 Rust 等語言默認約定值不可變 (immutable) 。
類似 C++ 的消亡值 (xvalue) ，通過左值引用的對象允許標記唯一，而允許其中的資源被轉移。
原理 以上代表性的選型決策中，一個共通的方法是比較不同方向的擴展之間的技術可行性 —— 並選取容易擴展的選項。否則，即便可行，也有許多本應避免的無效的工作。
因此，語言首先要求 PTC 以使其實現有足夠的可用性，而不鼓勵嵌套的不可靠的實現。
注意對 PTC 不可靠的實現方式在其它方面仍可能很成功（如翻譯 ECMAScript 方言的 Babel ）。因此，大多數其它特性並沒有（也不需要有）如 PTC 需要基本規則明確擔保的地位。
因此，語言首先排除對全局 GC 的依賴。
例如，用 unsafe 等特設語法標記「不安全」的語言中，通常會放棄語言定義的任意安全保證，而不能選擇保留其中的一部分。即便忽略這個問題，語言也缺乏機制允許用戶提供更嚴格的保證。
再如，默認不可變的數據結構雖然能保證 const correctness 這樣的「正確性」（一種保持被限定的不可變性質不被丟棄的類型安全性 (type safety)），卻忽略對「不可變」的定義描述不充分而不能讓用戶程序擴展的問題 —— 很多情形下，不可變僅僅需要是一種等價關係，而並非不可修改。
因此，基礎語言默認是不安全的。
若語言允許用戶表達「一些具有不同表示的值被視為等價」，則優化的適應性會自然地擴展。
這蘊含不可變性只有一種，除非修改類型系統設計，放棄原有的不可變定義並重新引入類似 C++ const 的限定符機制（「更困難」的情形）。
這裡用 const_cast 這樣的不安全轉換取消 const 引入的類型安全保證並自行假定不會破壞不可變性，是個無奈的變通（「更困難」的情形，且無法恢復類型安全性而效果更差）。
這可能導致具體的不可修改性被濫用，例如 C++ 標準庫關聯容器的鍵類型實際上不需要符合 C++ 的 const ，因為鍵的不可變確切地由比較關係導出的等價關係定義，但類型系統無法區別兩種情形。這過度地限制了鍵上的本應允許的操作。
默認不可變的類型系統，如 Rust 的設計，則更根本地在類型組合構造上阻止了擴展的方向。
這也限制了現有的實現的常量傳播 (const propagation) 的優化範圍，因為原則上這裡的「常量」只關心替換能保持變換前後的語義等價性 (semantic-preserving) ，而不在意具體的值是否相等。
因此，基礎語言中的對象默認可變。
因此，基礎語言首先被設計為動態語言。
設計一個靜態語言，然後添加一些規則把它偽裝成具有足夠動態特性的動態語言，遠遠難於在動態語言上添加規則而得到靜態語言的特性集。
從一個標記放棄某種保證的上下文中添加證明恢復某種保證（且不和其它保證衝突），比從一個已知不具有保證的上下文添加證明以確保保證更困難。
在一個已經要求全局 GC 的語言中排除 GC ，遠遠難於在不依賴 GC 的語言規則基礎上添加和 GC 交互的能力（特別是 GC 允許用戶定製時）。
在一個沒有 PTC 保證的語言實現中添加擴展基本是不可行的，除非重新實現最核心的求值規則在內的邏輯（例如，再添加一個執行引擎）。
和 C++ 具有良好的互操作性。
當前解釋器（運行時）使用 C++ 實現。
結合對象模型，能確保 Unilang 對象和 C++ 對象的對應。
語言綁定主要關注已知 ABI 的 C / C++ API 。
為保持通用性，Unilang 不內建提供 GUI 功能，而通過庫提供相關 API 。當前計劃中，Unilang 將會支持基於 Qt 的綁定的庫，以便銜接過渡現有的一些桌面應用項目。Unilang 的語言設計保持足夠的抽象能力和可擴展性，允許在未來直接實現 GUI 框架。