如何分析解決過程式和純粹app的語言Golang

如何分析解決過程式和純粹app的語言Golang，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

真正的APP語言。GO正確的設計。GO真正的分布式語言

以前，我總談到編程是從xaas開始，到langsys到 domainstack到app的四棧疊加過程，語言因為平臺也有本質(zhì)上的二種：toolchain式和app式，歷史上，人們總是企圖從toolchain式語言上封裝一次，在這上面發(fā)展app語言，這使得任何一種app都有了平臺相關(guān)性，這種相關(guān)性或是CPU架構(gòu)，OS的，或是toolchain libc。所以才會有那些移殖性的討論和軟件虛擬機語言（它們將平臺重新發(fā)明了一次，以封裝相異）和實現(xiàn)品，并在這上面長足發(fā)展了很多開發(fā)理念和實踐。

在《bcxszy》的語言選型上，我們一直在尋找一種包含四棧卻又不致于斷層設計的語言體系，我們從.net,java,到qtcpp,llvm cling,terralang,再到lua,js,python，這些。我們認為但凡是編程，總免不了要從xaas開始。

但其實這是不對的，app和hosting居然是可以分離的！純粹的toolchain編程和pure app編程是有區(qū)別的，基于前者的應用編程有四棧，但基于后者的只有三棧，因為，存在一種app和app開發(fā)生態(tài)，它是可以沒有任何平臺依托而存在的。無runtime設計，無backend to any hd, os,libc設計。

這就是go。它是真正的APP語言。

Go的設計級優(yōu)點:真正脫離平臺的APP語言

比起.net/java這種，c family based,llvm based語言，go對平臺沒有任何必須要依賴的邏輯，是完全問題域開始的。最通用的情況來講，基本上在c family式語言中，為了對接上toolchain langsys的成果，x86上的for app高級語言(及它們產(chǎn)生的任何程序)，都會直接或間接引用到glibc這種運行時，因為程序設計，必須不是個重造輪子的過程。一些基于llvm的語言，封裝c dlls形成自己的語言庫，這種技術(shù)在llvm出現(xiàn)后更流行，因為新發(fā)明的語言往往可以直接call into dll libs。——— 但其實，C系更多的是一種toolchain。而非appdev langsys，但現(xiàn)實是是很多編譯為native目標的本地語言都脫離不了它們是從toolchain生態(tài)作app programming的事實，這終究是錯誤的，而在.net/clr,jvm這類體系中，managed clr也是帶虛擬機的，這類虛擬機后端植根于某OS中，引用眾多，又巨大，雖然虛擬機上的APP是跨平臺的，但虛擬機它本身不是跨平臺的（實際也是多平臺），雖然它出現(xiàn)的目的就是為了脫離平臺，但它終究也是一種平臺依賴，都免不了與toolchain及其hosting生態(tài)綁得很緊，作某層次的引用，—— 這造成的最大現(xiàn)實就是，來自語言和平臺的依賴，使得分布式程序這個東西從源頭上變得不存在，于是在分布式開發(fā)中處處掣肘。使得本地程序和分布式根本無法割舍。

而GO（非cgo）從0開始另起灶爐，它在各個平臺的實現(xiàn)不包括運行時，而只是編輯器工具，支持面向各個平臺能直接生成APP不需要發(fā)布任何runtime，好吧，它其實也發(fā)布運行時，只是它這個運行時非常小，且集成到每一個每一個由GO產(chǎn)生的APP中。不是像java,net等所有此類APP共享的，巨大，且與OS依賴嚴重的這類運行時?！?你可以這樣理解：它的每一個可運行目標，雖然再小，里面都有一個小機器，這種小機器不是x86，也不是arm,也不是任何其它一種cpu，運行時并不需要外置另外發(fā)布，所以它免去了從硬件開始就帶來的平臺相關(guān)性。它是將四棧中的平臺集成到APP尾端的一種行為，而不是置于首端。

golang它的前身limbo所屬的os-plan9，甚至有從0開始，把kernel和系統(tǒng)調(diào)用都重做一遍的動作。它不基于x86。glibc都不用。因為glibc是從linux kernel來的,是一個rootfs最基礎的部分。因為只要工作在x86上，你就得繼承那里的成果，而GO不需要。---- 發(fā)明 plan9和limbo的那幫人實在是一幫眼光先到的家伙。

這就是真正的APP語言。是分布式開發(fā)的本質(zhì)選擇。

go的語言級優(yōu)點：只做好過程式的分布式新C規(guī)范

曾經(jīng)lua這樣的語言也很流行，因為它直面了程序設計中的痛點：x86下的過程式，都不好用。而基于過程式之上的各種OO，又過于發(fā)展得太復雜。這類語言痛點劣跡斑斑人們卻又視而不見，它們沒有一個穩(wěn)定的語言核心，它們語言技法雖顯高級而難用，用于分布式開發(fā)要拖上平臺?！?所以，可見，對于這種語言的強化或簡化需要是十分重要的。因為高級的語言技法，問題域的封裝是開發(fā)和工業(yè)中的大難題。

Lua出現(xiàn)那時，并發(fā)處理也不是很流行，分布式也不，lua用不同于CPU綁定的方式實現(xiàn)并發(fā)?？梢夾PP處理問題的方式與硬件，系統(tǒng)編程都不必相同。除非為了獲得硬件加速效果 — 這也是GO提出平臺與APP分離的依據(jù)所在。除此之外，LUA最主要的優(yōu)點在于：它比起現(xiàn)今的多種語言，短小，只專注于過程式，核心穩(wěn)定，技法緊湊，可以用較為省事的形式實現(xiàn)復雜的OO，比起那些嚴肅地從x86開始到OS到glibc的語言體系，它就是它自己，專門做lua支持下的那些有限集技術(shù)下的APP的！事到如今，類lua的語言一個個出現(xiàn)，如js,go，lua的思路也就不那么新鮮了

GO剛好也是lua一路的，只不過go vs Lua，有它從0開始的平臺無關(guān)性，而lua依然是平臺相關(guān)的那一類，所以除了那個線協(xié)程設計，它本質(zhì)上也不是適合分布式的。

所以，還有什么理由不選擇GO呢，即使單單是為了認真的做分布式開發(fā)。

看完上述內(nèi)容，你們掌握如何分析解決過程式和純粹app的語言Golang的方法了嗎？如果還想學到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！