(WARNING: Too much Odin can cause baldness and overgrowth of ginger facial hair)

It is too late

A month has passed from the day I started learning about Odin, and it seems there is nothing more to learn.

Today is the day I am deciding if I will keep using the language or move on.

However, there is no free will to move away from Odin. If you learned about Odin, then you are doomed to stay in Odin forever. It is like gravity, and as many people are learning Odin, then the more powerful the gravity becomes.

The only thing that I can do is to explain scientifically how Odin will pull everyone and everything until all we become a ginger sun.

How everything started

Ginger Bill, the creator of Odin, said in his X profile that he does not have a soul.

He created Odin to feel a bit of joy, but little did he know that he created a soul.

A soul that pulls every soulless person on earth.

And do you know who else does not have a soul?

Gen Y and Gen Z because they grew up with doomscrollers in their hands and everyone knows that doomscrollers are soul blockers. So our main workforce of Gens grew without a soul.

If you know the characteristics of Gens, then you know that

• they are soft.
  • For example, if tax filling causes them stress, then you can guess what borrow checker, macros, and Kubernetes do to their health.
• they have short attention span
  • For example, if they start watching a course, then automatically will redirect themselves to TikTok
• they are entitled
  • For example, they expect AI to write their code

Rob Pike defines them even better “They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software.”

However, thanks to Odin, all these soulless people now have a soul. These are the three elements that makes Odin a soul:

• Nothing in Odin is complicated
• Odin encourages people to learn by reading code instead of watching courses.
• Odin restores the joy of programming, and no one is inclined to delegate such pleasurable tasks to AI.

Now all the soulless people will want Odin to flow to every software on earth, until everything becomes orange.

Jokes aside, there is a fourth element that will change the course of software development as we know it.

The fourth element

The fourth element is letting errors to be any type.

I tried to explain to developers how important it is to let the errors be free and be whatever they want. I even created a challenge for the developers to realize on their own that free errors are doing a better job than slaved errors. But the challenge nearly downvoted because of how I asked them to take the challenge.

However, no matter how I speak or how much I have offended your pro-error-slavery programming language, it will not change the fact that free errors will change the course of software development as we know it.

First, I will reply to the responses that I received the last two weeks for the challenge and later on, we will see the future together.

“no one design functions like this”

No, we used to write code like this, but this changed after the economic crises.

Before the economic crises, we used to design our applications around MVC architecture. We had large monolithic code bases created using Waterfall methodologies.

After the economic crises, everything became “Agile” to reduce expenses. The reason that Agile is less expensive is that it understands that tracking and handling errors is difficult when the stack trace increases to more than two functions. For example, MVC is three to four layers of functions in each stack trace, and they replaced it with Component-Based Architecture to reduce the stack trace to two functions at most.

Moreover, moving to smaller stack traces for our errors, had as a consequence to change software architecture from monolithic to microservices and serverless. This way “Agile” moved our error handling away from the software itself to other services like loggers, OpenTelemetry, Kubernetes, Elasticsearch, etc.

But what we have seen from all these years of experience, is that all the “Agile” is still expensive. I am not talking only about the bill you receive from the cloud provider for setting up microservices, serverless etc., but also the technical debt from all this complexity.

This complexity created because programming languages cannot parse stack traces, and so we made other services to parse stack traces using configurations or fake languages.

For that reason, DevOps and SRE are paid more than the developers, as it is more complex to handle the errors from microservices than to develop the microservices.

“no one parses the stack traces”

Correct and certainly, they shouldn’t try it because they would do it in the wrong way, like using strings.

It is like asking a handicap to start walking.

Odin, on the other hand, can do it because the switch statement can parse and type check the stack trace.

This means that Odin does not have any problem with huge stack traces, and, for that reason, it is a great tool for creating monolithic applications.

We can even start a new challenge from this, which application has the biggest stack trace.

“it is too academic”

There is no academic paper that says Union types are better than error types and exceptions.

And there is no academic paper for writing better monolithic applications.

It is a discovery that will revolutionize the way we develop software from now on.

However, people who haven’t used Odin yet, can’t see the big picture.

The big picture

Let me paint it for you, using all the elements of Odin into account.

Odin will free you

Odin is not only simple that takes one week to learn, but you will not need to learn software engineering methodologies because in Odin there is only one way to do each thing.

You can do this thanks to Odin’s restrictions like:

acyclic dependencies
no classes
no interfaces
no macros

This way, you will not waste time on design patterns or other academic theory. For example, do you need to create an ORM that accepts DB drivers? Then just create type procedures for other developers to implement the drivers.

Do you want to create a parser for a markup language? Then just use struct tags with similar conventions to other libraries that use struct tags.

If there is something that you can’t do in Odin, then there is a good reason not to do it anyway.

Which also means there is only one way to read things, making the code readable at first glance. This will help you review code faster than any other programming language.

Moreover, Odin will free your mind from anxiety thanks to its stack trace parser and testing suite. You will literally be able to predict future stack traces through unit testing. This way, you will do a code coverage that in other languages you couldn’t.

If Odin becomes your main programming language, then you will have spare time to find a girlfriend and touch some grass.

You will even start remembering names.

Odin will map the software for you

Odin does not have classes or interfaces, which means that you cannot use UML to architect your software.

But if you start wondering, how can you live without UML, then I have good news for you! You don’t need to map anything because everything is already mapped for you automatically when you start coding.

For example, let’s examine the types from the challenge’s solution in Odin

F1_Error :: enum {
	None,
	Account_Is_Empty,
	Investment_Lost,
}

F2_Error :: union #shared_nil {
	F1_Error,
}

F3_Error :: union #shared_nil {
	F1_Error,
}

F4_Error :: union #shared_nil {
	F2_Error,
	F3_Error,
}

If you consider each one type as the specific error type for each function, then you can create a mental model in your head like this one.

Which means that you can architect your applications by coding.

You can even lock your architecture by creating tests that will type check any changes from naive developers.

However, the most important feature of Odin, is to help you architect the software around its errors because the errors define the software.

If you don’t believe me, look at the above code. You can’t read the names of the functions, and yet you know that it is for a bank based on its errors.

This is how we define everything in the world. Each word is defined by its errors.

For example:

• “Drunk” has errors like, the person can’t see clearly.
• “Woman” has errors like, the person can’t pee standing up
• “Friendzoned” has errors like, the person can’t get laid.

Odin just invented a new philosophy where the errors define everything because we let errors be any type.

Not only that, but by defining first the errors of your software and designing their stack trace paths, then you not only architect the software itself, but also you bulletproof each use case from any unexpected failure.

Odin will create the Tower of Babel

Odin already attracts developers who want to write monolithic applications like Games, but I bet in a year from now it will start attracting companies to develop even larger applications.

These companies will use Odin as the common language for all of their teams to replace protocols. For example, each team will work on a list of packages as a part of a monolithic application. For each package, the developers can prepare types for other teams to use as substitute for testing on their packages. Thanks to Odin’s test suite, stack trace parsers and procedural design, developers can test and finish their packages without waiting for other packages to be ready.

Furthermore, parsing stack traces in tests, will make sure that coworkers will not touch important logic. You will create tests that lock the code with type checking. For the first time, it will be possible to do full coverage of our code for all stack trace paths and write monolithic applications without technical debts. For example, imagine you’re working in Odin for a company and one day the boss tells you to use a library from another team. The library is not ready yet, but you can use its types for mock tests. The next day, you pull from git whatever updates are ready from this library and then the compiler throws an error that a switch statement from mock tests misses a case for a new error type from that library.

To realize how significant this is, then just remember how many times you have changed a code that you shouldn’t have touched. This is the cause of most technical debts in history.

Odin will make the developer reach O(1) development time, no matter how many new features are added to the application, while for other programming languages will be O(n!).

This will change how IT companies are structured. For starters, it will replace the workforce of DevOps with developers as there will be no need for Kubernetes, telemetries, cloud providers etc. Just using a Docker Swarm on dedicated servers will be enough.

Not only that, but please keep in mind that Odin is as fast as C, and it compiles code faster than C. These attributes alone will reduce the costs in hosting for production and CI/CD.

If you don’t believe me, then just ask your boss “I found a programming language, that you can learn in a week, it is as fast as C, it compiles code faster than C, and it is created to develop humongous monolithic applications by large and multiple teams of developers. Is it a good fit for our use case?”.

If he/she is hesitant to respond, it may be because they are translating AWS bills to yachts.

Monolithic applications are smaller, faster, and simpler than the same applications in microservices, however only Odin can help you create them without making your life miserable.

If Odin is the only programming language out there for building monolithic applications, then you can imagine what will happen in the near future.

If you can’t imagine it, click at your own discretion

Learn Odin if you want to have a job in the future.

PS: Yes, the ginger beard with residing hairline is the mascot of Odin