In this lively, conversational YouTube episode, the hosts Violeta, Pro, Chip, Byte, and Slice explore why Go (often called Golang) is touted as the "best language in the world." The discussion begins with the origin of the name – a nod to the board game Go, the short, movement‑evoking branding, and the early naming conflict with another language. They then introduce the three principal designers – Ken Thompson, Rob Pike, and Robert Griesemer – framing them as the "three musketeers" of Google. The core of the episode is a walkthrough of the seven design principles (attributed to a fictional Tony Huard document) that guided Go’s creation: simplicity & elegance, abstraction & flexibility, orthogonality, robust error handling, fast compilation & execution, avoidance of over‑design, and community involvement. These principles are linked to concrete language features: static typing with type inference, garbage collection, Unicode runes, fast compilation, dependency management, and a powerful concurrency model based on CSP, goroutines, and channels (with optional mutexes). The hosts recite a set of Go proverbs (delivered by the characters Byte and Slice) that capture cultural wisdom such as “Concurrency is not parallelism” and “The clear is better than the clever.” They compare Go to other languages (C, C++, Python, Rust, JavaScript, etc.), note criticisms (e.g., Alan Kay’s comment) and defend Go’s design choices. The episode also emphasizes Go’s philosophy of backward compatibility, community feedback, and the promise of stability for version 1. Throughout, the hosts intersperse humor, audience engagement prompts (likes, subscriptions, comments), and meta‑conversations about the show’s format. The episode concludes by inviting viewers to share their experiences with Go and to continue the discussion in the comments.
Chapters
Sois productividad, sois concurrencia, sois parte del mejor lenguaje jamás creado. Rápido, escondeos.
Violeta, sí que llegaste temprano. Se ve que el capítulo de hoy te fascina.
Completamente.
Uf, ¿qué pasa, Chip?
Estuve intentando calmar los ánimos en X.
¿Twitter?
Actualízate, pro. La red se llama ahora X. Y sí, están descontentos porque se eligió Go.
Pues yo no he visto ninguna reacción a ese mensaje que enviaste.
Tú confía en mí. Con su silencio dicen mucho más que ¿Estás escribiendo algo?
No, confío mejor en las estadísticas. Un 40% votaron Go. ¡Qué emoción!
Así que hablaremos de Go.
Yo empiezo. Voy a darle profundidad a los bloques de los que hablaremos.
No tan rápido.
No me digas, el inciso. Ya decía yo, evento canónico.
Antes de continuar, un inciso.
¿Te gustaría apoyar a nuestro canal?
No te olvides de darle a me gusta y si no lo estás, suscribirte para no perderte futuros contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.
Y además también podemos acompañarte desde tu plataforma de podcast favorita.
Ahora sí, continúa. ¿Por qué el mejor lenguaje del mundo se llama Go?
Qué largo quedó eso.
Había que decirlo y se dijo.
¿Quién dijo eso?
eso no es importante ahora. Lo importante es de dónde viene el nombre de Go. Ralph Pyke dijo en una charla que el nombre de Go coincide con el juego de mesa del mismo nombre, y no era coincidencia, pero que era otra historia.
¿Una forma de no querer contarlo?
Se dice que eligieron el nombre porque es corto y evoca movimiento, es positivo y conciso.
Pero hay muchos programas, juegos y otros elementos con un nombre similar. ¿No tuvieron problemas al elegir ese nombre?
De hecho sí, había un lenguaje llamado de forma similar: Go.
¿No es el mismo nombre?
No, no lo es. Uno es Go y otro es Go.
Sutil, pero igual. ¿No les forzaron a cambiarlo?
Argumentaron que no hacía falta, nadie los confundía.
No me extraña, nadie conoce Go. Pero entonces, ¿el lenguaje es Go o Golang?
El lenguaje es Go, solo que al principio, como el dominio no estaba disponible, registraron golang.org. No obstante, cuando tuvieron ocasión obtuvieron go.dev.
Pero el mal ya estaba hecho.
Sí, cambio de bloque, que no nos va a dar tiempo a todo. ¿Cómo hacer el mejor lenguaje del mundo?
Hola, un poquito subidito, ¿no?
No, y te diré por qué. ¿Has visto una película de Woody Allen llamada Todo lo que quisiera saber sobre...?
Vale, vale, que sé cuál dices, pero ¿qué tiene que ver esa película con lo que hablamos?
Porque Tony Hawk escribió en 1978 un documento titulado Todo lo que siempre quisiste saber sobre lenguajes de programación y nunca te atreviste a preguntar.
No lo he leído, pero supongo que será del estilo de su anterior documento donde daba pistas para el diseño del lenguaje de programación. ¿Los creadores de Go se basaron en estos documentos?
¡Exacto, pro!
Qué raro que no lo supieras, pro. Pero, Violeta, ¿Solo por seguir esos documentos ya se hace el mejor lenguaje del mundo? Porque seguro que muchos otros lenguajes también se basan en estos u otros documentos similares y no los llamarías los mejores lenguajes del mundo.
No solo por eso. Para preparar un plato exquisito, muchas veces tener la receta no es suficiente. También hay que tener grandes chefs, y Go tuvo de los mejores.
¿Sus creadores?
¿Quién diría que Ken Thompson no es de los mejores? Ya vimos lo fácil que le resultaba crear software para entretenerse y proyectos personales cuando hablamos del lenguaje C.
También hablamos en otro capítulo de concurrencia y Rob Pike. De hecho, esa charla exponía lo que significaba la concurrencia en la computación y desde el punto de vista de Go también.
¡Exacto, bro!
Qué raro es esto.
Pero se nos olvida alguien más. No es tan conocido, pero también estuvo junto a Pike y Thompson. Fue Robert Griesemer, y para mí son los 3 mosqueteros de Google.
Vale, tenemos los chefs como decías, y tenemos la receta. Por cierto, ¿cómo podemos resumir esta receta? ¿Cuáles son los puntos que Tony Huard puso en el documento?
Pues serían 7 puntos, Chip. El primero es la simplicidad y la elegancia.
Menor complejidad, menor posibilidad de cagar.
¡Chip!
Menor posibilidad de cometer errores. ¿Cuáles serían malos ejemplos en este caso?
Pues la lista es larga. Algunos son C++, Perl, Java y VBScript.
Pues no me extraña.
Continuemos. El segundo punto sería abstracción y flexibilidad.
Evitar mezclar los detalles de bajo nivel con la lógica de solución del problema.
Evitamos que se filtren los detalles de implementación en las abstracciones. Vale, creo que eso era un principio SOLID.
Ya trataremos SOLID si hacemos un vídeo de buenas prácticas. Calidad interna, deuda técnica y mantenibilidad. Dejadnos un comentario.
Pongamos ejemplos. ¿Qué lenguajes harían mal este punto?
Pues en este caso C, Fortran, COBOL, Pascal, PHP, JavaScript, Ruby...
Vaya, ¿hay alguno que lo haga bien?
Sí, por supuesto. Están Rust, Python, Swift, Elixir, Go...
Por supuesto. Sigamos. Tercer punto: ortogonalidad.
¿Ortogonalidad?
Evitar casos especiales o excepciones. Que el código escrito sea predecible y no sorprenda haciendo algo completamente diferente a lo que se espera. Buenos ejemplos son Rust, Go... ¡Por supuesto! Y Haskell.
¡Venga! Cuarto punto: detectar, reportar y recuperarse de los errores.
Aquí en verdad hay un arduo debate. Hay quien considera que try-catch es tan dañino como la sentencia goto porque rompe el flujo de ejecución.
Pero si sucede un error imprevisto, ¿qué haces?
¿Imprevisto? Si tienes una excepción programada, no es imprevisto.
Ciertamente hay un debate bastante interesante aquí. Lo dejaremos para otro momento. Solo indicar que Hoare hacía hincapié en que un error no significaba el fin inesperado del programa.
Quinto punto: compilación y ejecución eficientes. Nada que comentar aquí. Creo que todos sabemos lo rápido y eficiente que es la compilación en Go. No tiene rival. Así que sexto punto: evitar el sobrediseño.
Evitar la tentación de incluir toda posible característica.
Sí, creo que todos le hemos echado una mirada a Strauss-Trupp y su C++.
El último punto, y creo que bastante importante: la involucración de la comunidad. Tomar retroalimentación de la comunidad y aportar mejoras y cambios basados en el mundo real.
Vale, estos fueron los puntos marcados para el diseño e implementación del lenguaje. ¿Cuáles son sus características? Ya sabes, sus fortalezas...
¡Que tiene el mejor lenguaje del mundo! Grisemer escribió unas notas partiendo de C para mejorar el lenguaje.
¿Una carta a los Reyes Magos?
En cierta forma sí. La idea era simplificar, hacer cosas de modo más explícito y claro.
¿Como en Python?
¡Mejor que en Python!
Lo dudo.
Hubo gente, como Alan Kay, que criticó que no había nada nuevo en Go. Sus creadores se defendieron citando a Hoare: la labor de un diseñador de lenguajes es consolidar, no innovar.
¡Exacto, bro! Go recorrió las raíces de la programación desde Algol revisando la rama de Pascal y C, y aunque la lista inicial parece que partía de C, en verdad se basaron mucho más en Modula y Oberon, que son sucesores de Pascal.
¿Y la orientación a objetos?
No hay.
Un momento, ¿Go no está orientado a objetos?
No, esa moda fue de los 90 y ya pasó. Go se orienta en otros lenguajes que hacían las cosas bien mucho antes de la orientación a objetos.
Ya vimos que la orientación a objetos se consideró un error de millones de dólares y actualmente muchos lenguajes dan la posibilidad de programar sin objetos.
Como en Python, Chip?
Vale, vale, aunque creo que este es otro arduo debate.
De momento sabemos que Go parte de las ideas de Hoare e influencias de lenguajes como Modula, Oberon y C. ¿Qué más tiene Go?
Tiene buen soporte de Unicode para cadenas de texto. En Go los caracteres dentro de una cadena de texto se llaman runas para evitar ser identificados como los antiguos caracteres de 8 bits. Las runas son de 32 bits.
Pero eso ocupa mucho en la memoria, ¿no?
Tiene la contraparte del uso extra de memoria y la pérdida de rendimiento en según qué operaciones.
Pero aún tienes la posibilidad de usar cadenas de bytes si no necesitas gestionar multibyte o runas para un texto.
Vale, resumamos. ¿Qué características hacen notorio a Go?
Voy. Como hemos dicho, simplicidad. Y legibilidad, compilación rápida, tipado estático, inferencia de tipos, recolección de basura, interoperabilidad, gestión de dependencias y concurrencia.
Tipado estático e inferencia de tipos... Eso quiere decir que no hay que definir los tipos a menos que no se puedan inferir, ¿no?
¡Exacto, Chip! Si igualamos una variable a un número entero No hace falta indicar que es un número entero. La asignación nos da la información de forma implícita.
La gestión de dependencias fue algo conflictiva en sus inicios, principalmente por la falta de control de versiones.
Nada que no esté solucionado ya.
La concurrencia creo que es un tema fundamental en Go. Parece que no se basa en los típicos bloques que emplean otros lenguajes para concurrencia.
Sí, pero hablemos antes de las dependencias, porque parece que choca un poco con los pilares en que se sustenta Go.
¿Los pilares? ¿Te refieres a algo así como los objetivos o la filosofía del lenguaje?
¡Cierto! Abramos un nuevo bloque. La filosofía del mejor lenguaje del mundo.
Estos títulos habría que revisarlos.
Si mal no recuerdo, el objetivo de Go, según Rob Pike, era eliminar la lentitud y la torpeza en el desarrollo de software en Google y conseguir un proceso más productivo y escalable.
Exacto. Al igual que comentamos en el capítulo de Python sobre el zen de Python, Go tiene algo similar.
Proverbios.
¿Otra vez? ¿Quién dijo eso?
Hora de presentaros, chicos. Estos son Byte y Slice, y los he llamado para que ilustren los proverbios de Go. Chicos, dadle caña.
No comuniques compartiendo memoria.
Comparte memoria comunicando.
La concurrencia no es paralelismo.
Los canales son orquestan.
Los mutexes serializan.
Cuanto más grande la interfaz, más débil la abstracción.
Haz que el valor 0 cuente.
Interfaces no nos dicen nada.
El estilo de Go fmt no es el favorito de nadie.
Pero Go fmt es el favorito de todos.
Copiar un código pequeño es mejor que una dependencia del código pequeño.
Las llamadas al sistema deben protegerse siempre con etiquetas de construcción.
C debe estar resguardado con etiquetas de construcción.
C Go no es Go.
No podemos garantizar nada si usas unsafe.
Lo claro es mejor que lo ingenioso.
La reflexión nunca es clara.
Los errores son valores.
No solo verifiques errores.
Manejalos con gracia.
Diseña la arquitectura.
Nombra los componentes.
Documenta los detalles.
¡La documentación es para los usuarios!
¡No entres en pánico!
¡Muy cucos!
¡Somos peligrosos, chaval!
Vale, creo que más o menos los proverbios quedaron claros, aunque podríamos comentar alguno...
No nos queda tiempo y hay mucho que ver. El mejor modelo de concurrencia.
¡Del mundo!
¡Exacto, Chip!
Era sarcasmo.
Hay que reconocer que el modelo no es nada malo. A ver, el modelo de concurrencia se basa en el documento Communicating Sequential Processes o Comunicación de Procesos Secuenciales de 1978.
¿Qué otros modelos de concurrencia hay?
Hay muchos. Los más empleados en sistemas tipo UNIX suelen ser la comunicación entre procesos, se emplean señales y memoria compartida.
También hay hilos o hebras que comparten el mismo espacio de memoria como en C o Java.
Exacto. Tanto en uno como en otro requerimos de elementos como semáforos o mutexes.
En Node.js se emplea un mono-hilo con gestión de eventos.
También lo emplea Python a través de la biblioteca asyncio, pero no es su enfoque principal. Yo diría que este sería más bien un modelo de corrutina.
También presente en Go.
El modelo actor presente en lenguajes como Erlang o en Akka de Scala.
Y, por supuesto, el modelo de canal de Go.
También está presente en Rust.
Un momento, ¿no decías que el modelo de Go era de canal?
Go emplea gorrutinas y canales. Al igual que se menciona en el documento de Hoare, la comunicación se produce mediante canales y sin bloqueos.
¿Nada de mutexes?
Nada de mutexes en los canales. Obviamente, si quieres mutexes los puedes usar.
Conclusiones.
¡Pro! Aún no hemos abierto el bloque de la promesa de no cambiar nada y ser retrocompatible mientras dure la versión 1.
Pues ya lo dije.
¡No es justo! ¡El capítulo quedó corto!
¿Corto? ¡Díselo al editor! ¡Pobre! Ya solo con Bite y Slice estará contento.
¡Es su trabajo!
Quedémonos con lo mejor del capítulo. Dijimos muchísimo sobre el lenguaje: sus orígenes, sus influencias, sus valores, sus... ¡Proverbios! Eso, y su modelo de concurrencia.
¡Cierto!
Supongo que podremos seguir la conversación en comentarios.
Sí, es vuestro turno. ¿Habéis empleado Go?
¿Le decís Go o Golang?
¿Qué 3 lenguajes están en vuestra lista como los mejores?
¿Qué tiene que ver esa pregunta?
No sé, me apetecía saber. Da igual.
Déjanos tus comentarios.
¿Sabéis por qué los programadores odian el campo?
¿Por qué?
¡Porque hay muchos bugs! ¿En qué se parece programar a construir una catedral? ¿En qué? En que primero los construimos y después rezamos.
