在纷繁的快速变化中找到那些不变的东西。
编者按:Go+ 是一门以「数据科学」为靶心的通用语言。本期将开启《Inside Go+》系列文章的第一篇,讲讲 Go+ 的宏观架构。后续我们将会一步步解剖 Go+ 的实现。
今天我们将开启《Inside Go+》系列文章的第一篇,讲讲 Go+ 的宏观架构。后续我们将会一步步解剖 Go+ 的实现。
Go+ 是一门以「数据科学」为靶心的通用语言。它首先是一门通用语言,理论上你可以用它来解决绝大部分领域的问题。这一点和 Go 也很像。Go 也是一门通用语言,但以「服务端编程」为靶心。
以下是 Go+ 给人们的主要印象:
它是一门静态类型语言;
它完全兼容 Go 语言;
它看起来像脚本,在数据科学领域有着比 Go 友好得多的界面。
例如,以下是一个 Go+ 的例子:
同样功能的程序,用 Go 需要这样写:
关于 Go+ 更详细的介绍,请参考 https://github.com/goplus/gop。
下面我们话题回到 Go+ 实现的解剖。为了方便大家理解整个 Go+ 代码的组织方式,我画了下面这样一幅图:
那么,应该怎么看这幅图呢?
首先,圆角长方形代表 Go+ 处理过程中涉及的对象实体(object entity),它们包括:
Go+ 源代码(Go+ Source);
Go+ Token 流(Go+ Token);
Go+ 抽象语法树(Go+ AST);
后端接口规范(Executing Specification);
字节码(Byte Code);
Go 源代码(Go Source);
机器码形式的包或软件(Package/Software)。
后端接口规范(Executing Specification)这块比较特殊,它是一个抽象接口族构成的 DOM 树。它是一种抽象对象实体,和常规的对象实体有所区别,所以我们把它画成了特殊的形态。
整个 Go+ 处理的过程,你可以把它理解为其实只是在不同对象实体之间进行变换的过程。其中,整个变换的起点是 Go+ 源代码(Go+ Source),终点有两个分支,一个分支是字节码(Byte Code),一个分支是机器码(Package/Software)。为什么会有两个终点?因为 Go+ 是双引擎的,它既可以像脚本一样解释执行,也可以编译成机器码。
其次,蓝色加粗的文本代表我们接下来要剖析的 package,它们包括:
github.com/goplus/gop/token
github.com/goplus/gop/scanner
github.com/goplus/gop/parser
github.com/goplus/gop/ast
github.com/goplus/gop/format
github.com/goplus/gop/printer
github.com/goplus/gop/cl
github.com/goplus/gop/exec.spec
github.com/goplus/gop/exec/bytecode
github.com/goplus/gop/exec/golang
当然,这些 package 并不是 Go+ 完整的 package 列表,但它们是理解 Go+ 代码的关键,我们接下来会重点对它们进行介绍。
需要注意的一个细节是,我们有些 package 标在了对象实体(object entity)上,比如 token、ast、exec.spec。这代表这类对象实体(object entity)是通过代码表达的,具体代码就在对应的 package 中。
另一些 package 标在了箭头上,比如 scanner、parser、cl、exec/bytecode、exec/golang。这通常代表它们是负责了从一种对象实体变换为另一种对象实体。比如 scanner 负责将 Go+ Source 变换 Go+ Token,cl 负责将 Go+ AST 变换为 exec specification。但 exec/bytecode 和 exec/golang 有点特殊,它们是实现了 exec specification,然后将结果输出为 Byte Code 和 Go Source。我们统一理解为对象实体的变换也是说得通的。
最后,我们解释一下箭头指向。大部分箭头指向都是一个对象实体,这些箭头,毫无疑问,表示实体变换。标在其上的 package 就是负责变换的实现代码。但有少量箭头是指向某个 package 的,比如 Go+ Token 有箭头指向 parser,printer 包有箭头指向 format。这些指向 package 的箭头代表内部依赖。以上两个箭头,前者表示 scanner、token 这些实体和实体变换,都只是 parser 的内部过程,后者表示 format 内部依赖了 printer。
有了以上这些信息,相信你对 Go+ 整体的组织有了非常宏观的理解。更详细的内容,我们下回分解。
更多产品了解
欢迎扫码加入云巴巴企业数字化交流服务群
产品交流、问题咨询、专业测评
都在这里!



抖音算法推流核心指标是互动率而非GMV。天志互联直播抽盒系统从订单秒级上屏、一键拆盒、氛围引爆三个维度拉高互动率,驱动算法推流的正循环。

从"换皮联名"到"游戏化体验共创"——拆解彩棠敦煌联名案例的壁画修复小游戏设计逻辑、奶茶品牌联名翻车教训和中小品牌三条低成本高ROI的IP联名路径。

低代码时代品牌游戏化运营体系的"乐高式"搭建指南——从选模板、搭积分闭环、数据迭代到多活动并行管理和团队交接的全流程实操方法。

一个快消品牌用游戏化方法三个月救活240个死群的完整复盘——从签到排行榜、互动任务、习惯养成到赛季制防疲劳的六周运营节奏拆解。

游戏化社交裂变的三个底线原则深度拆解——让转发不像广告、让奖品有炫耀价值、给用户不转发的自由,加3%超级用户识别策略和三个常见翻车点避坑指南。