Go, la propuesta de Google
I know I wrote this before, but this week has been one of the most I’ve had to learn.
The context is this, I’m targeting a backend developer position with Go (Also known as Golang).
I tell you that Go is a young programming language that has the support of Google, so it’s without any doubt a language that’s here to stay and whose performance in data science and backend field is remarkable.
Some of the things that make Go special is that it’s compiled, statically typed (that means, you have to specify the data type you’re going to work with), if you don’t add a data type, Go will assign it a default value, in fact, that’s a great advantage to do data science since when cleaning data frames null values are usually a problem. The fact that Go does not have null values facilitates this type of work.
Another thing that this language stands out for is concurrency, this is a somehow difficult concept to understand by its very nature but the idea is that Go can only do one job at a time, so in order to work efficiently (otherwise we need to wait until one task is done and that maybe will be a little tedious) Go does is assign a delimited time (not more than a few milliseconds) to each task, pause it if it is not finished, go to the next task, work on it for a similar time to the previous one, pause the second job if it is not finished, tackle a third and so on until it eventually returns to the first task and the cycle continues until one activity is finished. Although Go does this natively, it’s possible to control this behavior through a concept called “goRoutine” (also called a thread in other languages), each task is assigned to a “goRoutine” and it’s possible to create “channels” that collect several “goRoutines” (we can also choose how many goRoutines a channel will contain).
This concurrency concept is an interesting topic but it can happen that two tasks want to access the same value, this would potentially create a disaster, especially if both goRoutines will modify the value while working with it, that’s why Go has a library called “Mutex “ which prevents this happening by isolating a variable that works with a goRoutine and releases it until one goRoutine stops using it.
As you can see, Go is a great language full of peculiarities.
Another thing I learned this week is the answer (complex by the way) to the question of why do technology projects fail?
This is generally due to communication problems, whether it’s problems when communicating the true size of a project, an error in the quantification of resources that a project requires, or simply because the development team has poor communication which can lead from delays until rework of software parts. The result of all of the above is always a failure in the project, these failures can cause severe damage to the company that implements them, such damage can range from simply stopping the project and not continuing it again, through losses economic unsustainable for the corporation, until the bankruptcy of the same company.
This is why agile methodologies are so important in this industry as it helps to detect problems before they become unsustainable.
I think at in the end we can all learn from agile methodologies and implement in our lives this way of looking the life, it’s better to correct small tasks soon instead of working on a gigantic task that possibly has errors, which they will be very difficult to fix and may not even be fixable.
