ryelang

When you are working on an "wide" project, like a language is, you have to limit your scope somehow. One self-imposed limit for Rye < 1.0 was, that I will not think about modules. Go compiler is known to produce single statically linked binaries. That means that a single file just works , no need for additional installations of any other Go runtime dependencies. This is very nice for distribution. Rye interpreter is also such single binary, and although Go, from version 1.5 supports use of shared libraries, I don't plan to make Rye's bindings dynamic for now. This is a limitation. If you have one global Rye, it has to be compiled in with all the bindings you need on your system. Tags to the go compiler define the modules, so defining them is not hard, but not something you want a Rye programmer to think about. Solving limitations often offers new avenues for innovation. Having a global programming language and global modules is problematic also in dynamic/shared s

I visit news.ycombinator.com - the Hacker News - at least few times a day. It often features interesting news items and intelligent comments. Last week I found a language comparison post by losvedir . Author thought of an interesting and compact problem around serving merged data from two CSV files over HTTP. Author so far tested idea only with static/compiled programming languages. Since Rye is focused on data/information processing and also on "the backend", this sounded like a perfect job for it. Rye also has this very high-level datatype called Spreadsheet (more about the reasoning in the previous blog-post ). This datatype, with some powerful functions, elegant setup for a HTTP server and easy loading of CSV files made whole Rye code very simple. While Go's solution used 180 lines of code and Rust 200 , Rye (which is a dynamic language) took just 38 lines . The problem Program needs to load two CSV files. First (trips) features 72k lines, second (stop_times) 1.