This post was partially adapted from The Calypso Manifesto, which I wrote on my "original" blog a bit over a week ago.

I saw that quite a few people read my last post, which you can see here:

Introducing The Calypso Chronicles

James [Undefined] ・ Mar 2 '21 ・ 5 min read

#calypso #rust #devjournal #langdev

I thought that it might be helpful to some people if I introduce them to Calypso, as I'm sure that 99.9% of the people that read it (or at least looked at it enough for dev.to to count it as a view) probably did not know what Calypso is.

Calypso is a mostly imperative language with some functional influences that is focused on flexibility and simplicity.

This is the tagline for Calypso on its GitHub page, which you can see here:

import standard.process.Args
fn main(args: Args) ->
    args
    |> _.get(0)
    |> _.unwrap_or("100")
    |> uint.from_string
    |> _.unwrap_or(100)
    |> fizzbuzz
    |> _.each(&println("{}", &

But what does this tagline mean, exactly? In this post, I'm going to describe why I created Calypso, what it is, what it will hopefully become, and what it will not become.

So, what is Calypso?

Calypso is a programming language that uses mostly imperative programming features, but also has some influences from functional programming. It was inspired by Elixir and Rust. I'm writing the compiler and virtual machine in Rust as I'm fairly comfortable with it, and it's arguably a pretty good language to do so.

In terms of the overall architecture, Calypso is mostly inspired by Rust. However, a lot of the functional aspects are inspired by Elixir or Erlang.

A lot of times, Elixir and Erlang are described as functional languages that break free to the imperative world at points (for example, with side effects). I would describe Calypso as the opposite an imperative language that breaks free to the functional world at points. While these seem very similar in nature, they're pretty different.

I'm aiming for Calypso to be familiar but introduce some potentially unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What does the tagline mean?

Flexibility and simplicity are two of Calypso's guiding principles. Here's what exactly they are:

• Flexibility. This means that you shouldn't have to "hack" Calypso to do more complex things.
• Simplicity. This means that code is expressive but is not too verbose to the point where it's hard to understand.
• Performance. This means that code shouldn't have to be micro-optimized (or otherwise manually optimized) to run well, without sacrificing flexibility or simplicity. As I'm not that experienced with optimization, this may take a while to implement effectively, but you're obviously welcome to contribute! :)

These guiding principles should not necessarily be mutually exclusive, which is Calypso's goal. Thus, you shouldn't have to sacrifice one of them to have the other, so you can have code that is not only simple but is also flexible and performant.

Also, they should also apply to the standard library/ies of Calypso, which should be expressive, flexible, and performant.

So why did I create Calypso?

In case you didn't already know, I love Rust and Elixir. However, there are just some things that Elixir isn't suited for. And this isn't exclusive to Elixir--there are also some things that Rust isn't the best for.

Sometimes, Rust seems kind of overkill or seems just too slow of a development process due to its incredibly static nature. While this makes Rust easy to work with, in the long run, it makes short development cycles and compilation times long. This draws me towards more dynamic languages like Elixir.

However, as Elixir is inherently tied to the BEAM and Erlang/OTP, it means that it has features like immutable variables (though you can rebind them and have state via process loops, e.g. Agents or GenServers). This also means that OTP is the main "application framework" for Elixir/Erlang. In my opinion, OTP is a pretty good design philosophy for applications, but sometimes it's just kind of hard to set up or wrap your head around. It can cause you to think about a lot of things when designing even simple applications, which means that it's sometimes much harder to develop applications incrementally.

I have also found that already available scripting-like languages such as JavaScript and Python are not really that easy to work with when scaling up; for example, JavaScript, with its many design flaws (which I'm not going to explain in this post because it's not a post about JS), and Python. While both work somewhat well when you start and when scaling up to an extent, they just get hard to maintain.

And these reasons are some of the reasons why I created Calypso. I enjoy Rust and Elixir, but for some applications, including scripts that are not quite full applications but not quite worthy of being just a Bash script, they're just too much. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more generalized dynamic environment.

What would I like Calypso to become?

Personally, I'd like to see Calypso become a language that could be used for applications, simple and complex, offline and offline, command-line and graphical.

I have no way of knowing if this will happen or not, but I have a goal to make Calypso approachable enough that people will be able to bring it to this point.

What am I not expecting Calypso to become?

I'm not expecting Calypso to replace Rust, Elixir, JavaScript, Python, or really, well, anything. It's not created with that in mind--it definitely isn't a systems programming language and probably won't have as good concurrency as Elixir, being on the Erlang stack. (Though I do hope that I can make concurrency work pretty well, though I haven't really thought that far ahead yet.)

I'm hoping Calypso can be used to make applications that could otherwise be made in Rust or Elixir, but I'm not expecting it to singlehandedly replace the entirety of those languages. That's just not a goal for it.

Calypso will probably not be as fast as Rust or Elixir either. It's intended to be simple, so it will definitely compile faster than Rust, but I'm not expecting it to particularly rival the performance of either language. It may be about as fast as Elixir at some point, but as a non-systems language, it's definitely not going to rival Rust's performance without JIT or other heavy optimizations (including native code, both of which I don't currently have plans for).

What are the parts of the Calypso ecosystem?

There are a few main parts of the Calypso ecosystem. In summary, these are:

• The language itself
• The compiler and tooling
• The standard library/ies, Atlas and Gaia
• The bytecode virtual machine, Odysseus
• Officially developed and maintained libraries

These parts should ideally work together to make ensuring Calypso's guarantees are enforced is easy and approachable.

You might not be familiar with some of these aspects, so I'll explain them briefly.

Calypso Compiler and Tooling

The Calypso compiler and tooling (including the calypso binary) are used to integrate development and testing of Calypso projects.

The standard library/ies

There are technically two standard libraries for Calypso: Atlas and Gaia.

Atlas is the kind of standard library that you'd be familiar with from a language like Rust or Elixir.

Gaia is more complicated. It's basically the minimum required to integrate Calypso and Odysseus. It will include things like FFI types, primitive types, language items, etc.

If you're wondering why they're named this way, it's because I'm bad at naming things. Congratulations me!

The bytecode virtual machine

Odysseus is a bytecode virtual machine. Basically, it's a system in which an abstract representation of a program that's not quite machine code but not quite source code or an AST is run on a "virtual machine" (hence the name) that is compatible with pretty much any platform the language it's programmed in supports (so, in this case, any platform Rust supports). I'm not able to test multiple platforms at this point, so please contribute or report issues if you have issues on another platform!

Officially developed and maintained libraries

In order to further the Calypso ecosystem, but not bloat the standard library, I will most likely develop some libraries that are helpful for things such as cryptography, HTTP, etc.

One library that I may eventually make which will probably not be an officially maintained library but which I will maintain myself will be a partial or full port of pwntools (a library written in Python for CTFs) to Calypso.
For more information on CTFs, atan made a pretty cool post about them:

What is CTF and how to get started!

atan ・ Mar 28 '19 ・ 3 min read

#security #ctf #beginners

Conclusion

Well, that was a long post. If you notice any mistakes, have any questions, or would just like to discuss something about Calypso, feel free to make a comment or hit me up on Discord (my Discord account is Paradoxical#2936). There's also a #calypso channel on the pretty popular programming language design Discord server.

Anyway, have a good morning/afternoon/evening/night/etc!
-James