Sooo.... I 've decided to compare the performance of Rust's and C#'s implementations of Russian declension, and, well... Everything is so explicit and safe in Rust, that I've spent several months learning Rust and figuring out the best way to implement all this.

I'm also addicted to Rust now.

I decided to make a grammar library in C#, for inflecting nouns, adjectives, pronouns and verbs. I thought I'd finish the project in a week or two, but the Russian language turned out to be so much more complicated than I ever imagined, even though it's my first language.

Traditionally, as you would learn from the textbooks, there are "only 3 declensions". But the thing is, that's the optimal number of declensions for humans to learn. As you dig deeper, and eliminate the "human intuition" factor, you end up with... approx. 4 558 657 distinct declensions. But, unfortunately, even that amount doesn't cover all the words...

I checked the source code of some SemVer C# libraries, and found out that all of them allocate memory excessively, use LINQ and even Regexes, and that's practically a crime!

And so, as someone who only at one single point in their life ever needed a SemVer library, I decided to develop my own solution, — Chasm.SemanticVersioning, that doesn't allocate that much unnecessary memory!

For some reason, I always limited myself to using either Prism.js or highlight.js for code highlighting, and recently I've learned of Shiki, a better (but much heavier) highlighter, and decided to try it out. It uses the same engine and grammars to parse code as VS Code, so it'd go really well with the VS Code theme I've been using!

In this post I'll compare TypeScript support specifically of the three mentioned highlighters and highlight some issues in them. I've also implemented switching between highlighters in my code blocks, so you'll be able to see how each one performs right here in this post!

Recently I've discovered some interesting information about the empty object type, {}, and some weird features and tricks that it provides. It's not "just an empty object literal" as some might think, and there are several very interesting and useful ways of utilizing its unique properties, that you could use in many different scenarios.

This month I decided to make a website for myself. One, that's just right. One, that will stick. One, that I won't abandon like the rest of my side projects... There were many challenges I had to overcome, but, in the end, I finally did it!

In this post I'll just write down my thought processes and decisions. It's not a step-by-step tutorial to creating your own website, but instead a record of a journey. You can view the website's source code as you read through this post, to learn how some stuff works.

React Server Components are pretty cool. It was a tough concept to understand at first, since not many guides explained how it all works internally, but eventually I got the hang of it.

But, as I developed reusable components, I found out that I had to create separate implementations (and therefore add separate exports) for React Server Components and Client Components. That wasn't ideal, because I wanted to put all of the code in one place and have it behave differently depending on what environment it was imported from.

So, I learned a lot of new information about the inner workings of RSC, SSR and CSR, figured out how to differentiate between RSC and SSR environments, and "invented" a solution for this problem, — "Hybrid" Shared Components.