Después de evaluar Go, durante las últimas semanas, debo admitir que... me gusta. Debe ser entendido como un C extendido, más que como una variante de C++, pero que soporta ciertos características de POO (programación orientada a objetos).

Es decir, uno podría pasarse a Go sin echar de menos, necesariamente, características de objetos. Se aprecia desde el principo que la idea es simplificar, siguiendo las conclusiones más actuales sobre POO, dejando de poner tanto énfasis en clases y herencia (aunque se soporta de alguna forma), y sobre todo, poniendo el énfasis en el polimorfismo.

Así que... definitivamente, un programador de C se sentirá muy cómodo en Go, probablemente notando que está utilizando un C mejorado con algunas extensiones de POO. Un programador de C++, Java o C# puede también sentirse cómodo, sintiendo que tiene que adaptarse, en cierto sentido, a algunas restricciones.

Por supuesto, no todo es mágico en Go. Ya he dicho que me gusta, pero tengo las siguientes espinitas.

  1. El sistema de paquetes. Si pones package x, tienes que tener ese archivo x.go en su propio subdirectorio x. Es decir, si decides reorganizar la estructura de tu aplicación, te encontrarás que tienes que rehacer la estructura de directorios, y también renombrar los package dentro de los archivos Go.

  2. Compilación de paquetes. Afortunadamente, un package se compila solo una vez (al contrario que en C, donde es necesario crear las famosas guards). Pero... no se permiten relaciones circulares. Es decir, la estructura Punto de un paquete A puede hacer uso de la estructura Lector un paquete B. Pero en ningún caso desde el paquete B se puede hacer referencia a Punto del paquete A. Para superar esto, será probablemente necesario crear una interface para la estructura Lector. Quizás pueda ser posible refactorizar ambos paquetes para eliminar el mayor número de dependencias. Esto está lejos del soporte de Java o C#, que automáticamente crean lo que sería equivalente a las interfaces de las clases, con el esqueleto de las firmas de los miembros públicos. Aunque es verdad que esto puede crear módulos excesivamente interdependientes (esto es bueno), también limita ciertas prácticas, como por ejemplo tener todos los métodos que leen una determninada estructura todos juntos en un package, si no se es cuidadoso.

  3. La implementación de la herencia. Si pones una estructura A dentro de una estructura B, en la práctica, estás haciendo que B derive de A. De hecho, B podrá hacer uso de los métodos definidos para A. Por un lado, colocar la estructura A dentro de B parece indicar que tendrás que apañártelas tú mismo con la herencia, cuando es obvio que el compilador va a ofrecer cierto soporte automático del que, al principio, puedes no ser consciente. Personalmente, me gustaría una sintaxis del tipo type B struct: A o algo parecido, lo que ya sugiere que el compilador va a ofrecer un soporte de la herencia explícito.

¿Y tú? ¿Has probado Go?