Penetration Testing Service Providers

Once you have decided to develop a technical team or add more team members to your existing team using the skilled people from Mitrais, you will need to select the right candidate proposed to you by the Mitrais Account Manager.

There are many different styles and approaches to interviewing and selecting technical candidates. Everyone will have their own preferences on how best to conduct the selection. Therefore, I will not be suggesting which approach is best, but instead trying to shed some light on this process based on my experience.

Interview questions and testing for selecting technical candidates usually falls into a couple of categories.

1. Deriving questions based on the candidate’s CV

This approach is one of the most common ones. The interview can be structured by going through the candidate’s CV and asking them to explain in more detail each experience that interests the interviewer. Using this approach, dive deep into the candidate’s their experience and skill set. This can be combined with other types of interview question.

Another popular questioning technique is to ask specific questions related to their experience, what the candidates did when certain obstacles occurred, and what they would do differently now to see if they have learned from their mistakes or experience.

By asking and going through the candidate’s experience based on their CV, the interviewer can get a fairly complete picture of the depth and coverage of the candidate’s experience and skill set. This approach also allows you to assess the candidate’s communication skills.

2. Common interview questions (often asked by the HR staff)

There is a check-list of common questions usually asked by an interviewer from a HR background. They include:

• Tell me about yourself
• What do you know about this company?
• What are your strengths?
• What’s the most enjoyable part about your job and why?
• How do you handle criticism/pressure?
• What do you like the least about your current job?
• Why did you choose this career path?

If an interviewer with an HR background is not on your interviewing team, you should try to ensure that these types of open questions are included at some point.

These open questions allow you to get into more detail to assess what the candidate has done or would have done in certain situations. An experienced interviewer is able to gain more insight about the candidate using this interview technique.

3. Test the brightest minds using generic puzzle questions.

Some interviewers love this type of question to see if how a candidate will react. By including puzzle or problem-solving questions, you can see how a candidate approach different challenges from a simple question (such as why the manholes are round) to more complex questions.

The candidate might try to prepare themselves by reading the typical puzzle questions used in interviews by searching in the internet. So generic questions don’t guarantee that those with the best scores are the brightest – perhaps they are just the most prepared candidates.

4. Assess the candidate by performing a sample real-world task

When selecting a technical candidate, there is no better way to assess their capability than asking them to perform some real sample technical task and assess their performance based on their performance.

For programmers, asking them to solve real code challenges requires them to use real coding skills and show their algorithmic, programming and problem-solving skills.

For testers, asking them to design test cases for a certain type of simple application serves a similar purpose.

The drawback of this technique is that it can make the interview process time-consuming. There are some tools (such as HackerRank) that can help in testing a technical candidate using this approach.

5. Assess the candidate by asking questions based on industry processes and best-practice.

Some questions might include:

• Do you do any unit testing? If so, please explain when and how you perform unit tests.
• Do you perform code reviews? How are they performed?
• Have you prepared test cases? Who reviewed them? How were the tests executed? How were the test results reported?
• Have you ever tried to refactor your code to be more efficient? If so, please explain your experience in doing so.

This interview technique can be quite effective to be able to assess the coverage of the candidates experience and skills in regard to the engineering best practices in short period of time. However, we still need to be careful. A candidate may claim that they always perform unit testing, but that doesn’t necessarily mean that he/she is expert at designing and performing unit tests.

6. Assess the candidate by assessing on their knowledge of the fundamentals of their disciplines.

• For a Java programmer, perhaps ask the difference between double equals (“==”) and the “equals()” method in Java. We could also ask about the differences between the Java SDK and Java Runtime Environment (JRE) , or the new features of different JDK versions (e.g. Java 8 or Java 11).
• For a .NET programmer, we might ask the candidate to describe the architecture of the .NET Framework, and to name the common .NET Assembly.
• For testers, we could ask them to discuss the strengths and weaknesses of domain testing.

This interview style is quite effective and easy to use in assessing the candidate’s technical knowledge, but if the candidate uses different terminology for the same items that we refer to in our technical question, we may need to elaborate more to the candidate on what we mean by our question.

7. Elimination based on role constraint.

We can quickly assess the candidate suitability for the role by directly asking or interviewing the candidate based on constraint for the current role opening. For example, if the candidate must have at least 5 years of experience as a front-end programmer, anyone with less experience than that can be quickly removed from the list.

Another good practice is to have different people in different roles that the candidate may work with interview the candidates (in different interview sessions). This often gives you a more complete picture of the candidate, and can be a good approach since different people naturally see and focus on different aspects when interviewing. It could be a more time-consuming process, though, and may not be necessary if the assignment is a short term assignment.

What are your favourite interview questions? I usually try to combine as many of these types of question as time allows. But often time is not at our side when we are on time constraint. By knowing the characteristics of each technique, hopefully we can make the right decision to choose and combine the right ones in selecting the right technical candidate from Mitrais.

In many software development projects, Agile methods have proven to be a meaningful alternative to other, more complex process models. When using Agile, development-centric models, however, the question regularly arises about how the architecture should be adequately addressed – for example, Scrum does not feature an explicit architect role in the development process.

One of the principles of Agile software development is to make design decisions as late as possible (Last Responsible Moment). Agile suggests not creating a big design up-front (BDUF) for a target system, because the scope of an Agile project is variable in size. A target system often cannot be defined at all because details in complex systems are mostly unknown and emerge at a later point in time. The software development process is also seen as a learning process. The more you know about a domain, the better a suitable design can be created that specifically addresses these unknown details.

This becomes possible because refactoring is one of the typical engineering practices used in Agile teams. Software architecture is understood to be the result of a permanent refactoring and this approach is called emergent design.

Refactoring as precondition

The term source code refactoring describes a process in which existing source code is restructured. The external behaviours and functionality of the program remain unchanged. Only the structures and composition of the source code change.

In addition, refactoring slows down the aging of software, and in an ideal world may even stop it. Already mature software can be revamped with refactoring. This is done by continuously “cleaning up” the code and reducing complexity. The internal architecture is consequently improved, and an object model is created that increases readability and extensibility, leading directly to higher maintainability.

Typically, refactoring involves a set of standardised essential micro-refactoring procedures and practices. Each procedure or practice follows the preservation of the program behaviour, so that the conformity of the functional requirements is maintained.

Modern integrated development environments (IDEs) often provide extensive automated support for the software developer during refactoring. When refactoring, the complexity is reduced and hidden or dormant errors as well as security gaps in the program can often be found and eliminated at the same time. However, refactoring creates the risk that external functionality may be changed, or errors may be incorporated into the source code. It is not surprising, then, that refactoring is an integral part of Test-Driven Development (TDD). Extensive test coverage is a prerequisite for painless refactoring.

Unit Test and walking on the Green-Path

Automatic Unit Tests should be set up prior to refactoring to ensure that routines still behave as expected with the new design. Unit tests can give stability even to large-scale re-orderings. The re-ordering in software design is then an iterative cycle in which a small program transformation is performed, and the software system is then checked for correctness before another small transformation is performed and tested. Through many small steps, each followed by tests, the software moves from its previous state to the desired target state, and new design changes can emerge. For this very iterative process to be feasible, the tests must run very quickly and cover the areas which shall be refactored and its boundaries. Without a proper Unit Tests, refactoring is like balancing on a high wire without a safety net. Refactoring is only carried out if the Unit Test suite, our safety net, is completely in the green phase and all tests are passing. This is the only way to ensure that refactoring does not break anything.

Software Design is emergent

Emergence must be empirically gained, because it has always been shaped according to what was known and necessary. Thus, the emergent design is the sum of requirements resulting from changed intentions and refactoring. But this does not mean that the design also meets the global optimum. And this is the moment when Technical Debt can rise. If design is emergent and disoriented, this can lead to costly refactoring cycles that have to be performed later! A good, sustainable emergent design must be created oriented.  And this orientation must be available where the design is created. Here it stands on two pillars:

• On one hand, the self-organized team needs to know which goals it wants to achieve. Quality criteria, non-functional requirements, existing experience and competencies play a decisive role. In other words, the team must agree –with the business side– what it intends to achieve with the chosen software design and why it wants to achieve it.
• On the other hand, the self-organized team must have a common understanding of what architectural options are available, which ones to choose and when, and how the chosen strategy works. Documentation alone is not enough –this is quickly forgotten as a work artefact in the emergent creation of architecture. It needs a real, internalised image of architecture, its motivations, its options and alternatives.

After all, an emergent design usually depends strongly on non-functional requirements and how and where our design evolves. However, especially in Agile methods, the fact that changes in functional requirements can and should always occur when performing a refactoring cycle addressing design changes with conscious foresight to factors known at the time should be considered.

Through technical excellence of programmers, appropriate refactoring practices, design patterns and the SOLID principles significant design changes can be realised and the emergent design gain maturity as more facts are learned throughout the development cycles.

Is migration necessary? Will it benefit your organization? This infographic presents one path that can be used as starting point for organization to migrate to cloud.

Migrating apps to the cloud has the potential to deliver great benefits to your organisation, but success is contingent on adopting a considered and proven strategy. With a wealth of experience in what works (and doesn’t), Mitrais is a great partner to help you design your migration roadmap and execute it for success.

Even in times of constantly changing requirements and influences, it must be possible to carry out development projects (especially production development) successfully, and in a structured manner. Agile methods can make a valuable contribution to customer satisfaction while at the same time improving profitability. In this article, we examine how some Mitrais clients are implementing Agile techniques, the benefits that can be reaped, and how to avoid some potential pitfalls.

We apply many agile ideas, concepts and practices in product development, which we introduce by consulting with a wide range of customers. An internal survey that we recently conducted showed that 90% of the current 48 projects use agile methods, and only 10% use traditional processes. However, we often encounter large differences between theoretical ideas and practical implementation. The existing environment and the natural inertia to change often require adjustments. In our project portfolio we most frequently encounter the agile methods:

• Kanban,
• Scrum, and 
• Scrum-But.

Since Scrum is a framework, we define Scrum according to the Scrum Guide and Scrum-But as a Scrum method that is either added to or removed from standard Scrum practices. Scrum-But is acceptable as long as the Team have agreed on the reason for the departure from standard practice and have developed their own workarounds. For example: “(We use Scrum, but) (we use additionally a Definition of Ready,) (that we have a working agreement what ready means before a story get accepted into an upcoming sprint between the on-side Team and the off-side Product Owner.)”

We only identify a project as “Scrum based” if it uses the standard 3-5-3 content elements. Otherwise, false expectations are projected into the daily work process and can cause confusion in the team and misunderstandings with external groups (eg: Senior Managers). However, each project is an individual challenge, and the customer’s often express a desire for more traditional processes. But even here, we notice that agile practices have occasionally been adapted in classic project processes. For example, we encounter the Daily-Standup in almost all implemented projects.

Besides Scrum, we often find Kanban as an agile method. And this is no surprise, because the main goal of Kanban is to reduce unproductive multitasking, the frequent switching between different tasks. Kanban is a great choice, especially for projects with a team of 1-3 people. In addition, the visualization of the workflow via a Kanban Board is a strong way to build trust with the customer. Through a transparent representation of the work steps the customer can track project tasks easily and accurately. In addition, the average time between the start and completion of a task can be measured and strategies can be developed together with the customer to reduce this time and keep it as constant as possible.

A concrete process, which may also include parts from the traditional waterfall world, should always be exactly tailored to the circumstances of a project.

Questions we often ask when starting an engagement with a client include:

• Is it a small project and team or a complex project with distributed or even scattered teams or people?
• Is the risk of errors negligible and are there no guidelines, or are human lives at stake and do the relevant legal regulations have to be fulfilled?
• Can the work be planned over a short period of time or does new and important work always arrive unexpectedly and continuously?

Only if the concrete process addresses all these different boundary conditions of a project it can be properly followed and lead to effective work. Together with our experienced Agile Coaches, Scrum Masters and Product Owners, we recommend the appropriate agile methodologies and practices in collaboration with our customers that always keep the valuable characteristics such as iterative development, continuous process improvement, transparency, communication and trust in mind.

In such a diverse project environment like in Mitrais, there are a host of Scrum Masters who deeply believe in servant leadership and help teams to increase their agility while meeting business goals.

If Agile software development actually brings all the advantages claimed, then “What’s the catch?”. In fact, it can be highly inconvenient to a team to introduce agile methods successfully and to maintain them over long periods of time. For this you must break away from old habits, explore new ways and check again and again how you can improve further. This is the constant task of the Scrum Master, who plays a special role in the implementation of projects. Our Certified Scrum Masters have gained experience over a wide range of projects and are there to accompany you so that your projects can also be carried out with higher agility.

Do you have any questions or are looking for guidance on how to improve your Agile Practices? Feel free to contact us.

Whether at conferences or in articles, the term DevOps is currently the subject of lively discussions in the IT world. This interest is understandable, because numerous IT departments are looking for ways to free their companies from the existing mixture of delayed projects, questionable product quality and missed delivery dates.

However, despite all the enthusiasm, there is often a suspicion that not everyone has the same understanding of the term DevOps. This fear increases when CTOs and vendors claim to provide DevOps services or offer tools for them. Against this background, it makes sense to bring together and compare the different, and sometimes ambiguous, interpretations of DevOps.

What is DevOps – really?

By definition, DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems-development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives (https://en.wikipedia.org/wiki/DevOps). In practice, DevOps is a collaborative approach to organisational and process improvement in the areas of development and operations. With a background of finding new methods to increase agility, the term was used for the first time at a conference in Belgium in 2009. Since then, it has been one of the most discussed topics when it comes to the question of the best way of working. Many large companies are now pursuing DevOps strategies.

What DevOps isn’t? DevOps is not a methodology or a process, or a particular bunch of tools or technologies. In fact, DevOps can’t even be clearly assigned to development and operations. DevOps is also not a software-as-a-service application, even though many companies that successfully use DevOps come from this area.

Instead, DevOps is commonly understood as part of the corporate culture with certain principles that a company strives for and embraces in the long term. Supporters of this culture value cooperation, experimentation and a willingness to learn. All those involved in a DevOps culture focus on one goal throughout the entire software delivery lifecycle. Not just in development and operation but also the rapid implementation of stable, high-quality software, from inception to delivery to the customer or user.

Although not mandatory, the automation of software development, testing and deployment through Continuous Delivery (CD) is a recognised k ey factor for DevOps. Automation enables faster software implementation and ensures that solutions have the required quality, security and stability.

Defining DevOps

In simplified terms, DevOps focuses on bringing together all participants in the software development cycle at three levels: People, Processes and Tools.

DevOps can be defined and described in terms of very different models, all of which are correct in their own way and can lead to a deeper understanding and a seamless introduction. A good example can be found in ‘Three Ways of DevOps’ in Gene Kim’s book ‘The Phoenix Project’. The three ways describe intersections between systematic thinking, reinforcement of feedback loops, continued experimentation and learning at its core.

Another model is an acronym called C.A.L.M.S. According to DevOps pioneer John Willis, the five basic principles of C.A.L.M.S. are needed to establish a DevOps culture in the company according to the motto, “Keep C.A.L.M.S. and carry on”:

• Culture describes a safe environment for innovation and productivity. To create this, the boundaries of the individual areas must be broken. Separated groups of developers and operators each pursuing their own goals will no longer exist.
• Automation refers to the conviction that optimisation takes place through automation. Process automation creates consistency, saves time and avoids errors.
• Lean means avoiding waste and still achieving the desired results. Process optimisation must be seen holistically, and transparency is required for this.
• Measurement defines uniform evaluation criteria that must be created. With these, a continuous improvement of the processes is possible.
• Sharing serves as the basis for joint communication. This includes the willingness to share knowledge and to learn from each other, as well as the proactive sharing of knowledge.

These five principles form the basis for more efficient cooperation and better quality product. DevOps itself is more than a tool and simple automation. All the above building blocks for DevOps are equally important for a successful DevOps implementation. but at the core of DevOps are the people and the way they collaborate with others.

Establish DevOps as culture

Developing towards DevOps means that a cultural change usually needs to take place. Teams in development and IT operations work together to deliver mutual value throughout the entire lifecycle of the product.

With Continuous Delivery as its key factor, DevOps creates previously unknown transparency. A build monitor can be used, for example; to show the current state of the software. This can be done very granularly, i.e. each individual step (build, unit test, integration test, acceptance test, metrics, deployment on target system, etc.) is directly visible on such a monitor at any time. Once DevOps is established, not only can the state of the software be visualised, but the state of the infrastructure is also transparent. Monitoring not only gives feedback to the Ops team on their computers but is also available to developers in the same way, making the entire team feel responsible for the software. Regardless of whether the server monitoring is reporting problems, or a unit test fails, or unexpected errors are logged in the application logs, the team immediately recognises that there is a problem with the application and takes care of it – in line with the principle of collective ownership.

It is important that the movement toward DevOps is supported at the management level because it requires the dismantling of functional silos, an initial investment in hardware and software for automation, the changing of work environments and the recognition that cultural change takes time and cannot simply be introduced into the company overnight. The way in which software is developed and operated is changing noticeably, but the advantages are obvious and are usually already demanded by management: Shorter time to market, stress-free regular releases, higher quality, transparency and high-performance teams – what more could you want?

Continuous Integration is an established practice in software projects to continuously merge the source code changes made by different developers. Generally, the process can be divided into 2 steps; the compilation and the testing process. This article highlights some of the challenges that can arise in the area of testing in large projects.

In modern projects, a large part of testing is fully automated. Techniques such as Test-Driven-Development (TDD) have a proven positive influence on project progress, architecture and coverage. The number of tests available for execution increases continuously due to such methods. Ideally, all automated tests that exist would be executed with every change to the source code. This would ensure that functionality already implemented is not broken by new changes. However, new challenges are not considered in the literature on Continuous Integration. Initially, all tests can and should be executed with each change. But we are neglecting the factor for the execution time for the test-suite, which is constantly increasing, sometimes up to several hours. This leads to long feedback loops which we try to avoid. The following five factors can cause Continuous Testing to fail.

Test Level Not Used Correctly

Ideally, the distribution of the tests on different levels results in a pyramid ascending from unit tests as the foundation, to integration tests and system tests at the top. This is known as the Test Pyramid metaphor from Mike Cohn.

However, in many projects we find an inverse pyramid, the so called Icecream-Cone, in which most of the tests are at a very high level. At worst, all tests are UI-based or manual. These tests should be the smallest part of the test-suite. But why does this have a negative effect? Tests at higher levels have some or all the following negative characteristics:

• High execution time
• High analysis effort in case of failure
• High maintenance requirements (especially for UI tests)
• Increased instability during test execution

On the other hand, it does not make sense if a test suite only consists of unit tests. These test very quickly whether a change in a local area has broken the existing functionality, but not whether the individual parts of the software work together correctly. Therefore, it is essential to bring the number of tests on the respective levels into the form of a pyramid. Each of these levels covers a separate aspect that should be tested, from the functionality of individual classes to that of the entire system. It also tests whether the system meets the non-functional requirements.

Tests Are Not Continuously Improved

Unit tests are ideally continuously adjusted and improved together with the product code. As a result, the aging of the code is usually not a problem. As soon as you approach the system level tests, however, you will increasingly see the phenomenon that the test code is no longer considered once it has been added to the source code management. Over time, especially on the higher test levels this can lead to problems. Test-suites that initially ran in a few seconds can last from minutes to hours.

In addition, technical debt can accumulate in the tests, such as duplicated code or lack of refactoring. As a result, the test-suite is increasingly difficult to maintain. You can then find yourself in a situation where it is more time-consuming to adapt the tests than to implement the product. This is why the quality of the automated tests must be continuously improved. For example, you can analyse the five slowest tests in each iteration to see if you can speed them up.

Unstable Tests Are Not Treated Separately

In every large project there are tests that deliver a non-deterministic result (Flaky Tests). They should not exist but, but they do! The automated triggered build process in our Continuous Integration practices is therefore sporadically green or red. This reduces confidence in our Continuous Integration System.

This problem should not be ignored. If you look at the “Broken Window Theory”, which says that you start to neglect something as soon as the first flaws appear, you start to ignore the Continuous Integration build results. Statements like “I’m done when 95% of my tests are green” or “These five tests fail sporadically, but everything works” are the result. But what if it’s 94% instead of 95%? Or if six tests fail instead of five at once? Or five completely different tests fail, and nobody notices it because you only concentrate on the number of failed tests?

In a system that continuously performs automated tests, unstable tests should therefore be treated separately with a separate process. Martin Fowler used the term “quarantine”. In principle, the point is that a test that fails sporadically should not be included in the normal test-suite. Much like a highly contagious disease where the infected persons must be quarantined, these tests should be removed from the normal execution to prevent the results of the build from being ignored. The tests must of course be examined and then either the product repaired, or the test corrected. If the problem cannot be solved within a few hours, this should be done outside the normal build process to avoid it not having a positive outcome. With the introduction of Test Quarantine, it should also be monitored how many tests have been quarantined to avoid that suddenly there are no more tests in normal test execution.

Tools Are Too Complex

Another possible error is that the tools used for Continuous Integration and Continuous Testing are too complex. They should be as easy to use as possible, since they are used several times a day by almost all developers and testers. However, this also means that the tools cannot be considered separately for the “compile” and “test” areas. These aspects must go hand in hand to make daily work as easy as possible for all involved. What can be expected from a test should be clearly defined in terms of its behaviour and what should be the task of the infrastructure. In this way you can decide what measures are to be taken using the tools, and what is the responsibility of the tests. Typical examples are configuration changes that a test makes in order to be executed. The test is responsible for resetting them (even in the event of an error).

No Test Architecture

In many projects, test code development is still not considered software development. But in fact, they are the first class citizens of your product code. In complex projects, test code development is a big challenge and must be approached with the same software development methods as product development. If the quality of the product code is poor, an automated test suite with good quality is required. This allows you to gradually increase the quality of the product code and rely on the safety harness of high-quality tests.

However, if the test code quality is not good either, the correction of errors found in the field will cost a lot of time. This means that a high proportion of the costs are incurred after the actual development, i.e. during the maintenance phase. Therefore, it is important to set up an architecture with clear rules for the test code, and to measure the quality of the implemented code. At best, the architecture of the test code is described in the same way as the architecture of the product code to ensure that all project participants can read this documentation in the same way.

Summary

Continuous testing in large projects is not impossible, but it is a challenge. These five points cover a large part of the possible difficulties. However, the challenge should be accepted, as Continuous Testing can significantly impact the development of software and reduce the fear of changes in an existing system. It is an investment in the future.

The Spring Framework is a Java application framework that is powerful yet lightweight compared to the Java Enterprise Edition. It also provides an abstraction to other popular frameworks such as Hibernate, Thymeleaf, JMS, etc, so they can be easily integrated. Discover the path you should follow to become a Spring Framework Ninja here.

The frequency with which new programming languages see the light of day is continuously increasing. One of these, Go, is a relatively new programming language that is becoming increasingly important. Go programming language, which was only introduced to the public in November 2009 and declared ready for production in May 2010, has been growing strongly in popularity for some time now, because with every technical development and every new programming concept, deficits are revealed in the established, old programming languages. No other language has been able to grow so rapidly in recent times.

But, what exactly was the main driving force behind the development of Go? Simply, there had been no new major system language for a decade. Technical peculiarities in the underlying environments of software solutions changed dramatically. When Rob Pike presented Go in the Google Talks in November 2009, he spoke of:

• Applications that have extensive libraries and dependency chains
• Dominance of networking
• Client/Server Focus
• Massive Clusters
• Multi-Core CPU’s

In application development, all these points are now gaining more importance. However, system languages were not designed with all these factors in mind. So, what exactly differentiates Go from other system languages? Let’s discuss this in this article.

Two Worlds United

Go (often referred to as GoLang) is still considered a new programming language, even 10 years after its release. The development of Go was driven by Google to increase programming productivity while addressing the environmental characteristics mentioned above. Go programming language itself is imperative and modular, borrowing from object orientation and functional languages. Experience with numerous languages, including C, C++, Java, Perl and Python, was incorporated into the development. However, Go is syntactically similar to C, but with memory safety, garbage collection, structural typing and Communication Sequential Processes (CSP) concurrency [1].

What is impressive is that Go has been consistently designed for practical use and almost completely does without the introduction of entirely new features and paradigms. It is an imperative programming language, i.e. the instructions of a program are processed in the order of the source code. Parallel processing is possible both explicitly (using goroutines) and implicitly (by reordering in the compiler and or the CPU). However, when accessing global variables, there are precisely defined rules for sequence and synchronicity.

Go is also modular. Each program consists of one or more modules (packages). Modules specify namespaces that cannot be broken, and visibility rules for self-defined variables, functions, and other identifiers.

Go has some characteristics of functional programming languages such as First-Class functions (functions that can be used as parameters or return values of other functions) / High-Order functions (functions that have functions other than parameters or return values), functions with multiple return values, variable functions, anonymous functions and closures. However, Go is not a real functional language. For example, functions can have side effects, and there is no strict call-by-value semantics.

Developers do not refer to Go as an object-oriented programming language, although many of the properties of object-oriented languages are present. There are no classes; instead, methods can be defined for all self-defined variable types. There is no inheritance hierarchy, but in many situations similar structures can be achieved by composition, i.e. a data type contains another type and uses its methods. There is no access control to the data of an object; instead, the visibility rules for modules can be used as access protection.

Interfaces are a central concept of Go. These define a list of methods that a data type must have to correspond to the interface. If this is the case, values of a specific type can be assigned to interface variables. This makes polymorphism possible: any objects can be passed to a function whose parameter is an interface variable, provided the type fulfils the interface. The function can call the methods defined in the interface directly.

Go supports concurrent or parallel programming through goroutines. These are based on the Communicating Sequential Processes defined by Tony Hoare in the 70s. A goroutine is a very lightweight, concurrent execution unit. Initially, it needs only about 2 kB memory, so that one million and more goroutines can quickly be started on current systems. Other parallel languages, on the other hand, often map concurrency to operating system threads, so that several thousand of them are already problematic. For concurrent programming, there is the data type Channel, which implements a type-safe communication channel. It is used for the exchange of messages and between goroutines. There are buffered and unbuffered channels; the former has an adjustable capacity for buffering messages and thus support pipeline-like data processing. Unbuffered channels enable bilateral synchronisation between goroutines.

Simplicity Is The Key

There are only 25 keywords in Go (cf Java’s 57 reserved keywords [2] and Python’s 33 reserved keywords [3]) and 39 additional predefined identifiers. These keywords define the basic syntax of Go programs and must not be used as names for self-defined variables, functions or the like. In Go version 1 (go1.12.4 was recently released), a guarantee was made that no further keywords would be added to the language. If this happens, the corresponding words will no longer be available for custom definitions, and existing programs might no longer be compiled.

In comparison to language monsters like Java, Go has a minimal amount of language resources. Within the 25 keywords, there is only one loop (for-loop), there are no classes and no inheritance, there is only one form of interface, there is no generic programming, there is no pointer arithmetic, there are only two levels of visibility (public and private), there are no constructors and destructors, and minimal reflection. Even though these limitations exist, they do make the language very easy to learn.

In addition, Go is a statically typed programming language. Errors in the use of types are flagged during compilation and cannot cause a program to crash at runtime which makes it faster to identify flaws in the source code. Conversions between types are possible within certain limits, but in contrast to other languages, they must be explicitly written out to avoid ambiguities and accidental conversions.

As mentioned previously, there is only one type of interface that can be used to implement Polymorphism. An interface variable can be assigned values of different types, provided they match the interface, i.e. have a specified set of methods. Type assertions can be used to recover the original data types, whereby runtime errors are possible if not all possible states have been considered during programming.

In Go, it is not possible to explicitly delete an object. The runtime environment automatically recognises when an object can no longer be used (for example, because the scope of its visibility has been left and there are no references to it), and deletes it using automatic memory clean up. Since the deletion takes place later, a Go program often uses more memory than a comparable C or C++ program. However, the garbage collection prevents an object that has already been deleted from being referenced again. This avoids other objects being accidentally overwritten without control, potentially preventing a program crash.

Future Development Perspectives

The simplicity of its neat syntax and the very high performance and low memory footprint are the most significant advantages of Go [4]. Go runs directly on the underlying hardware and is not executed on a virtual machine, like Java, which means that program code is compiled directly to a binary file, making it faster.

The low memory requirements of the Go programs and the integrated parallelisation make the programming language particularly suitable for specific application areas, such as use in the cloud.

Go programming language is easy to learn, especially if you already know another programming language.

Go code contains practically no surprises. Its limited language resources lead to an absolute uniformity of the source code (independent of the author) which facilitates later maintenance. One could also say that tedious code is good in the long run. Go is platform-independent and can be used on different operating systems by just setting an environment variable before compiling the package. There is no additional runtime necessary for the target environment that needs to be managed.

Ref:

1. https://en.wikipedia.org/wiki/Go_(programming_language)
2. https://en.wikipedia.org/wiki/List_of_Java_keywords
3. https://www.programiz.com/python-programming/keywords-identifier
4. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html