ryelang

I am changing Rye to use Go modules, which became mandatory with Go 1.18.  This took me some time, because of Rye's very dynamic use of modules. I described the problem in a few Go forum posts. No obvious solution was found - although, very kind community! Now I think I see how it can be done in an OK way, and could also improve the Rye experience at the end. In the meantime, while making the builder script I also needed and added small addition to the language in terms of functions, and in terms of concepts. The if-with . More about it in the pic below: Follow our development on Github .

I need to make a Telegram bot for my work. I decided to make it in Rye ... this is first example to see how it works. Rye uses the Golang's telegram bot library . Telegram has very rich support for bots, not just regular "chat". It also supports inline interaction, special "keyboards", etc ...   The TinyGo experiment so far hasn't brought any fruits. After tons of pruning of all possible problematic code and dependencies we go to a .wasm binary that was smaller than if the same code was compiled by the official Go compiler, but only by 10 percent. Rye is a Golang project, and Golang moved to Go.mod system for dependency and module management. Rye seems to be a little specific here, since it's dependencies are deeply dependent on the build flags. I was looking for a solution to this inside Go.mod system but couldn't find any, so I asked a question on Go forum yesterday. We will see how it goes ...

Contrary to the number of blogposts, Rye development wasn't sleeping last week. I experimented with Rye compiled to Web Assembly. Regular Go can cross-compile to WASM without a problem, but the .wasm file is not so small. It was around 5MB in my test case. The bigger size is supposed to be the result of not so small Go runtime, that isn't made to be used in a browser for example. But there is a very interesting project out there: TinyGo , that made an alternative compiler. They are using llvm and a lot of it's features to reduce the size. So go becomes good option for very small devices like micro-controllers and also WASM! Compilation right now takes a lot more time, but if it would produce considerably smaller .wasm file, it would be more than worth it and really awesome also for Rye. The problem right now is, that compiling Rye with TinyGo doesn't produce smaller binary, so we are trying to figure out why is that.

When playing with recent puzzle , I added some new HOF-like functions and made existing ones work with more data-types. I added strings not just blocks / lists to some of them. Below is a short demo from the Rye console where you can see how they work. You can get the code as code in the following gist .   We have got binaries now on github and a docker image on Docker Hub .

As part of making Rye REPL more exploration friendly I started working on an interactive Rye value display -er. Below is simple first demo with a Block. It tries not to just display the block, but let you interact with it and return the value of selected item back to the REPL. I don't have a full picture about this yet, but I think if done well, it could enable some interesting workflows. Think about a full programming language, a REPL and something a little akin to Excel? The same will be done for other Rye structures, like Dicts, Lists, Contexts and Spreadsheets.   BTW: a goal of Rye is to be human-friendly, so Rye REPL, while sounding more Lisp-y will from now on simply be called Rye console . And the Spreadsheet , A R-lang data-frame inspired Rye structure will for brevity be renamed to Table . I am also adding a set of functions around now Table . Not the same, but in the past, I already integrated Go-lang's QFrame (think Python Pandas dataframe) library to Rye, and also ...

Just an idea I got last week and haven't yet been able to overthrow it yet. Potential benefits are also yet to be explored ... When programming, our scopes (namespaces, contexts ...) are basically key-value stores. They translate names to values.  What if scopes could also store relations between values? If context would also be a graph?  Would this improve on how we solve some problems, or write some algorithms? I haven't really explored it yet, below I tried to get some sense of how Rye code in this case could look like at all. Do you have any ideas? The solidification of Rye core continues ... you can follow it on Github :)

There's time for exploring, trying out ideas, rapid experimental growth and garbage collection ... that was the majority of my time with Rye so far. But a time for solidifying what worked, making all the dull tasks, unifying error messages, type checks, cleaning out build dependencies is also needed. If product should eventually become a product, not just exploration of ideas. I am currently in this time. In big part thanks to @otobrglez , who wants to tinker with Rye a little, make a FizzBuzz example, etc ... :) At the end of it, Rye should be easy to build by anybody interested and should be relatively easy to start exploring and tinkering with. At least core functions should provide consistent error messages and docstrings. I already cleaned up repository somewhat and setup a tiny build with minimal dependencies. There are new instructions on Readme page. I am now solidifying core functions in builtins.go and improving runtime and syntax (loader) error reporting. Also improvin...