A year of EYG development and proper open source
It's just over a year since the last EYG update. In that time I have taken a new job, organised the first Gleam conference and continued to experiment with EYG.
This update shares some details of that year and outlines what comes next.
EYG is officially open source.
Experiments in the Eat Your Greens project have been many, varied and to satisfy my own curiosity. I've always been happy to talk about my work and the source code has been available since the beginning.
Thus far I had not attached a license to the code. That has changed and to signal that I am open to contributions there are two obvious changes in the repo.
An Apache 2.0 license is in the
LICENSEfile.There is much less code and it's all Gleam.
The initial repo contains a JSON spec for the language. There is also a set of packages to build an interpreter with it's own external effect implementations. The packages have all been tidied up with more tests, ci, some documentation etc.
All other experiments have moved out. Some will return as they also get cleaned up and documented.
By focusing on the language spec and a good quality first interpreter I'm moving EYG in the direction that most interests me.
An editor for large programs
For a good while the main item on the roadmap has been an editor for large programs. This item is still outstanding, though a lot of progress has been made.
My definition for a large program is one that you want to split over multiple packages. The EYG structural editor is very effective at moving through one package/module. This large editor extends that effectiveness over a workspace of multiple files.
To see a preview of the editor in action checkout this introduction. All the key questions about how the editor should function are resolved. All that remains is adding polish so that it can be moved into the open source code base and deployed.
AI in the room
I've always thought EYG should be good for end user programming. I'm not a fan of "vibe" coding. However it's not possible to talk about end user programming and avoid questions about AI. To that end one of my experiments has been to use EYG code as the scripting environment available to an LLM.
The managed effects of EYG make me much happier running that code than arbitrary bash. It's less powerful but a lot safer and I like that trade off.
In the end playing around with coding harnesses has made me realise how important a programming environment is. An LLM in the terminal can do a lot more than one in the browser.
Next for EYG
I will be moving all the remaining packages that the editor requires into the new clean repo. The website will be built on this editor and more reliable as the test coverage increases. EYG claims to run everywhere so it's important that is true on the website.
What makes EYG different is the simplicity of making one more implementation. I have run EYG programs on arduino, within Auth0 rules engine, in Nginx, in the browser and on the server.
My goal for this year is to make it easy for other people to implement one more EYG interpreter and start an ecosystem of runtimes.
That's all for this update, I hope you have enjoyed it.
This issue is available, and shareable, at https://eyg.run/news/editions/6