Once upon a time, in the land of curly braces, I, a devoted C# enthusiast, embarked on a daring adventure to explore the mysterious realm of Rust. Rust burst onto the scene like a supernova, capturing the hearts and minds of developers around the globe. Its focus on safety, performance, and concurrency has earned it a dedicated following, and even the Linux kernel couldn’t resist Rust’s allure. As Rust continues to make waves in the world of systems programming, C# watches from the sidelines, confidently flexing its newfound performance muscles and ready to take on any challenge that comes its way.

While Rust’s safety features and swift performance tempted me, its cryptic syntax and peculiar design choices soon had me pining for the familiar embrace of C#. Rumor had it that C# and .NET 7 had been hitting the performance gym, so I decided to rekindle our romance. In this blog post, I’ll chronicle my journey back to C# and compare its newfound strength with Rust using some good ol’ benchmarking results.

C# Sharpens Its Edge

It turns out that while I was flirting with Rust, C# had been diligently honing its edge like a master swordsmith. .NET devs had been forging tirelessly to improve C#’s performance and the .NET runtime, forging the razor-sharp .NET 7.

The Computer Language Benchmarks Game showcased the fruits of C#’s labor, revealing significant improvements in execution time and memory consumption. C# now slices through performance benchmarks alongside Rust, demonstrating that it’s no longer the blunt underdog in the performance arena.

Meanwhile, the TechEmpower web framework benchmarks crowned ASP.NET Core among the elite, proving that C# and .NET 7 can deliver high-performance web applications with the precision of a finely-crafted blade, rivaling Rust-based web frameworks like Axum.

C#’s “New” Superpower

During its time at the forge, C# discovered a new superpower: Ahead-of-Time (AOT) compilation. This newfound ability allows C# to compile code into native machine code before runtime, skipping the more leisurely Just-In-Time (JIT) compilation process.

AOT compilation not only reduces startup times but also enhances performance optimization. AOT and JIT compilations are like two superheroes with different origin stories, each with its own strengths and weaknesses. AOT, the more proactive of the two, compiles code into native machine code before runtime, flexing its muscles to reduce startup times and optimize performance. On the other hand, JIT, the more leisurely and contemplative hero, compiles code during runtime, taking its sweet time to optimize based on the application’s real-world usage.

C#, being the more application-driven and versatile chameleon that it is, initially chose JIT as its trusty sidekick. However, as C# realized it could cater to more performance-critical scenarios, like games, it embraced AOT, stepping out of its comfort zone and broadening its horizons.

• AOT-only
  • C
  • C++
  • Rust
• JIT-only
  • Java (mostly JIT, but can use AOT in specific cases)
  • Ruby
• Both AOT and JIT
  • C#
  • Go
  • Kotlin/Native (for native platforms)

The Rusty Side of the Coin

Rust is undeniably a fascinating language, boasting a focus on safety and exceptional performance. However, its syntax and design choices can sometimes feel like deciphering ancient hieroglyphics. With a slew of abbreviated keywords like fn, mut, and impl, Rust might as well be speaking in code.

In addition, Rust’s syntax deviates significantly from its more familiar counterparts like C# and Java. Rust’s concepts of lifetimes and ownership can leave developers accustomed to garbage-collected languages scratching their heads in bewilderment.

Check a box on which concept to you ever heard of:

• Lifetimes and Ownership
• Borrow Checker
• Pattern matching syntax with match and _ (wildcard)
• Option and Result types for error handling
• Trait-based generics
• Macros with a ! syntax

Congratulations: you scored Zero points!

Meanwhile, C# retains its elegant simplicity, with meaningful keywords and design choices that prioritize readability and user-friendliness. Over time, C# has embraced modern features like pattern matching, nullable reference types, and async/await, all while maintaining its easy-going charm.

Back to The Future

My escapade into Rust was undoubtedly an eye-opening experience, allowing me to appreciate the powerful capabilities of both languages. However, Rust’s enigmatic syntax and design choices had me yearning for the warm, familiar comfort of C#. Returning to the latest C#, I discovered a language that had evolved and adapted, offering a potent combination of performance, elegance, and ease of use.

As C# and .NET 7 bask in the limelight, little do they know that .NET 8 is waiting in the wings, ready to dazzle us with even more breathtaking improvements. Rumor has it that .NET 8 will further incorporate functionalities from popular third-party libraries, making it an even more enticing one-stop shop for developers. With the pace of innovation accelerating, the future of C# and the .NET universe looks brighter than ever.

So, my fellow developers, let my tale be a testament to the importance of keeping an open mind and daring to explore new horizons. However, sometimes, the grass isn’t always greener on the other side. In my case, I found that C# was the perfect blend of power and familiarity that I had been seeking all along.

As you navigate the tumultuous seas of programming languages, remember to consider your project’s specific needs, performance requirements, and personal preferences. Each language has its quirks and charms, and the right fit will depend on your unique circumstances. In the end, it’s about finding the language that makes your heart sing and your code soar.

Smart homes are becoming increasingly popular as technology continues to advance and become more accessible. You can control various devices and appliances in your home through a single app or voice assistant. It can include lights, temperature control, security systems, and more.

You can control these lights through voice commands through platforms like Google Assistant or Amazon Alexa. With smart lights, you can easily set the mood in your home by adjusting the color, brightness, and temperature of the lights. You can also automate lighting by setting schedules or creating scenes, such as turning on the lights when you enter a room or dimming them for movie night. The typical sales pitch “Endless Possibilities” does apply here!

I started to transform my house into a Smart Home about a year ago and I’m loving it!

DIY

One of the most affordable and customizable options for building a smart home is to use Home Assistant with a Raspberry Pi. Home Assistant is an open-source platform that allows you to integrate and control various smart devices in your home. It is free and can be easily installed on a Raspberry Pi, making it accessible to people with a range of technical skill levels. Home Assistant supports a wide variety of smart lights, including those from popular brands like Philips.

One of the benefits of using Home Assistant with a Raspberry Pi is that it is free of paid service. All smart-device companies offer a paid subscription service to unlock some extra features. The Home Assistant community has hundreds of tips and tutorials to replicate them on your own. This means that you don’t have to worry about recurring subscription fees or being locked into a specific platform.

Unlike paid smart home services, particularly those in other countries, you can be confident that your private information and data are secure and not being monitored or accessed by anyone else. You have full control over your data and devices, and you can be sure that your security cameras, personal information, and other sensitive data are not being shared with any third parties. This level of privacy is crucial in today’s world where data privacy concerns are becoming more widespread. By choosing this DIY smart-home setup, you can enjoy the benefits of a connected home without worrying about the privacy implications of using a paid service.

Node-RED, included as a plugin, allows for even greater customization and automation in your smart home. You can create “flows” that automate various tasks, such as recording security video when motion is detected, sending notifications to your phone, or turning on the lights when you enter a room. This can make your smart home even more intelligent and responsive to your needs, freeing up time and effort that would otherwise be spent on manual tasks. The plugin provides a visual interface for building these automations, making it easy to set up and modify your flows, even if you have little to no programming experience. By incorporating Node-RED into your Home Assistant setup, you can take your smart home to the next level and make it truly your own.

I had to configure an online backup. Raspberry Pi has a history of failing, especially the micro-SD. It gives me peace of mind knowing that even if my Raspberry Pi fails, I can easily restore my Home Assistant setup without any hassle.

Wallet and Keys Free

Another great feature of a smart home is the ability to leave your keys and wallets behind when you leave the house. With smart locks and phone-based payment systems, you now can control access to your home and pay for purchases with just your phone. It can make life much more convenient, as you won’t need to carry a bulky keychain or wallet everywhere you go. It’s pocket freedom! Simply use your phone to unlock your front or garage door, and pay for your morning coffee – all without ever having to dig through your pockets or purse. The counterpart is the single point of failure: in case I lose my phone (or get robbed), I will have no money and no way to enter my house. :(

I did the right thing to start to automate my home a year back. Building a smart home with Home Assistant on a Raspberry Pi is a cost-effective and customizable option for people who want to control their home appliances and devices from one central location. A valid warning: it’s addictive to tweak each device or flow to fit your taste. Just take care of not getting into the rabbit hole!

In a year full of personal experimentation in other careers (like running for congress, for example :), I still programmed a lot. I invested a lot of time studying Docker and containers, Kubernetes, Home Assistant, and hosting web systems myself (like Nextcloud).

But game design is a passion.

I constantly get annoyed with Unity3D and the latest events on the business side, which had me worry even more. I tried to use Godot and failed. C# is far better in terms of easy-to-use and safety compared to C++ and even more to custom scripting languages. It’s more organized and well-documented. And I have years of accumulated experience. And Godot-C# integration is buggy, unstable, and full of gotchas. The way they re-implemented C# in the upcoming Godot 4 created so many artifacts to properly work that I got even more frustrated. I could not use Lists<>!

After watching a curious review on the GameFromScratch channel, I tried a new kid in town: Flax Engine. It’s a C++/C# engine heavily inspired by Unity. The from-to process is straightforward. After just a few of weeks playing with it, now I decided to invest in it. I am planning to port my closest-to-finish game I have to it by the end of the year. It’s 1 step back, 2 steps forward.

Cons

👎 Like Godot, there is no way, currently, to drag-and-drop assets and actors with a specific class. I always have to ask for a generic Actor in the editor and check if has the given class in the code. Annoying and error-prone.

👎 Still lacking several common features, compared to Unity and Unreal. It’s evolving and, most importantly, their competitors pave the way for inspired clones like Flax.

👎 Minuscule community compared to other game engines, even the indie ones. Recent GitHub reports the biggest Open Source projects do not place Flax into the top 10.

Neutral

😐 Not FLOSS. It’s open source but it’s not free. The license requires paying royalties. It’s very close to what Unreal asks but more generous. I would love to see it converting to a full FLOSS model in the future.

👎 Old C#/.Net version. A branch with the newest .NET 7 was created and developed. The current version uses .Net Framework 4.8 and it is a pain to install on Linux.

👎 Still lacking Docker image for CI/CD (well, Unity and Unreal also do not have official ones). I may implement a repository myself, inspired by GameCI ;)

Pros

👍 1-1 adaptation from a Unity developer. It’s not as feature-rich, but it’s very competent.

👍 Open community. A lot of issues and Merge Requests on the project’s GitHub page. I’ve been talking to devs in a Discord channel and they are receptive.

👍 Small footprint. The editor is only a couple of megabytes and the “cooked” game is also small. If possible, running it in an Alpine-like image will create a minuscule image to use CI/CD.

I do maintain, for almost 10 years now, a personal journal. A diary. It’s self-psychotherapy. It’s a way to express my thoughts and feelings.

First, I used Google Docs. I created dozens and dozens of files, one for each day. Eventually, I realized that Google was not supposed to be trusted with confidential and personal information. Their spiders crawl and index everything. These thoughts may be still there, even after I delete all the files. Who knows.

Then I migrated to a secondary solution: WordPress. I hosted a blog and used an add-on to lock it up, allowing just me to see. It’s wonderful for blogging, with a lot of tools. I designed some extra add-ons to manage some aspects of the journal, like a word count and a title generator (based on the post date).

However, maintaining an up-to-date WordPress installation is critical. Due to its popularity, and broad usage for e-commerce, WordPress is a target for many, many hackers. I started to think that I could let hacked and let all my stuff be exposed. So I decided to export all posts and move once again.

I tried to only maintain it offline, on my computer. It’s, for sure, the most secure way. Anything that is on the internet, even if it’s secured, could be hacked. But sometimes I want to write while away from home. On a trip, for instance.

I looked for a solution that was hosted online, secure (bonus if it was encrypted), and versatile (super bonus if it was open source). I tried some days using SimpleNote, and then Notion. Notion is very nice, and I was using it not only to write my journal, but also I started to use it to track some daily routines, like checking weight, sleep time, and amount of water that I’ve consumed.

But again I was not very confident about security. So, I’ve exported everything and decided to host it only on my computer. This time, with a caveat: I was liking the usage of Hugo static site generator, so I designed a blog front end and only enable it locally. And use git to track changes and host at GitLab. If eventually I’m not at home and want to write, I could find an app to connect to the repository and write. Months passed, but I’ve never found a mobile app. So I was locked to just write locally or access the repository using VS Code or whatever.

Finally, the Main Topic

The other day I decided to check Netlify CMS. Created by Netlify hosting service, it tries to create a dynamic admin front end to manage static websites. The result will still be very much static, but the admin section is a single page with a JavaScript script that will do everything. It will communicate with an online git repository and commit any new post. The authentication is done through the git service, GitLab in my case. It could be GitHub or any other git service. If the user does not have access to the repository, the admin page will be blank. It reads the source in real-time.

Besides, I could also host the final journal online using GitLab pages, but with settings that are only visible to maintainers. The same authentication would be required to see both the front-end and admin pages. Nice solution.

Netlify CMS is VERY simple. I can only imagine how complex is under the hook, but the final experience for users is simplistic. However, it does the job: I can now access and write my journals from anywhere, including the browser on my phone.

The system relies on a monolithic configuration file that is hosted side by side with the content in the git repository. Traversing all the posts from a remote git repository is very slow and not efficient. I cannot imagine dealing with a more complex team structure using it at the same time.

A neat feature is the draft mode: it creates automatically a fork with the draft content. Only when the user clicks “Release”, it merges the content into the main branch and publishes. Netlify CMS does not require Netlify itself, but they are nicely integrated if you decided to use it.

After the successful first experience with my diary, I implemented it in my blog. By the way, this very post was written using this pseudo-CMS!

At the beginning of the year, I posted about the retrial of Godot, the most popular free and open source game engine around.

I’ve posted some pros and cons at the time. I then decided to enter into a JAM to motivate myself to try to use it myself for a real complete project. Even if it is a jam-like game.

Now it’s time to write a review the whole process.

TLDR: I failed to complete the game. I tried to create a pipeline to build a nightly version for the latest version, with C# support. It is partially running ok.

Bootstrapping

The Jam theme was “ocean”. Bonus points if:

1. All sounds in-game are made with your mouth(s)
2. Include a fishing mini-game
3. Include your favorite quote or pun in-game

So I started. As previously said, I’ve planned to implement an old game of mine as the main game. The advantage was that I knew what was needed and the general need. Another plus was the fact that the game was abstract, so I could save a lot of resources and time on the presentation. And by doing the sound effects with the mouth, I could neglect this front until the end.

For the mini-game, I looked for a small board game that I could easily implement in digital form. After some research, I settled with Leaky Boat, a fast-paced pen-and-paper game with dice.

So I started to code. But the problems with the C# integration were getting on my nerves. Godot editor crashed more than 30 times on the very first night of coding. It was not blocking the path, but it was making it very, very difficult.

New Version from Scratch

As a potential solution, I checked if the undergoing development of Godot 4 (I was using the “stable” version of Godot 3.5) had any nightly build available. I’ve found a guy that was creating these nightly builds! But only the original non-C# version. The repository was open, so I checked if anything was possible to salvage. Not much.

So, as a detour, I decided to build a pipeline on GitLab that would compile the source code and build it. Eventually, I would schedule it to run every night. However, the process of creating a build pipeline online is very tedious and laborious: on every change, I had to run online. In the case of Godot, trigger the code compilation to eventually discover that 30 min the build started, it failed due to some dependency on the build stack was not fun. It took me a whole day to spend my CPU quota doing this.

So, as a second detour, I decided to host a local GitLab instance on my computer. It would allow me to develop the pipeline itself. Once ok, I would migrate back to the online service. It took me 2 days to set this. I first decided to go with local Kubernetes, but it was getting too complicated. Then I migrated to a solution that I am more familiar with: Docker-compose inside a virtual machine. I created it inside VirtualBox (instead of KVM) because I planned to reuse it when I decided to use Windows.

Downloading and building several docker images takes a lot of space! I had to resize the VMs to a much bigger size than originally planned to accommodate a dozen images created/downloaded.

The plan was to create a helper image with all the tools needed to compile the code with or without C#, host/register inside GitLab itself, and reuse it in the main pipeline. This step was working fine, but the actual build was failing time after time.

To check if the steps were right, I decided to compile them inside my machine. I did not want this to not pollute my pc. But worked. Since I “wasted” a couple of days on this detour, I decided to use this local compilation in my project again.

New Version, Old Problems

Godot 4 renamed vaious classes. Also, it changed countless small things internally, and it took me a couple of hours to migrate to the new environment. Good thing is that I did not have much to convert. Done. And the game was working the same as before.

Now it was time to continue the development. But the problems continue the same way: the editor was crashing time after time. I managed to make both the game and the mini-game functional, but with restrictions. The pace was slow because I had to investigate the way of doing things all the time. And the documentation was definitively not comprehensive for C# users.

After 5 days, I gave up. 😞 I could theoretically finish the game in a certain state, but I decided to focus my attention on other projects instead. I might try to go with this engine later in the future, but for now, I will return to Unity until I finish one of my projects.

A couple of days after the end of the jam, Godot 4 alpha 1 was released. I still think that, if the devs do not provide a nightly version by themselves, my project has some space.

Despite the failure, I’ve learned a lot about Godot, GitLab, and Kubernetes. Especially, the latter two. I will use it in the future for sure, so I do not feel the pressure of failure.

All the code, even incomplete, is open source in my GitLab profile.

Also, they are organizing a Jam every month. I can reuse all to the new jam, for certain.