Impresiones Go (golang)

Tal y como todos sabéis (después de la paliza que he dado durante estos días) durante la PiWeek me dedique a aprender el lenguaje Go.

Este post resume mis sensaciones sobre este lenguaje en el poco tiempo que lo llevo usando. Desde luego estas son mis opiniones, son intransferibles y cambian con el tiempo... (como todo).
:-)

Me ha gustado

• Facilidad de expresar concurrencia. Esta parte en realidad me ha encantado, definir patrones de concurrencia usando comunicación por canales ha resultado muy sencillo y en nada de tiempo he desarrollado soluciones que solo de pensar en desarrollarlas y depurarlas en C++, me da dolor de cabeza. (Entiendo que los patrones aprendedidos en la ErlangCamp con actores y todo lo leído sobre sistemas distribuidos ha ayudado a que resulte fácil).
• Me ha encantado la eficiencia en memoria de las soluciones generadas (comparando con el equivalente en python, ruby o en java).
• Da gusto ver los ocho cores aumentando y disminuyendo su carga de forma uniforme. :-)
• Generar  binarios estáticos o dinámicos que sólo dependen de la libc o la libpthreads es una delicia, sobre todo cuando tienes máquinas con distintas versiones de linux. Los despliegues se simplifican de forma brutal... quedando reducidos a un scp :-)
• Orientación a Objetos, muy sencilla, siempre y cuando estés acostumbrado a hacer diseños en los que predomine la composición. Si eres de los que piensas que Orientación a Objetos es diseñar jerarquías, estás en un problema (en mi opinión, tanto en Go, como en cualquier otro lenguaje Orientado a Objetos).
• Inferencia de tipos, hace que tengas las ventajas de un lenguaje estáticamente tipado sin tener toda la verbosidad.
• Gran cantidad de documentación de alta calidad (charlas, ejemplos, libros). Esto desde luego tiene que ver con que han decido estabilizar la versión 1.x del lenguaje y ser muy conservadores en cuanto a los cambios.
• El compilador es MUY rápido y el ecosistema es muy simple, lo que permite que el flujo de trabajo en cuanto a trabajo con tests, y feedback casi instantáneo, sea muy similar a trabajar con lenguajes dinámicos como python y ruby.

No me ha gustado

• Aunque es algo más difícil, puedes liarla con los punteros. 
• Se da bastante flexibilidad para cualquier solución de concurrencia, incluidas algunas formas de solventarlas que pueden ser peligrosas (Mutexes que dejemos sin cerrar, semáforos, etc). Por otro lado el lenguaje 
• Evidentemente es un lenguaje de un nivel de abstracción bajo/medio, que permite estar en contacto con los tipos de datos a nivel de procesador y usar los recursos de una forma eficiente, pero en ocasiones echo de menos construcciones más expresivas y compactas de otros lenguajes de más alto nivel (bloques ruby, list comprehension python, etc.)
• La sintaxis para los mapas se me hace poco legible.
• Por supuesto, soy un enamorado de los lenguajes dinámicos, por lo que en algunas ocasiones me siento encorsetado al definir las estructuras de datos. Pero supongo que es por cómo suelo programar...
• Si nos salimos de el tipo de aplicaciones para los que fue inventado, vamos a echar en falta bibliotecas potentes, aunque entiendo que eso es cuestión de tiempo.

No tengo opinión clara

• Control de errores, sensación no definida, por un momento,  parece demasiado verboso, por otro lado parece buena idea obligar a los desarrolladores a que piensen en los errores...
• La parte de testing integrada en el core del lenguaje y las herramientas me parece una gran idea, pero no los he usado como para tener una opinión formada sobre su funcionamiento.

Otros comentarios

• Si estás acostumbrado a hacer objetos pequeños y facilitar el reuso por composición en Golang no vas a tener ningún problema.
• Los escenarios en los que Go creo que es una opción muy viable son:
• Aplicaciones de alta concurrencia y que requieran escalabilidad.
• Aplicaciones reactivas y centradas en eventos.
• Aplicaciones de networking.
• Sistemas de monitorización, de control.
• Lenguaje de sistemas
• Escenarios en los que veo que hay mejores opciones:
• Lógica de negocio complicada
• Sistemas de información con flujos muy complejos
• Existen tipos de aplicaciones en los que se van a echar en falta bibliotecas (pero esto dependerá de hacia donde evolucione la comunidad).
• Lenguajes/entornos para los que creo que es un buen competidor
• Susituto de Node
• Susituto de C++ en aplicaciones de red y lenguaje de sistemas
• Rust
• Lenguajes dinámicos (python/ruby) para sistemas escalables o programación de sistemas

Go no es un lenguaje no hecho para hipsters. Aunque lo parezca porque es muy reciente y está consiguiendo mucha tracción, se trata de un lenguaje muy conservador, con una sintaxis simple y con pocas funcionalidades a nivel de lenguaje.
Parece que han decido que solo introducen funcionalidades al lenguaje en caso de que todos los diseñadores/desarrolladores del core estan de acuerdo, por lo que en general se añaden muy pocas cosas.
Se han centrado en tener la versión 1.0 y la van a mantener la compatibilidad durante varios años. Esto permite que se creen muchos recursos de gran calidad (charlas, libros, etc), cosa que no se ha visto con otros lenguajes que evolucionan mucho más rápido.

Patrón para la concurrencia :-)

Conclusiones

Creo que Go esta para quedarse, tienen muchos y grandes apoyos, y cubre una necesidad real (concurrencia y paralelismo, en un entorno de desarrollo y necesidades para despliegue extremadamente sencillo)
Es un lenguaje suficientemente bueno, centrado en un mundo escalable y reactivo, muy estable y que está creciendo a una velocidad de vértigo con una gran comunidad.
Es un lenguaje sin construcciones muy avanzadas y es un gran paso para desarrollos concurrentes y paralelos sin resultar disruptivo, de forma que lo más probable es que obtenga un gran exito (bueno, en realidad creo que ya lo está teniendo).

En esto de los lenguajes es lo de siempre:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Bjarne_Stroustrup

Recursos Go:

Para empezar:

• Web official http://www.golang.org
• Especificación del lenguage
• Tour of Go
• How to Write Go Code

Más información de calidad:

• Blog del lenguaje Go http://blog.golang.org/
• Charlas https://code.google.com/p/go-wiki/wiki/GoTalks
• Charlas y Videos http://go-lang.cat-v.org/talks/
• Cómo escribir código Go idiomático http://golang.org/doc/effective_go.html

Otros recursos interesantes:

• http://www.golangbootcamp.com/book
• https://gobyexample.com/

Charlas recomendadas:

• Go Concurrency Patterns
• Advanced Concurrency Patterns
• Go: code that grows with grace
• Concurrency is not Parallelism
• Go a simple programming environment
• Let's Go Further: Build Concurrent Software using the Go Programming Language

Enlaces relacionados:

• https://github.com/eferro/gosnmpquerier
• https://github.com/eferro/rabbitmqmgmt
• http://piweek.com/
• Post sobre PiWeek

Conclusiones PiWeek / Brutal :-)

Tengo que decir que la PiWeek ha sido para mi uno de las semanas más intensas y de más retorno de la inversión que he tenido en bastante tiempo.

En mi caso pretendía aprender GoLang y tengo que decir que el objetivo ha sido cumplido con creces. No quiero decir que ahora domine el lenguaje, pero sin duda puedo decir que ahora estaría en condiciones de empezar un proyecto que se pudiese poner en producción y creo tengo las nociones necesarias de los conceptos más importantes (concurrencia expresada mediante procesos ligeros (gorutinas), comunicación por canales, los diseños share nothing, etc)

Resumiendo, que hace mucho tiempo que no era capaz de centrarme toda una semana en aprender algo, en un ambiente en el que todo el mundo está entusiasmado por crear, aprender, construir... innovar.

Desde el punto de vista de empresa creo que es una forma muy barata de impulsar la innovación, de fomentar el trabajo en equipo y de crear nuevos productos. Por poner un ejemplo, en una sola semana, he visto proyectos que pueden ser perfectamente un nuevo producto, yo mismo he aprendido una nueva tecnología a un nivel que no podría conseguir en un curso y ahora mismo me veo con capacidad de aportar todo lo aprendido en mi empresa. Seguramente pudiendo ahorrar mucho coste en cierto tipo de proyectos.

Vamos, que desde el punto de experiencia personal, de cumplimiento de expectativas y de retorno de la inversión, le doy una puntuación de:

9/10

El juego de la perfección. Para que la PiWeek fuese la mejor opción para la innovación personal y la innovación tecnológica, y por tanto un gran paso para la dominación mundial por parte de los nerds, falta mejorar los siguientes puntos:

• Preparar proyectos con un poco más de antelación, para que se pueda generar interés en los proyectos (internamente en Kaleidos puede que se genere, pero desde fuera es mucho más complicado).
• Logística de telecomunicaciones para que sea más sencilla la incorporación de proyectos realizados desde otras sedes.

Otra posibilidad es impulsar la actuación más local para que se expanda la idea de forma más global. Es decir, dar más peso para que se generen sedes en otras ciudades que actúen como centros de innovación, como actúa Kaleidos en el caso de Madrid.


Desde luego, me he quedado encantado y seguro que voy a intentar repetir la experiencia en las siguientes convocatorias...

Muchas gracias Kaleidos por la idea y la puesta en práctica


Enlaces relacionados:

• http://piweek.com/
• blog piweek
• twitter #piweek
• Post sobre PiWeek

Diario PiWeek Dia V (El desenlace final)

Hoy era el último día de la PiWeek y el ambiente que se notaba era entre festivo y de nerviosismo. Todo el mundo estaba cerrando las últimas tareas o preparando la demo/presentación.

En nuestro caso, la verdad es que el jueves teníamos ya implementado las dos soluciones que pretendíamos hacer, así que lo único que podíamos hacer era abrir el proyecto e intentar meter más funcionalidad o seguir leyendo y autoformandonos en Go, y dado que yo soy más bien de asegurar, no quise tocar el código y simplemente he pasado la mayor parte de la mañana leyendo sobre Go y debatiendo sobre temas de agilidad con Yamila.   :-)

A punto de empezar las demos

A las doce y media se paso ha realizar las demos de los proyectos. Recordemos que uno de los requisitos de la PiWeek es que en la demo se presentase un sistema/aplicación funcionando. No vale con presentaciones, tiene que ser algo real, algo funcionando. Esta regla te obliga a tener unas expectativas reales y gestionar muy bien el tiempo del que dispones.

Las demos me han gustado mucho puesto que no había podido seguir el avance de los proyectos durante la semana y algunos estaban muy currados y podrían ser perfectamente la base de un producto.

Una cosa me ha quedado clara, una aplicación servidora con interfaz de linea de comando no es muy impactante precisamente. Quizás podríamos haber generado gráficas en tiempo real o algún tipo de medida de rendimiento para que se viesen más claramente las ventajas que hemos tenido por desarrollar en Go. O mostrar parte del código para que se viese lo fácil que ha sido expresar la concurrencia.

Todos los proyectos me han parecido muy interesantes y esto no es por ser un pelota, lo digo de forma sincera. Había de todo, pruebas concienzudas de tecnologías, proyectos de integración, posibles productos para publico masivo, webs de contenido especifico, integración de sensores y hardware, aplicaciones móviles, webs, bases de datos, multitud de lenguajes, multitud de tecnologías, etc.
Una de las presentación ha tenido incluso música en directo creada expresamente para la ocasión. Contra eso está claro que no se puede competir :-)

Presentación con música en directo (flipa!!!!)

Por cierto, muchas gracias Yamila por apuntarte al proyecto, se aprende muchísimo más en compañía y además así ha resultado mucho más fácil completar toda la funcionalidad que pretendíamos :-)
Un gusto trabajar contigo.

Enlaces relacionados:

• https://github.com/eferro/go-snmpqueries
• http://piweek.com/
• blog piweek
• Puedes seguir twitter la #piweek
• Post sobre PiWeek

Diario de PiWeek IV (Jueves)

Nuestro logo de proyecto

Hoy la verdad es que se ha dado muy bien, hemos terminado todos los hitos funcionales que nos habíamos planteado al comienzo del proyecto.

Por lo que una vez preparada la demo que vamos a hacer mañana, hemos podido ir estudiando como podemos hacer el código más idiomático. Recordemos que el objetivo principal es aprender Go, asi que todo lo que podamos aprovechar esta tarde y mañana antes de la demo, para seguir aprendiendo será perfecto.




Yamila se ha currado el servidor http y sus correspondientes pruebas y yo he terminado las pruebas del servicio por amqp. La verdad es que en ambos casos no se ha dado mal.

El diseño que ha quedado es el siguiente: dispone de un motor de consultas snmp asíncrono, que a partir de un canal de peticiones snmp, las despacha para diversos workers creados por cada destino y que se balancean la carga permitiendo hasta un máximo prefijado de operaciones snmp por destino. Una vez realizada la consulta snmp, la respuesta se devuelve por otro canal.
Por supuesto este canal de salida está desordenado, puesto que se ponen en el canal de salida en cuanto termina de realizarse la petición snmp y eso dependerá totalmente del host destino y de la consulta snmp.

Usando este motor de consultas se han creado dos servidores:

• amqpsnmpqueries (pasarela amqp/snmp)
• snmphttpserver (pasarela http/snmp)

amqpsnmpqueries

Partiendo de una cola AMQP (en rabbitmq) de peticiones snmp, publica en un exchange AMQP las respuestas a las peticiones. En este caso, la aplicación es casi un uso directo del motor de consulta snmp asincrono.

Diseño interno amqsnmpqueries. 

snmphttpserver

Permite realizar consultas snmp por http. En este caso dado que cada cliente quiere una respuesta sincrona a su petición exite una capa de adaptación que apartir de las salidas desordenadas se encarga de despachar cada respuesta al cliente correcto.

Diseño interno snmphttpserver

En un plano más mundano, Kaleidos ha invitado a unas riquísimas empanadas de Milan Dopico que hemos disfrutado en la azotea.
Cualquiera que me conozca sabe que disfruto con esas cosas como un cerdito en la charca :-)

Y mañana demo!!!  La verdad es que hay unos proyectos chulisimos y estoy deseando ver hasta donde han llegado...
Por mi parte, con el nuestro hemos cumplido, puesto que creo que las bases de Go como para desarrollar algo que vaya a producción están asentadas.

Enlaces relacionados:

• https://github.com/eferro/go-snmpqueries
• http://piweek.com/
• blog piweek
• Puedes seguir twitter la #piweek
• Post sobre PiWeek

Diario de PiWeek III (Miercoles)

Artista con las tizas...

Tercer día de la PiWeek, hoy hemos comenzado los primeros prototipos para interactuar con el servicio usando AMQP y http.
De momento sólo tenemos algunas pruebas, pero creo no debería ser demasiado difícil enganchar las piezas.

Hoy después de repasar el punto en el que estamos en el proyecto, decidimos dividir el trabajo y abrir dos vías de forma simultanea, una para amqp (que he empezado yo) y otra para el servicio http que ha empezado Yamila.

Por desgracia, Yamila, fue requerida por una urgencia (de fuera de PiWeek) y no tubo todo el tiempo disponible.

Hasta ahora mis sensaciones con respecto a Go son:

• Permite expresar muy bien la concurrencia de un programa
• El tratamiento de errores, se me hace pesado (supongo que porque es tan divertido como documentar :-) )
• Por otro lado, la velocidad de desarrollo es muy buena en este tipo de problemas, aunque se nota que tenemos una falta de conocimientos brutal, puesto que aunque las cosas funcionan no tienen para nada pinta de ser muy idiomaticas. Asi que creo que nos queda mucho que aprender sobre como organizar el código, los paquetes y como abstraer y reusar usando iterfaces.
• En cualquier caso, suelo preferir hacer algo que funciona y luego ir iterando verificando que sigue funcionando. Así que nos centraremos en tener el servicio amqpsnmp y httpsnmp y ya nos preocuparemos de refactorizar haciéndolo más idiomatico y reusable.

A última hora...

No solo de programar vive el PiWeekero y también se ha celebrado un campeonato en la pequeña recreativa que hay en la oficina.

Entre pomodoro y pomodoro, puede echar un vicio...

Mañana más...

Enlaces relacionados:

• http://piweek.com/
• blog piweek
• Puedes seguir twitter la #piweek
• Post sobre PiWeek

Diario de PiWeek II (martes)

Segundo día de la PiWeek y el proyecto a toda marcha...

El lenguaje Go nos esta resultando fácil y nos está permitiendo con muy poco coste solventar los problemas de concurrencia.
Aparentemente la aplicación es robusta y se ejecuta de forma paralela en todos los cores sin tener que añadir nada de código.

Al igual que ayer, hemos generado algunos deadlocks, en muchos de los casos por intentar escribir en canales sin buffers de los que todavía no existe un lector.
En cualquier caso, han sido fáciles de detectar y de solventar.

Todavía no hemos empezado con temas de interfaces, pero cada vez se me hace más evidente que con un buen diseño el core es reusable para otro tipo de operaciones de red.

Hoy, no he acaparado tanto el teclado y creo que hemos avanzado en conocimiento los dos.

Lo que a estas alturas tengo claro es que verbalizar problemas de concurrencia y sincronización es bastante complicado, por lo que creo que Go hace un trabajo excelente en permitir expresar en código esa concurrencia de forma más o menos sencilla (teniendo en cuenta lo difícil que es en otros lenguajes).

Bueno, mañana más....

Enlaces relacionados:

• https://github.com/eferro/go-snmpqueries
• Panel trello del proyecto
• http://piweek.com/
• blog piweek
• Puedes seguir twitter la #piweek
• aprendiendo golang en la piweek