Yttria's Future and Roadmap

[nthnn]

The Future and Plans

Greetings! It's been one week and one day of development since the initial commit of Yttria. Hence, there's a lot plan wrapped on my head for this project. I also think that it would be a good idea to let the future collaborators know future and the roadmap itself of what Yttria should be. So, yeah.

Target Architectures

Initially, the target architectures of Yttria, since it uses LLVM compiler infrastructure, are the ARM, X86-64, X64, MIPS, SPARC, et cetera. However, I've been also looking forward to make it compatible for AVR microcontrollers (such as ATTiny85, ATTiny45, ATMega328P, ATMega2560, etc). Quite ambitious, but it would be great for Yttria to support a wider variety architectures and devices.

Influence from Other Languages

Like every other programming languages, there's a lot of ideas for Yttria which are inspired from different languages; C/C++ (of course), D, Kotlin, Go, Carbon, and Rust. Yeah, I know, all of them are technically compiled language. I'd like to enlist those possible features from the mentioned languages that will be implemented in Yttria, however, the list is subjected to a lot of changes. So, here it is.

• D's in and out statements on subroutine

  I've been kind of contemplating for this language feature if I should add it on Yttria. Personally, I believe that this is an underrated feature of the D programming language. Both in and out statement can be used for preventing unsafe side effects and enhancing debugging processes on runtime.

  However, the in and out statements for a subroutine's body on Yttria would be different. It won't be called and checked on compile time, but would be executed on actual runtime.

• Kotlin's Extension Functions

  I know this feature also exists in Golang, but I discovered it first while developing an Android application using Kotlin. Anyway, it'd be amazing to add this feature not just to extend some primitive data types, but to also extend structs to make an OOP-style of abstraction.

  # Structure example for a cat description
  struct Cat {
      name: string;
      age: i4;
  };
  
  sub printCat(): void ext Cat {
      render 'Cat's name is ' + ext.name +
          ' and is ' + ext.age + ' years old';
  }
  

  Hence, the ext keyword would be used to declare a subroutine as an extension of a struct and also as a variable that holds the current structure's data.

• C# and Rust's unsafe block statement

  I am not exactly planning to make Yttria a safe language as Rust do, however, it'd be great to let the programmers using Yttria to be able to have a low-level memory manipulation and also for interfacing with an external code as well. There are also instances, based on my experience, that unsafe code blocks have proven pretty good performance optimizations. Thus, unsafe code blocks can allow developers to fine-tune memory usage and control in some performance-critical scenarios, specially on AVR microcontroller targets.

• Golang's go routine

  Concurrency is a very significant concept in programming languages. Making products achieve much more performance, responsiveness, and utilization of resource availability. And so, I believe that this feature is a crucial concept to be added on Yttria, including the channels.

  In addition to go statement and channels in Golang, I'd also like two statement blocks, which is the lock and sync statement. I won't delve too much on this, however, this feature might be disabled on AVR microcontroller targets since they are typically single processors. But who knows?

And yeah, that's it for now.

Command Line Interface Tool

I love Terminal tools and programs, as for my personal preference. So I'm planning to develop something like an NodeJS' NPM or Python's PIP for Yttria. I named it simply... CLI Tool for now, but might rename it soon. I'm planning Yttria's CLI tool to be more like a package initializer, deployment tool, and more. That's what I have on my head right now.

To Future Collaborators

Comment down what are your thoughts on this... and that's if there's someone reading this.

---

Sincerely,
@nthnn