Hi there! I’m The Puzzlemaker

I do program stuff. I’ve worked with Minecraft, Unity, OpenGL (reluctantly), the Linux Kernel, and other languages.

General Info

  • Birthday: September 14
  • Place: Wichita, Kansas, USA
  • Pronouns: He/Him/His/etc.

Programs I Use

  • IDE:
    • IntelliJ Idea Community Edition
    • Visual Studio
  • Text Editor:
    • Visual Studio Code
    • Nano
  • Terminal:
  • Shell:
    • Fish
  • Art Stuff:
    • Adobe Photoshop
    • Adobe Illustrator
    • Aseprite
    • Krita
    • GIMP
  • Git
    • Git CLI
    • GitKraken
  • Reverse Engineering
    • Ghidra
    • Cheat Engine (for Windows)
    • IDA Freeware
    • dnSpy
    • ILSpy
    • DotPeek Portable
    • Radare2
    • Good Ol’ GDB and LLDB

Dotfiles

See the GitHub repo

Links/Socials

About This Site

This page is going to (try to) answer some possible common questions about this site.

What is this site?

This site is my blog. I’m not using a CMS (i.e. Wordpress, what I used to use) for it anymore, as I honestly find them irritating at times.

How’d you make it?

I used mdBook, which is written in Rust, used for documentation and information about many Rust packages. I honestly just like the style and ease of use, hence why I used it.

Got a question to ask?

Feel free to email me! I may leave the question and answer here if it relates to this site.

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

The Caypso Manifesto

Note: Most of these are my own opinions and are not necessarily reflective of community of the programming languages in question. (Except, perhaps JS. JS is just unequivocally and demonstrably awful.)

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. However, what does this mean, exactly? In this post, I’m going to explain my ideology for Calypso: why I started writing it, and what I’d like it to become.

The Creation of Calypso

As you may or may not know, I love Rust and Elixir. However, there are just some things that Elixir isn’t suited for. And there are some things that Rust isn’t the best for. Sometimes, Rust seems like overkill or seems like too slow of a development time due to its long compilation times or complex type system. This draws me towards more dynamic languages like Elixir. However, Elixir, being inherently tied to the BEAM and Erlang/OTP, has features like immutable variables (though you can rebind them), and OTP is the main “application framework” for Elixir/Erlang. OTP is a really good design philosophy for applications, but I find that it’s sometimes kind of hard to set up for some applications, with its actor concurrency model and supervision. It’s a large amount of things to think of while designing even simple applications.

I have also found that already available scripting-like languages such as JS and Python are not really that easy to work with when scaling up; for example, JS, with its MANY design issues (e.g. implicit coercion), and Python, which while working pretty well when scaled up, is kind of hard to maintain in my opinion.

And that’s 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 a Bash script. Also, sometimes I have applications that are not really the best suited for either and are better suited for a more dynamic environment.

Calypso’s Guiding Principles

Calypso strives to cover these principles:

  • Flexibility, i.e. you don’t have to “hack” the language to do more complex things.
  • Simplicity, i.e. code is expressive but not too verbose.
  • A reciprocal combination of these two: flexibility and simplicity, i.e. allowing simplicity without sacrificing flexibility and allowing flexibility without sacrificing simplicity.
  • Performance, i.e. code shouldn’t have to be micro-optimized, code should run well enough without sacrificing flexibility or simplicity. As I’m not that experienced with optimization, this may take a while to implement.

These principles also apply to the standard library/ies of Calypso, which should be expressive but flexible and performant.

Calypso is mainly influenced by Rust, Elixir, and Erlang. In terms of overall architecture, it’s mainly inspired by Rust. However, there are some functional influences from both Erlang and Elixir, intended to help ensure flexibility and simplicity. Erlang is described as a functional language that breaks free to the imperative world at some points, whereas I would describe Calypso as the opposite: an imperative language that breaks free to the functional world at some points. While these seem like similar concepts, they’re somewhat different in nature. Calypso aims to be familiar but introduce some unfamiliar concepts from the functional world that can help to keep code short, simple, flexible, and maintainable.

What I’d Like Calypso to Become

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

As I’m not really a fan of Python, and I’m an enthusiast of binary exploitation and CTFs, I may eventually port at least some of pwntools to Calypso. I might end up implementing some of it in Rust, as I do plan to have FFI as a major part of Calypso, or at least the VM behind it, Odysseus.

What Calypso is Not Going to Become

I’m not expecting Calypso to replace Rust or Elixir or JS or Python or, well, really anything. It’s not created with that in mind--it definitely isn’t a systems language and probably won’t have as good concurrency as Elixir (though I hope I can make concurrency work pretty well).

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 performance of either language. It may be about as fast as Elixir as some point, but as a non-systems language it’s definitely not going to rival Rust’s performance without JIT (which I currently don’t have plans for).

Updates

2021/02/22: Added “What Calypso is Not Going To Become” section

Dotfiles done!

I have finished compiling my dotfiles. You can find them at https://github.com/ThePuzzlemaker/dotfiles.git.

Here is the README as of now:

dotfiles

A collection of my dotfiles. This will expand every once in a while.

Some of these are modified to work on (almost) any environment, though some are modified to remove possibly sensitive/user-specific information.

Here’s a list of programs you’ll need to use these at the greatest level:

  • radare2
  • gdb
  • pwndbg
  • nano-syntax-highlighting
  • ripgrep
  • lsd
  • fish
  • kitty
  • neofetch

If you find any issues with these or a program I forgot to mention, feel free to make an issue.

Dotfiles done!

I have finished compiling my dotfiles. You can find them at https://github.com/ThePuzzlemaker/dotfiles.git.

Here is the README as of now:

dotfiles

A collection of my dotfiles. This will expand every once in a while.

Some of these are modified to work on (almost) any environment, though some are modified to remove possibly sensitive/user-specific information.

Here’s a list of programs you’ll need to use these at the greatest level:

  • radare2
  • gdb
  • pwndbg
  • nano-syntax-highlighting
  • ripgrep
  • lsd
  • fish
  • kitty
  • neofetch

If you find any issues with these or a program I forgot to mention, feel free to make an issue.

Hello, world!

This is a test page to test a script thingy I’m making. Also, it’s the first post on this blog, I guess. 😀