Python is 72x slower and uses 76x more energy than C

According to a recent study named “Ranking Programming Languages by Energy Efficiency” conducted by several institutions in Portugal, Python is incredibly energy wasteful. In addition, Python is also extremely slow when compared to the C programming language. See table below:

This comes to no surprise to me. Interpreted languages like Python, Perl, Lua, JavaScript, TypeScript etc. are by their very design, slow and energy wasteful because priority has been put on “ease of use” for programmers. This comes at a very heavy price: slow performance and energy wastefulness.

Compiled languages like C will always be outperforming and be much more energy efficient because C is much closer to the hardware and operating systems than interpreted languages.

Do people or organizations care of wasting energy and have lousy performance? They should. If organizations do not care, your customers eventually will see a difference in quality between scripted languages and taking the time to produce fast and energy efficient code. One can always see a difference between native applications and scripted/browser applications.

For example, let’s say you are creating a cloud-based applications that uses AWS Lambda to execute your functions. If that Lambda is written in Python, you are wasting time and money. Since Python so incredibly slow, you are being charged in 100ms increments when you execute your Lambda function in AWS. Now, imagine your Lambda function is written in C? Your Lambda function will execute so much faster and you are being charged much less. It will be more cost efficient to execute in C rather than Python. So, it would be cheaper and you are contributing to a lower energy consumption.

The same idea can be applied when you create a Linux daemon service, a Windows service, or even a native Linux, MacOS, or Windows application. Have a look at NappGUI, a cross-platform C SDK that allows you to create super fast and beautiful C applications.

C is a really powerful language. Have a look at it and start using it in your next project.

Proposed book about Event Sourcing & CQRS

For years, I wish I had a source that I can direct people to learn more about Event Sourcing & CQRS. Greg Young never created a book, sadly. The difficulty in Event Sourcing & CQRS is not so much the technical side but, as usual, the people you need to convince and work with. Typically, Event Sourcing allows for capabilities in your software that are extremely hard or almost impossible to do with old style software development. It is fairly easy to convince executives, product, sales, etc. that these new capabilities and insights for your customers can easily beat competition. So, why is Event Sourcing not used in like 85% of all software projects? I believe that there are different reasons but at the core, where can people go to? The Web? The Web shows all sorts of different views and many of them show inexperience and brushing Event Sourcing off as “too difficult” or “increased complexity”. WTF? Software by it’s definition is hard to do properly if you stay aligned with the business and the vision your organization has. I argue that Event Sourcing makes this actually easier, not harder!!! The CRUD virus shows its ugly head again!

So, after years of not having a great source for people to direct to, I’ve been seriously thinking of writing a book about Event Sourcing and CQRS. I have not pulled the trigger because I know this a huge time commitment. However, I did create a six page table of contents and surprised myself of how much information can and should be shared on this topic. This book would be very comprehensive and covers Event Sourcing from every angle including the business and customers side and not just the technical side.

My question would be, are you interested in this type of book?

My new course on Udemy: Build an Event Store in C# .NET for CQRS and Event Sourcing

I’m excited to announce my new course “Build an Event Store in C# .NET for CQRS and Event Sourcing“.

Real-time communication and feedback to your customers are more important then ever. Customers have become used to immediate feedback on the actions they take in your software. It is very hard in create, read, update, and delete (CRUD) based applications to provide this sort of responsiveness that your customers are demanding. Event-based solutions that are based on CQRS, Event Sourcing, and Domain-Driven Design (DDD) can offer deep insights in real-time to your customers and to your business. More importantly, you won’t loose data in an event-sourced solution when compared to CRUD-based solutions because your solution will be able to provide the context on why changes happened and record changes into an immutable log, the event store.

In this course, you will learn about the importance of using domain events as your source of truth instead of pieces of data that are incomplete in CRUD-based applications. You will be able to tell stories on what happened when and why. You will be able to answer future questions by your customers and business even though you may not have all the requirements at hand when you design and build your event-sourced solution.

At the very heart of your solution will be the event store. The event store is the source of truth in your entire solution. We will be building an event store in C#. NET and utilizing AWS DynamoDB as the persistence mechanism. However, the provided C# source code can easily be converted to Java or other languages. For the actual persistence, you could also use MySQL, PostgreSQL, MongoDB, and others. The C# code is abstracted so that can you can re-use it for specific persistence implementations. The concepts and code can work for on-premise, cloud only, or hybrid models. For an example read model implementation, we will be creating a read model using MySQL in AWS.

Once you understand the power of event sourcing, you won’t go back.