Discusión:Go (lenguaje de programación)

Promoción

Considero que el artículo podría permanecer en Wikipedia por ser perfectamente enciclopédico, pero en su redacción actual (febrero de 2013) parece propaganda. Como no tengo ni idea del tema, no me atrevo a meterle mano yo. Un saludo, Cvalda | Tus mensajes aquí 18:15 20 feb 2013 (UTC)

Totalmente de acuerdo. Añado la plantilla:publicidad. --Txuspe (discusión) 16:45 21 ene 2015 (UTC)

¿Propaganda publicitaria? ¿Por qué si se puede saber?. Antes de actuar como auténticos talibanes de Wikipedia sin tener "ni idea del tema", no estaría de más que se informaran un poco y/o incluyeran alguna prueba citando lo que supuestamente se publicita. Si sirve de algo, me parece que el estilo se podría pulir un poco para que resultara un poco más "enciclopédico", pero la información, por lo que parece, es correcta. Por cierto, en informática, las "capacidades de alto nivel" o el "paradigma" puede que no signifiquen lo que algunos creen. Saludos. --Iván R.83.40.196.61 (discusión) 22:13 23 abr 2015 (UTC)--Iván R.83.40.196.61 (discusión) 22:13 23 abr 2015 (UTC)

A mi entender la sección de innovación esta totalmente de más, a lo mejor hay que buscar integrarlo en la sección de características. --Emax093 (discusión) 15:35 20 oct 2015 (UTC)

Publicidad no veo por ningún lado. --JuanPCSur (discusión) 21:57 18 sep 2020 (UTC)

Orientacion a objetos y peso C++

No conozco de Go pero si no soporta multiherencia, polimorfismo, etc. no se le puede considerar POO, hasta a assembler se puede programar en un estilo que simule objetos, pero eso no lo hace un lenguaje OO. Y sobre el peso de otros lenguajes creo que al menos deberia ponerse un "citation needed" GCC compila codigo que dificilmente se iguala en assembler, si le pasas el parametro -O2. Y de clang ni se diga, gracias a que generaron competencia empezo a mejorar GCC tambien

Describirlo como POO no creo que sea correcto. En ningún sitio lo he visto. Puede simular objetos con el type struct pero no es un lenguaje POO. --JuanPCSur (discusión) 21:36 18 sep 2020 (UTC)

---

Efectivamente, Go no es un lenguaje de programación orientado a objetos (en adelante POO). «No ofrece soporte para la creación de clases y objetos»​ afirman en una web no oficial. Sin embargo, si seguimos tirando del hilo, el artículo continúa afirmando que sí ofrece ciertas funcionalidades (interfaces, herencia y polimorfismo) que le confieren la capacidad de emular un lenguaje de POO, término que varias veces usa para referirse a como Go logra satisfacer estas funciones.

Esta información está respaldada en el apartado FAQ de la web oficial de este lenguaje (golang.org). Leyendo el primer párrafo podemos entender que, a pesar de cumplir características propias de un lenguaje OO, no se comporta como tal y requiere de «aproximaciones», lo cuál lo puede catalogar más como un peso ligero si nos referimos a este paradigma. Aunque cumpla con ello, no es su principal finalidad desde luego.

Como conclusión, se podría decir grosso modo que Go es un lenguaje que, sin estar OO, comparte similitudes y puede llegar a emular el comportamiento propio de ese paradigma. Decir simplemente «no es orientado a objetos» sería falaz. Durante su desarrollo se tuvo en mente este paradigma, y se le ha dispuesto con varias funcionalidades que satisfacen los fundamentos de un lenguaje de POO. Ignorar este detalle nos haría perder una información que considero vitals para poder entender por qué se le puede ver llamado como OO, y como, de algun modo, la versatilidad de este lenguaje permite emular un paradigma orientado a objetos.

Dicho ésto y trás informarme un poco más, revisaré el artículo y trataré de enfocar mejor este concepto. --Emartinezr (discusión) 08:41 18 oct 2020 (UTC)

C y C++

Constantemente se menciona el parecido de Go con el C o C++, nada más lejos de la realidad. El lenguaje que menos se parece es precisamente el C o C++ donde no existe el concepto de var o el keyword func y sí el concepto de pre-procesado. Sin embargo el Go es muy parecido a Swift donde comparten casi todas las características o al Python.

Donde se dice que declarar "var i, j *int" como dos punteros es de lo más natural es de locos; hay que estar muy "envenenado" de sólo Go para pensar así. En C es "int* i, j", más compacto y más claro; el "var" no aporta nada en la expresión anterior.

Quitar las excepciones por ser algo excepcional es excepcionalmente absurdo. Desde que surgieron con C++ se han mantenido en los siguientes lenguajes que han ido apareciendo y su uso es especialmente útil. Fue un gran paso adelante. No usar excepciones es volver a la locura. Ha tenido que llegar Go para hacernos ver lo equivocados que estábamos todos programando con excepciones en C++, Java, Python, ...