Yak 的前世今生
Yak 语言本身并不是一个凭空出现的项目。
从企业需求中诞生：合理的引擎需求#
早在近两年，我在参与企业安全建设过程中，提出并实现了一套非常棒的企业安全平台架构，用来把所有的扫描能力，HIDS 源数据，数据处理能力，审计能力做了整合； 使得我们在同一个平台中，可以获取并同时以上帝视角分析这类数据，得到综合的安全分析的结论；但是由于数据纬度很多，我们编写一些基本的规则表现力并不够完成我们想要的分析。 所以，我们需要一个嵌入式语言。
甚至我们想把一些分析/规则能力分散到节点中，减轻中心服务器压力。
技术起源：嵌入式语言演变#
如果是 Java 的话，这事儿很好解决，我们甚至有 groovy 等等表达式语言/嵌入式脚本语言去和代码进行无缝对接；但是由于技术栈的关系，我们并不能使用这些技术；
Golang 技术下可选的嵌入式语言并不算多。
经过一些技术调研之后，我选择了当时一个 qiniu/qlang 这个项目（原项目已不在维护，变成了 Goplus）。
感谢 @qiniu 的开源协议与精神。
虽然 qiniu/qlang 仍有很多 BUG，但是经过我一段时间耐心的修改和调教，实现了很多 qlang 未实现的功能，同时也解决了很多他作为嵌入式语言的问题，
终于可以初步把他应用在我的安全平台中了。
第一次露脸：xray/rad 参与建设企业安全#
当我们集成进平台中，效果其实非常棒，我们可以用它做太多事情了
- 在文章中，我调用了
xray/rad完成了漏洞扫描的一些能力； - 同时，基础的规则审计，报告生成，动态通知我们都用了这门神奇的嵌入式语言来参与我们的建设；
此时，我们已经完成了初步的："安全融合" 的概念，我们把能力和规则与平台进行了融合。
当然，虽然我们只融合了当时供职单位中的数据和安全能力，但是不可否认的是，这个"融合行为"，和 API 互相调用有着本质区别，在人力/研发资源不够的客观因素下，真的解决了太多的问题了
巅峰：分布式脚本执行引擎#
作为一个勉强能说是 "研发人员" 的我来说，喜欢抽象化/泛化/有梦想做"鸡架"(基础架构)的人来说，其实上面说的很多能力，代码越少越好，嵌入式规则脚本越多越好。 所以，我们又对这门嵌入式语言进行了审计，我们移除掉了他与数据库的强绑定关系，他可以同时运行在分布式的节点中【参考我在这篇文章中提到的架构】。
我们的节点更加的泛化了，他能执行我们专属的嵌入式语言。
这取得了令我自己都吃惊的效果：
- 几行实现了分布式 xray 调用
- 一个脚本实现了分布式端口扫描
- 任何复杂的数据分析与审计流程都可以在节点上实现
- ...
以前这些超级复杂的能力，现在居然这么简单就能实现？
又造轮子？我们开放这门语言吧！就叫 Yak#
聊到了我做了的这些事情，大家有些人要说："这不就是造了个轮子吗？"
但是... 我真的是在造轮子吗？当然，我并不觉得我是在造轮子，可能大家会说，你这门语言里的类似的东西，我在 "XXX" 见过；但是，你想把它工程应用需要多久呢？需要付出怎么样的人力物力呢？ 解决工程问题，创造更好的生产工具则是非常好的解放生产力的方案，生产力解放了，大家就有更多的时间做安全研究了，从而又可以创造更棒的生产力工具，这本来就是事物良性发展的客观规律。
所以，我们从最初的平台中，把这个语言抽离出来，单独做了一个项目，阉割掉了 "企业需求"，留给大家一个 "安全工具大融合" 的新语言 Yak。同时我们努力新加入/新集成了更多的新朋友：
nuclei：不造轮子，MIT协议集成fuzz：市面唯一 Web Fuzz 全套解决方案- ...
最终，它变成了现在的样子。