Error checking is a complicated problem. It is like a garbage problem; everyone produces garbage, but no one wants to pick it up. Errors come from code that might behave unexpectedly due to forces outside of the developer’s control. Code accepts user input, and it will do its best to make sense of it, but there are scenarios where it is not possible for the code to handle the data that it was given (the code does addition but gets “hamburger”)....
Underneath the syntax and runtime is a very important system that is often overlooked in a language. Usually, there is “the person” who built the language, and successful languages often come from the person wanting a language to suit their needs, not finding one, and then making their own. Over time, more people want to use the language, and balancing constraints of what is included or not included in a language becomes challenging....
Even though the “go” keyword is the same name as the language, you would think this is more commonly used. From my experience, go developers, including myself, will avoid using go routines and channels as much as possible. The reason is that it adds complexity that you often don’t need. Concurrent code unlocks a lot of performance as tasks that would otherwise “stop the world” only stop the go routine that they are on....
In the realm of software development, the dichotomy between local development environments and production settings presents a notable challenge. The ideal scenario is where both environments mirror each other as closely as possible, minimizing discrepancies that can lead to unexpected behaviors upon deployment. However, achieving this level of synchronization is fraught with complexities. Tools like Docker have emerged as potential solutions, offering the promise of containerization to encapsulate applications in self-contained units that can run consistently across various environments....
Dependency injection has radically increased my programming rate. When everything is designed as a module, you find yourself constantly reusing things you have already written since it is the path of least resistance. If you try to do this without the help of a framework, you will find yourself writing and rewriting the boilerplate code to connect dependencies together. Most DI frameworks resolve dependency graphs at runtime https://github.com/uber-go/fx A dependency graph resolved at runtime is error prone and leads to confusing code....