运维开发网

Golang,一门独立门户却又好好专注于解决过程式和纯粹app的语言

运维开发网 https://www.qedev.com 2020-10-09 11:11 出处:51CTO 作者:minlearn
本文关键字:真正的APP语言。GO正确的设计。GO真正的分布式语言以前,我总谈到编程是从xaas开始,到langsys到domainstack到app的四栈叠加过程,语言因为平台也有本质上的二种:toolchain式和app式,历史上,人们总是企图从toolchain式语言上封装一次,在这上面发展app语言,这使得任何一种app都有了平台相关性,这种相关性或是CPU架构,OS的,或是toolcha

本文关键字:真正的APP语言。GO正确的设计。GO真正的分布式语言

以前,我总谈到编程是从xaas开始,到langsys到 domainstack到app的四栈叠加过程,语言因为平台也有本质上的二种:toolchain式和app式,历史上,人们总是企图从toolchain式语言上封装一次,在这上面发展app语言,这使得任何一种app都有了平台相关性,这种相关性或是CPU架构,OS的,或是toolchain libc。所以才会有那些移殖性的讨论和软件虚拟机语言(它们将平台重新发明了一次,以封装相异)和实现品,并在这上面长足发展了很多开发理念和实践。

在《bcxszy》的语言选型上,我们一直在寻找一种包含四栈却又不致于断层设计的语言体系,我们从.net,java,到qtcpp,llvm cling,terralang,再到lua,js,python,这些。我们认为但凡是编程,总免不了要从xaas开始。

但其实这是不对的,app和hosting居然是可以分离的!纯粹的toolchain编程和pure app编程是有区别的,基于前者的应用编程有四栈,但基于后者的只有三栈,因为,存在一种app和app开发生态,它是可以没有任何平台依托而存在的。无runtime设计,无backend to any hd, os,libc设计。

这就是go。它是真正的APP语言。

Go的设计级优点:真正脱离平台的APP语言

比起.net/java这种,c family based,llvm based语言,go对平台没有任何必须要依赖的逻辑,是完全问题域开始的。最通用的情况来讲,基本上在c family式语言中,为了对接上toolchain langsys的成果,x86上的for app高级语言(及它们产生的任何程序),都会直接或间接引用到glibc这种运行时,因为程序设计,必须不是个重造轮子的过程。一些基于llvm的语言,封装c dlls形成自己的语言库,这种技术在llvm出现后更流行,因为新发明的语言往往可以直接call into dll libs。——— 但其实,C系更多的是一种toolchain。而非appdev langsys,但现实是是很多编译为native目标的本地语言都脱离不了它们是从toolchain生态作app programming的事实,这终究是错误的,而在.net/clr,jvm这类体系中,managed clr也是带虚拟机的,这类虚拟机后端植根于某OS中,引用众多,又巨大,虽然虚拟机上的APP是跨平台的,但虚拟机它本身不是跨平台的(实际也是多平台),虽然它出现的目的就是为了脱离平台,但它终究也是一种平台依赖,都免不了与toolchain及其hosting生态绑得很紧,作某层次的引用,—— 这造成的最大现实就是,来自语言和平台的依赖,使得分布式程序这个东西从源头上变得不存在,于是在分布式开发中处处掣肘。使得本地程序和分布式根本无法割舍。

而GO(非cgo)从0开始另起灶炉,它在各个平台的实现不包括运行时,而只是编辑器工具,支持面向各个平台能直接生成APP不需要发布任何runtime,好吧,它其实也发布运行时,只是它这个运行时非常小,且集成到每一个每一个由GO产生的APP中。不是像java,net等所有此类APP共享的,巨大,且与OS依赖严重的这类运行时。—— 你可以这样理解:它的每一个可运行目标,虽然再小,里面都有一个小机器,这种小机器不是x86,也不是arm,也不是任何其它一种cpu,运行时并不需要外置另外发布,所以它免去了从硬件开始就带来的平台相关性。它是将四栈中的平台集成到APP尾端的一种行为,而不是置于首端。

golang它的前身limbo所属的os-plan9,甚至有从0开始,把kernel和系统调用都重做一遍的动作。它不基于x86。glibc都不用。因为glibc是从Linux kernel来的,是一个rootfs最基础的部分。因为只要工作在x86上,你就得继承那里的成果,而GO不需要。---- 发明 plan9和limbo的那帮人实在是一帮眼光先到的家伙。

这就是真正的APP语言。是分布式开发的本质选择。

go的语言级优点:只做好过程式的分布式新C规范

曾经lua这样的语言也很流行,因为它直面了程序设计中的痛点:x86下的过程式,都不好用。而基于过程式之上的各种OO,又过于发展得太复杂。这类语言痛点劣迹斑斑人们却又视而不见,它们没有一个稳定的语言核心,它们语言技法虽显高级而难用,用于分布式开发要拖上平台。—— 所以,可见,对于这种语言的强化或简化需要是十分重要的。因为高级的语言技法,问题域的封装是开发和工业中的大难题。

Lua出现那时,并发处理也不是很流行,分布式也不,lua用不同于CPU绑定的方式实现并发。可见APP处理问题的方式与硬件,系统编程都不必相同。除非为了获得硬件加速效果 — 这也是GO提出平台与APP分离的依据所在。除此之外,LUA最主要的优点在于:它比起现今的多种语言,短小,只专注于过程式,核心稳定,技法紧凑,可以用较为省事的形式实现复杂的OO,比起那些严肃地从x86开始到OS到glibc的语言体系,它就是它自己,专门做lua支持下的那些有限集技术下的APP的!事到如今,类lua的语言一个个出现,如js,go,lua的思路也就不那么新鲜了

GO刚好也是lua一路的,只不过go vs Lua,有它从0开始的平台无关性,而lua依然是平台相关的那一类,所以除了那个线协程设计,它本质上也不是适合分布式的。

所以,还有什么理由不选择GO呢,即使单单是为了认真的做分布式开发。


我们把bcxszy的目录也明确分成了二部,第一部os/toolchain/xaas,第二部app langsys/middleware stack/devops tools,以示我们app编程不需扯上xaas和toolchain langsys,terralang c其实也不是良选。


(此处不设回复,扫码到微信参与留言,或直接点击到原文)

Golang,一门独立门户却又好好专注于解决过程式和纯粹app的语言

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号