Go, es el nuevo lenguaje de programación que acaba de lanzar Google. Dicho lenguaje es OpenSource y según Google combinará performance y velocidad. Go esta basado en la familia de lenguajes de programación tipo C, e incorporta elementos de Python, Pascal, Modula y Oberon para hacer más rápidos y dinámicos programas.
En su Go FAQ, Google explica su principal motivación para crear el lenguaje:
1. Ningún mayor sistema de lenguaje ha emergido en una década.
2. Las Computadoras son enormente rápidas pero el desarrollo de software no lo es.
3. El manejo de dependencias es un gran parte del desarrollo de software hoy, pero los archivos de cabecera de lenguajes en la tradición de C son antiestetico para limpiar analisis de dependencia- y rápida compilación.
4. Hay una ascendente rebelión contra engorrosos tipos de sistemas como Java y C++, empujando a la gente hacia lenguajes dinámicos tales como Python y JavaScript.
5. Algunos conceptos tales como Recolección de Basura (Garbage Collection) y computación paralela no estan bien soportados por populares sistemas de lenguajes.
6. El surgimiento de computadores multinúcleo ha generado preocupación y confusión.
En resumen: Google cree que la web y la computación han cambiado dramáticamente en los últimos 10 años pero los lenguajes de programación no.
¿Que Opinan ustedes sobre lo que será este Lenguaje de Programación, estan ustedes de acuerdo con estos argumentos que Google plantea?
Eso si, se podia haber traducido algo mejor la noticia...
Para empezar sólo funciona sobre Linux y Mac OSX, y el GC sólo es Mark & Sweep... así que de momento mucho hype como para comerse el mundo. Veremos como evoluciona, por mucho Go-ogle que sea.
Y la mitad de los argumentos me parecen bastante chorras como excusa para crear un nuevo lenguaje, por que que algunos sean ciertos no tiene nada que ver con que la respuesta sea crear otro nuevo lenguaje.
Y estoy con Nilojg, un poco mas de cuidado en la redacción sería de agradecer, y no es cuestión de acentos puntillosos.
creo que google = gate = microsoft hemos dejado que el monopolio se apropie de la web y para mucha gente solo existe google, lo mismo paso con microsoft era bonito al principio, una empresa que hacia frente a ibm y ahora ....
A mí personalmente google no me convence con todos esos argumentos mercadológicos, todavía tengo que investigar como este lenguaje en verdad trabaja, veremos luego como va evolucionando esto.
Estoy de acuerdo con el anónimo 21:03. Debo tener más cuidado al redactar.
Saludos!
Me parece que en Google trabaja gente muy inteligente, y si no han podido dar argumentos mejores que esos es por que su lenguaje no esta a la altura de Java o C# (al menos todavia)
Aunque últimamente estan intentando abarcar mucho, y ya se sabe que el que mucho abarca....
Emmerson
Hay muchas de estas razones que son compartidas en el nacimiento de Java y de C++
2. Las Computadoras son enormente rápidas pero el desarrollo de software no lo es.
3. El manejo de dependencias es un gran parte del desarrollo de software hoy, pero los archivos de cabecera de lenguajes en la tradición de C son antiestetico para limpiar analisis de dependencia- y rápida compilación.
4. Hay una ascendente rebelión contra engorrosos tipos de sistemas como "el anterior" empujando a la gente hacia lenguajes "mas nuevos"
5. Algunos conceptos tales como "metodologias y tecnicas nuevas" no estan bien soportados por populares sistemas de lenguajes.
6. El surgimiento de computadores "diferentes" ha generado preocupación y confusión.
Obvio que hay que colocar cada oracion en su tiempo
Comentar para quien no se haya enterado todavía, que el nombre del lenguaje al parecer ya estaba cogido por otro lenguaje, lo cual está llevando a que mucha gente esté pidiendo a google que cambie el nombre de su lenguaje Go por otro:
¿A estas alturas todavía alguien duda acerca de si son el nuevo Microsoft?
Mientras todo sea Free, a mi me vale.
Para el anónimo de las 09:13.
Creo que es BSD. Por favor, que alguien me corrija. Y si es BSD, entonces no es tan "Free". GPL, sí, que es "Free".
Personalmente yo diría que GPL no es tan "free" como BSD ;) . Para gustos hay colores...
Qué manía con reinventar la rueda todos los días, casi todos los "problemas" de un lenguaje se solucionan CON LIBRERÍAS.
Es como el que aprende varios idiomas para elegir en cada caso cual es el más "efectivo" cuando al final acabas diciendo lo mismo casi con las mismas palabras, es de locos.
La INMENSA mayoría de los lenguajes que nos borbandean todos los días son más de lo mismo, su máximo logro es conseguir quitar unas cuantas letras de código (a costa de la claridad, el que sabe algo de Perl o Shell me dará la razón), es decir, lo mismo que definir una función que haga lo mismo.
en el proceso de creación del lenguaje, está gente que inventó Unix, B (luego C), Plan 9...
Yo le daría un tiempo a ver... además, el tema de la programación multihilo tiene muy buena pinta... además, siempre es bueno entrar en un lenguaje cuando está empezando. A mi me fué bien con Java así.
Saludos.
Despues de verlo no me convence demasiado, tanto por su sintaxis, como por su contenido, ya veremos en que queda todo esto...
@Abraham
Software -> GPL -> El software será libre para siempre.
Software -> BSD -> El software puede llegar a ser cerrado.
Libertad del programador -> GPL -> No puede nunca cerrar ese software. Por lo tanto, el
programador tiene limitada su libertad.
Libertad del programador -> BSD -> Cuando le de la gana lo cierra, y punto.Es decir, no tiene
límites.
¿De qué estamos hablando? ¿De la libertad del software o del programador?
Que cada uno saque sus propias conclusiones. Yo lo tengo bien claro: está por delante la libertad del software que enriquece a la comunidad.
Con todo mis respetos a sus creadores (entre ellos el único ganador de 2 Turing), mi me suena que este lenguaje no viene tanto a dar respuesta a las lagunas exitentes en el resto de los lenguajes como a crear el lenguaje que satisfaga la moda actual: dinámico, sencillo, palabras cortas (las odio), rápido, etc... Le ponemos punteros (a medias) que molan y la gente se siente inteligente usándolos y lo hacemos compilado que suena rápido.
Siempre he dicho que cada 10 años aparece un nuevo leguaje que será adoptado masivamente. No sé si Go será el mejor de los que está apareciendo, pero es el que tiene más posibilidades de convertirse en el nuevo lenguaje por el poderío de papá Google.
Para mi las cosas inhertes no tienen ningún tipo de libertad asociada. Un pájaro puede ser libre o no. Sin embargo, no tiene sentido hablar de si una roca es libre o no. La libertad del soft. para mi es siempre la libertad que tiene la persona que usa el soft. Y una persona usando soft. BSD puede hacer todo lo que podría hacer con soft. GPL, y más cosas.
Ya sé que lo escribe en un post anterior, pero esto me sigue pareciendo una estrategia para consolidar una plataforma para eso que llama “la nube”.
Solo tienen que listar los últimos desarrollos de Google con más impacto.
AppEngine ---> Nube
*Chrome SO ---> Escritorio
*Android ---> Movil
Go ---> Con lo que podrías programar en los 3 anteriores
*Clientes de servicios en la nube
Pues yo veo mejor Java (o .Net) para trabajar en todos esos entornos, porque Java es run-everywhere, mientras que Go es compilado. Y ademas, no se compila para ARM o Intel, si no para Intel con 32 o con 64 bits.
Es mejor Java, que escribes un applet, lo dejas en un sitio y te da igual la arquitectura del usuario y como ordene a los indios. El applet funciona y punto. Mas o menos, JME mediante. Da igual si usa tu programa en la nube, en local, dentro de un navegador o en un movil (JME otra vez).
Con Go tienes que ponerte a recompilar para cada entorno y tener una version disponilbe para cada posible maquina. Yo creo que Go es mas bien algo para sustituir a Python, ese gran lenguaje que usan tanto en Google y con el que estan tan contentos...
¿Otro lenguaje de programación? Buffff... como si no hubiera suficientes ya.
Todavía no entiendo como partiendo de una noticia acerca de un nuevo lenguaje se llega a conclusiones como las de @nilojg: "Es mejor Java, que escribes un applet, lo dejas en un sitio y te da igual la arquitectura del usuario...". ???!!!. Por cierto, pareciera como que la parte en que mencionas a Python tiene un poco de ironía, no sé si es así, pero en caso de ser afirmativo te recomiendo que aprendas un poco de lo que criticas, o que aprendas de lo que crees saber, porque alguien que recomienda volver a los applets...
Saludos.
¿Sabeis algo realmente de este lenguaje?
¿Lo habeis investigado bien?
Creo que los tios que estan detras de él son gente muy seria y eso da ciertas garantías (hablamos del creador del compilador GCC, el del UTF-8 y uno de los creadores de UNIX y el lenguaje B), a mi personalmente no me gusta mucho la sintaxis por mis costumbres con C++, pero hay otras cosas que si me estan gustando en cuanto a threads y orientacion a objetos.
En cuanto a lo de que no es multi-plataforma os dire algo, en ese sentido es igual que C y C++ con todo lo bueno y lo malo, por tanto no se parece ni a JAVA ni a C#. (Tienen compiladores para x86, x64 y ARM).
Si hacen una SDK completo, independiente del sistema operativo y como dios manda puede que le haga mas caso (me gustaria ver una aplicacion compilada en Windows, Linux y OsX con las mismas lineas de codigo comunicandose con las APIs del SO ajajajajajaja).
> palabras cortas (las odio)
Yotambienlasodio.
Al anonimo de las 14:22.
A ver, yo respondia a JBaez, que decia que Go es un lenguaje para unificar la "nube", el escritorio y los dispositivos moviles, para lo cual, un lenguaje compilado no va muy bien, porque sin ir mas lejos, tienes que tener una version compilada para un intel64 y otra para un intel32. Y si hablamos de moviles ya debe ser la pera. ¿Como vas a usar un lenguaje compilado para unificar esas cosas si dependes de que procesador tienes debajo? Igual el codigo fuente es el mismo (que me extrañaria mucho que sea el mismo para un intel64 con Windows, para un intel64 con kde y para un intel64 con MacOS, pero te lo concedo), pero el codigo objeto definitivamente no es el mismo.
Para eso son mejores Java y .Net, que con el mismo codigo fuente te funciona en cualquier arquitectura que tenga un runtime (y en el caso de Java y gracias a Swing, incluso el codigo de las ventanitas es el mismo, en .Net no se porque no lo conozco).
Y mira, no creo haber recomendado el uso de applets, pero ya que lo mencionas, pues si los recomiendo. Puedes estar meando cristales para hacer una aplicacion Ajax que aparente ser una aplicacion "de verdad", arrastrando iconos y sacando mensajitos y cruzando los dedos para que funcione en todos los navegadores, o puedes escribir un applet con swing, que sabes que va a funcionar seguro alli donde tengas un navegador con JVM, y ademas de arrastrar iconitos y sacar mensajitos, puedes abrir varios threads, hacer ruiditos, hacer animaciones de verdad, etc... Y si pagas un certiicado o convences al usuario para que se fie del que tu generas, hasta puedes imprimir (formateando como es debido), hacer efectos mas avanzados, leer ficheros del ordenador del usuario... Y a poco que te organices, el mismo jar que sirve como aplicacion de escritorio, asi que tu cliente puede elegir. En fin, que comparar lo que puedes hacer con esa chapuza que es Javascript y Ajax con lo que puedes hacer con un lenguaje de verdad como Java y los applets es como comparar... pues no se me ocurre una comparacion que no sea ofensiva, pero es que no tiene comparacion.
Para que veas lo que se puede hacer con Swing (y Java2D) te rcomiendo que mires un poco el libro "Filthy Rich Clients" (http://filthyrichclients.org/) y mires lo que hace Roman Guy buscando un poco por Google.
Y respecto a Python, pues es verdad, soy absolutamente ignorante sobre Python, pero este (http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1) tipo no, y tiene algo que decir sobre la escalabilidad de Python. Es de perogrullo, si Python aguantara el tipo, no inventarian Go...
@nilojg: Si respondes a un usuario, con indicarlo se evitan posibles confusiones (hablo por tu respuesta anterior).
Lo que pasa es que no comprendo como de un artículo en el cual no se menciona nada acerca del uso del lenguaje (cliente/servidor/nube/lo que sea/como se lo llame) se termina cayendo en la conclusión de los applets, y menos aún al párrafo anterior donde traes a colación a Javascript como si fuera la única alternativa a un hipotético caso de uso en el cliente...
Con respecto a la recomendación de Swing, te agradezco la misma y la leeré en un rato libre, pero realmente Java no es mi opción para la parte de presentación.
Para finalizar lo de Python, te recomiendo leas completamente el link que mencionas, y no sólo los 2 primeros posts...
Por si te interesa, el último post (http://neopythonic.blogspot.com/2009/11/python-in-scientific-world.html) en el Blog del creador de Python (que casualmente también trabaja en Google) da un par de ejemplos interesantes de uso del lenguaje, pero bueno, quizá no sean buenos ejemplos a seguir en un lenguaje no escalable... :).
Saludos.
Ninguno de nosotros ha aprendido java bien así que la respuesta de todos es: no hemos aprendido uno como para meternos en otro. al final no aprendemos ninguno y lo que queda en la cabeza solo son los patrones, buenas practicas etc.
Discrepando un poco, si que veo un cierto hueco a un lenguaje de este tipo.
Ahora mismo hay que tirar o bien de lenguajes que compilan a nativo directamente como c y c++, pero que no tienen muchas caracteristicas deseables como recolector de basura o buen soporte de threads, o tirar de java, .net, python, php... que necesitan un interprete o una máquina virtual, por lo que el uso de CPU y la necesidad de memoria sube.
En un entorno como el de Google, utilizar menos recursos de computador para muchas de sus tareas debe ser muy importante. Si se ahorran un 10% menos de servidores tienen que ahorrarse una pasta, y supongo que para esas utilizarán c o c++. Si pueden utilizar un lenguaje de ese estilo sin el tostón de los malloc con un buen sistema de threads, y otras cositas de esas, podrán usar algunas de las mejores cosas de los lenguajes "modernos", en desarrollos de alto rendimiento.
Yo mismo hace un tiempo pensé en desarrollar unas cosillas en linux y buscando alternativas a c y c++, para desarrollos nativos, solo encontré un lenguaje denominado D que también iba por esa senda, pero lo vi todavía muy verde.
Lo importante más que el jodio lenguaje es que paguen bien por currar con el, lo que menos me importa es lo bueno que llegue a ser, me da igual programar en Java, C, C#, javascript, phyton o lo que sea, lo importante es que me paguen bien y no me hagan pasar más de 8 horas en el curro, nos preocupamos por un jodido lenguaje y dejamos lo importante en el tintero, el arribismo y tontería que imperan en el sector.
Vaya panda de lumbreras.
Al anonimo de las 12/11/2009 23:23
Mira, jbaez si hablaba de la nube, del navegador, del escritorio, etc, asi que venia perfectamente a colacion. Un programa escrito en Go no se puede ejecutar en cualquier sitio y uno escrito en Java (o .Net) si, y como ejemplo, ahi estan los applets, que escribes, compilas, y despues simplemente funcionan, tanto si el cliente esta en un W95, en un Konqueror o en FireFox en un Solaris. ¿No te parece buen ejemplo de como Java se adapta a todos los entornos? Funciona en la nube, en el escritorio... Haz lo mismo con Go.
Y probablemente haya mas opciones para hacer la parte cliente, pero cuando se piensa en clientes en un navegador se piensa en Ajax (y ultimamente en Flex), cuando con applets puedes conseguir infinitamente mas. No estaba relacionado, lo admito, pero, total, como dices que defiendo los applets (que es verdad) y ademas habia cierto desprecio por ello, pues ahi iba mi defensa. Si se te ocurre algo con lo que puedas mejorar la presentacion que te da un applet, lo dices. Y asi aprendemos.
Y en cuanto a Python, digo lo mismo; si aguantara el tipo no inventarian otro lenguaje.
Y menos uno compilado, que tienes que saber por fuerza la arquitectura de la maquina sobre la que se va a ejecutar. Google es una empresa que vende servicios desde la web (la nube, ya sabes) y en ese entorno un lenguaje compilado no es muy practico porque no saben que va a tener el cliente, pero lo que si saben es lo que tienen en los servidores. Saben que procesador tienen y que hay interprete de Python. Ahora, ¡mira! ya no necesitan el interprete de Python.
Y del blog de Rossum, ¿si no habla bien el del lenguaje quien lo va a hacer? ¿De que humor estara sabiendo que Goggle le pone los cuernos con un tal Go? Y por cierto, las aplicaciones cientificas suelen ser aplicaciones adhoc y se hacen en el lenguaje que controla el cientifico que las escribe, sin mas. Las he visto en cobol, perl, c, java...
En cuanto a "nuevos" lenguajes se refiere, me quedo con Scala frente a este Go. De todas formas a la velocidad a la que vamos en España en cuanto a adopción de nuevas tecnologías, no empezaremos a verlo hasta dentro de 5 ó 6 años...
@nilojg: Aplicando la lógica de que Go reemplaza a Python porque, según tu opinion basada en la lectura parcial de un post tiene problemas de escalabilidad, probemos el mismo criterio en lo que trajiste en su momento a colación, applets vs. Javascript, y repasemos un poco:
-Google crea un browser como Chrome -> Google pone especial énfasis en la velocidad Javascript (V8) -> Google libera pruebas para usar aceleración 3d nativa en el navegador, con javascript como el lenguaje de scripting...
Entonces, tengo que asumir que Google no usa applets por problemas de escalabilidad?...
Saludos.
Ostra, veo que mi comentario ha generado polémica…
No creo que Google, cree un lenguaje nuevo solo por Hobby, creo que este lenguaje tiene una intención mucho más grande…
Que el lenguaje sea compilado ahora, no quiera decir que no se pueda crear un compilador a la maquina virtual Dalvik, o que luego saquen algo parecido para el AppEngine e o el Chrome SO. En definitiva no creo que el hecho de que en esta primera versión del lenguaje sea compilado, no se pueda usar en un futuro en Android, AppEngine, Chrome SO.
Para el anonimo de las 13:58
No se porque Google no usa applets, pero seguro no es por escalabilidad, porque los applets se ejecutan en el ordenador cliente y no consumen nada del servidor. Pero que nada. Igual es porque no necesitan mas que Ajax porque la gente cuando se ponde delante de un navegador baja sus expectativas (la de veces que he oido decir que GMail es muy bueno porque guarda los correos segun los escribes (y he oido criticar al MSOffice por lo mismo. A la misma persona) que es lo minimi que se le pide a un editor) o tal vez sea por cualquier otro motivo que ni se nos ocurre (igual es porque si GoogleDocs fuera un applet, Google no sabria lo que escribes y no podria ponerte anuncios personalizados en GMail), incluido que por h o por b no les gusta Java.
Respecto al amigo Rossum, pues vale. Lo que quieras. Pero el siempre va a decir que Python es la pera pirulera. Incluso cuando otros tres tipos (estos si, respetados) sacan un lenguaje nuevo dando a entender que lo que hay hasta ahora no vale, incluyendo entre ellos a Python (porque Python forma parte de lo de antes). No deja de ser justicia poetica que usen el mismo argumento que uso Rossum para lanzar Python diciendo que los demas no valen. Y si usan Python en el servidor y se inventan un lenguaje paa el servidor... ¿como acaba la historia?
No hace falta que busque en Google la razon por la que Google no hace cosas escalables usando applets porque como ya te he dicho, los applets se ejecutan en el ordenador del cliente y la escalabilidad ni fu ni fa. Ademas, me puede la responsabilidad. Buscar "Google" en Google podria ser el fin de Internet...
@nilojg:
"...igual es porque si GoogleDocs fuera un applet, Google no sabria lo que escribes y no podria ponerte anuncios personalizados en GMail..." No entiendo, los applets no permiten enviar información al servidor?.
"...Incluso cuando otros tres tipos (estos si, respetados)..." Nadie mejor que tú para decir quien es la voz autorizada y quien no...
"No hace falta que busque en Google la razon por la que Google no hace cosas escalables usando applets..." Una lástima, pero hubiera estado bueno, sobre todo porque quien menciona los applets, escalabilidad, Python y Javascript todo en combo solucionable con las tecnologías asociadas con Java fuiste tú. Resumiendo, si sólo conoces un lenguaje y las tecnologías asociadas al mismo, pues úsalo como te plazca, pero sería bueno que cuando desconoces algo no te creas que leerte mal un post (insisto en que leas completamente el link que posteaste) te da idea alguna para dar opiniones tan poco realistas como las que has tenido hasta el momento.
@jbaez: Interesante lo que mencionas en tu último Post, totalmente de acuerdo. Pero como todo, tiempo al tiempo y ver que realidades aporta este nuevo lenguaje.
Saludos.@Annonimo de 17:10
Si, eso es...
Solo el tiempo lo diria
Para mi es el reconocimiento definitivo de la "secta de C(+-)" de que los demas si tenian unas cuantas cosas que enseñarles ...
En definitiva no creo que el hecho de que en esta primera versión del lenguaje sea compilado, no se pueda usar en un futuro en Android, AppEngine, Chrome SO.
Aun cuando entra dentro de lo posible, hacer un lenguaje con maquina virtual por en medio o hacerlo compilado directamente son cosas lo suficientemente diferentes como para que no se tome la decisión a la ligera y no es algo que puedas ir cambiando alegremente. Así que yo lo veo como algo muy dudoso.
@nilog
"¿Como vas a usar un lenguaje compilado para unificar esas cosas si dependes de que procesador tienes debajo? Igual el codigo fuente es el mismo (que me extrañaria mucho que sea el mismo para un intel64 con Windows, para un intel64 con kde y para un intel64 con MacOS, pero te lo concedo)"
Actualmente tu escribiras un applet y tampoco lo podras ejecutar en moviles. Por ejemplo. ¿Porqué el códgio fuente tiene que ser diferente para una u otra plataforma? El problema en C y C++ es que el tamaño de muchos tipos no está definido de forma complet, las librerias estándar son escasas y las implementaciones de los compiladores de los estándares difieren. A eso se suma el que suelen ser aplicaciones que aprovechan recursos específicos del SO y del hardware, con lo que se atan a una plataforma determinada, o al menos parte del código lo hace. En el caso de Go todo esta definido de forma completa, así que no hay razón para que el código fuente sea exactamente el mismo, siempre que dispongas de las mismas librerias. Pero esto, insisto, ya pasa en Java, donde dependiendo del tipo de dispositivo tienes diferentes especificaciones, notoriamente JME y JSE. Y no digamos dentro de JME.
"o puedes escribir un applet con swing, que sabes que va a funcionar seguro alli donde tengas un navegador con JVM, y ademas de arrastrar iconitos y sacar mensajitos, puedes abrir varios threads, hacer ruiditos"
Y un montón de jaquecas tal y como funcionan las implementaciones actuales. Y no digamos a la hora de maquetar y mantener el contenido de la web. Son útiles, si, y en muchos casos son opciones interesantes, pero con los tiempos de arranque que tienen, las limitaciones en memoria que se puede emplear, la mala integracion con el resto de la pagina donde se incrustan y lo problemático de la instalación del plugin en muchos navegadores... yo solo los recomendaria para trabajar en entornos cerrados, donde la base de usuarios está mas o menos limitada.
"Y en cuanto a Python, digo lo mismo; si aguantara el tipo no inventarian otro lenguaje."
Perdona pero no tiene ninguna base la afirmación. Primero, actualmente lo usan ampliamente en google, y que quieres que te diga... tendrá algunos problemas a la hora de escalar (no más que lenguajes como Java, Ruby o C#), pero si está siendo usado en aplicaciones accedidas por... ¿10 millones? ¿100 millones de usuarios?... entonces quizás es que buscan mejorar, lógico, una mejor herramienta para trabajar, pero que Python da la talla... eso no lo duda nadie.
"Y menos uno compilado, que tienes que saber por fuerza la arquitectura de la maquina sobre la que se va a ejecutar. Google es una empresa que vende servicios desde la web (la nube, ya sabes) y en ese entorno un lenguaje compilado no es muy practico porque no saben que va a tener el cliente"
Google busca emplear el lenguaje en el lado servidor, y hasta ahora no se han planteado otra cosa que Javascript en el lado cliente (al menos de forma generalista), que con todos sus defectos es realmente la única lingua franca que existe actualmente. Y ellos, que trabajan sobre una serie de plataformas específicas, no creo que tengan mayor problema para que sus scripts.. ¿generen 2,3 o 4 ejecutables? Además ya usan C++, y ahi los problemas de portabilidad son mayores.
Soy el anonimo de 14/11/2009 00:03, voy a hacer una aclaración, que me las veo venir :).
Cuando me refiero a que "python...tendrá algunos problemas a la hora de escalar (no más que lenguajes como Java, Ruby o C#)" me refiero a que las herramientas que proporciona Python en programación concurrente no son en esencia diferentes a las de esos otros lenguajes y porque apesar de su inferior rendimiento (fundamentalmente en benchmarks, en la realidad no es ni de lejos tan aguda la diferencia) potencialmente escalan de forma equivalente, duplicar el hardware para duplicar throughput y/o mantener latencia.
En la práctica Google usa Python porque en muchisimas aplicaciones los problemas de rendimiento no están en la CPU sino en accesos a datos (bases SQL o alternativas), latencias de red o de acceso a soporte físico (aunque no creo que google tenga demasiado problema con esto último). Además, al final muchisimas llamadas a método python están luego implementados en librerias C, o en el peor de los casos se pueden programar si es que de verdad ese es el problema.
Y si, conozco las límitaciones de python en tema de hilos, pero intrínsecamente no es tampoco el problema. ¿alguien conoce Erlang? Trabaja con user-threads (hay quien diria procesos, pero para la comparación es válido el término) y gracias a ello puede "spawnear" muchas mas "tareas" que usando un modelo basado en kernel-threads gracias a que no hay una dependencia con los límites que impone el hardware (salvo memoria y cpu para que realmente hagan algo práctico).
Para mi las intenciones de Google no son nunca claras,vamos que pueden sacar el lenguaje simplemente porque su negocio es el marketing y la imagen , es decir sacar cosas nuevas y bonitas. Pero lo que no dudo es que cuando un gigante esta detras, esto tiene tintas de convertirse en el lenguaje mas usado de cara al futuro. Para mi cuando salio C# no era mas que un clon de java que no aportaba nada serio que no tuviera Java. Lo mismo opino de este lenguaje, no es ningun mesias que venga a cambiar el mundo de la programación, ni a dar un salto cualitativo como, en mi opinion, lo hico c++ respecto a c y java respecto a C++.
En el caso de Go todo esta definido de forma completa, así que no hay razón para que el código fuente sea exactamente el mismo, siempre que dispongas de las mismas librerias.
Para ser exactos, no es del todo cierto ya que en Go tienes tipos que son dependientes de la implementación (uint, int, float y uintptr). Mientras no los use, bien.
Pero esto, insisto, ya pasa en Java, donde dependiendo del tipo de dispositivo tienes diferentes especificaciones, notoriamente JME y JSE. Y no digamos dentro de JME.
No es el mismo caso. En el primero estamos hablando de dispositivos y arquitecturas totalmente diferentes, con capacidades muy diferentes, así que es normal que no intenten hacer lo mismo. Lo contrario sería estupido. El segundo caso es realmente estúpido, pero es más cuestion de los "amables" fabricantes de dispositivos a los que la palabra portabilidad les da urticaria. Se parece más, pero en este caso es algo involuntario por parte del lenguaje.
De todas formas, no es por "echarle" nada en cara a Go. Simplemente por aclararlo.
duplicar el hardware para duplicar throughput y/o mantener latencia.
Ojala fuera tan sencillo :). Y si encima como tu mismo dices, el mayor coste está en acceder a la BDD, duplicar el hardware donde corre tu aplicación no te duplicará el througput ni-de-lejos. Es más, según como hasta puede que lo empeore. Pero eso no tiene que ver con Python, Go o C+-=.
Francamente, a estas alturas de la película lo que use Google en sus servidores me la trae al pairo, y si quieren hacer un lenguaje nuevo como si quieren hacer dos. Ahora mismo no se a comer el mundo y si lo hace, pues ya me adaptaré. Esto de "casarse" con los lenguajes o S.O. es para gente incapaz de adaptarse a los cambios.
yo opino lo mismo que uno ha dicho por ahí atrás "un nuevo lenguaje, como si hubiera pocos ya". Yo con tanto popurri de lenguajes me vuelvo loco. No entiendo demasiado de cómo se construye un nuevo lenguaje, pero lo que sí está claro para mí es que lo hagan como lo hagan lo importante es que la sintaxis no cambie mucho ya que es una locura aprenderse 5 sintaxis distintas para programar (javascrip,php,c++,c#,asp,html,xml,sql etc.) Lo que había era que poner una norma (igual que se normalizan medidas, y muchas otras cosas) normalizar ciertos aspectos de los lenguajes de programación, de lo contrario va a ser una locura ser programador. Yo programo en todos los lenguajes que he mencionado pero os juro que no me sé la sintaxis de ninguno, es imposible. Cuando en una entrevista me mandan hacer un programa tengo que llevar todos los programas que yo tengo hechos si no es imposible. Y ahora viene google y inventa otro... es otra estrategia más para monopolizarlo todo (¿para cuando un sistema operativo google?). Ojalá explote la burbuja google de una vez.
Esto se ha movido el fin de semana...
Anonimo de las 00:03, admito que JME no es muy estandar que digamos, pero es que yo mismo hago mencion a JME en el mensaje original (y no se donde he leido que el proximo JME sera una implementacion completa) porque es muy problematico, pero dejando de lado JME, un applet escrito en swing funciona en todas partes siendo compilado una sola vez, que en Go en el mejor de los casos tendras que compilar varias veces y seleccionar que version envias segun el navegador. Me extraña que el codigo fuente sea el mismo, no por el tamaño de los datos, qie seguramente el corazon de un programa escrito en Go, lo que trabaja, si sea igual, si no que me extraña por los botoncitos de Windows, KDE y MacOS, que seguramente seran muy diferentes y tu codigo para crear un combo y dos botones no sera el mismo en cada entorno. Es el problema que tiene .Net. Es portable, si, pero las ventanitas no.
En cuanto a los applets, si dan problemas si intentas integrarlos en una pagina, pero es que yo no me refiero a eso. Yo me refiero a que toda la pagina sea el applet. A que al entrar en GMail te salga un frame con el Outlook. O al procesador de textos de ThinkFree. No hay nada que integrar con el navegador. Tu haces tu aplicacion Swing como quieras y primero escribes una funcion main que la lanza, y despues, un applet que pinta un boton y en su eventlistener copias la funcion main (no sera una copia tal cual, pero no tendras que cambiar mucho). Igual tienes que firmar el applet o tienes que lidiar con los policies, pero se puede hacer.
De hecho, lo he hecho, y en esta pagina (http://personales.ya.com/nimrod/applet.html) puedes ver que el applet que se usa es el mismo que descargas (en el que no esta firmado, el que esta firmado es otro jar) para ejecutar desde tu escritorio o para usar como libreria, y el cuadro de dialogo realmente no sabe si se ejecuta en un escritorio en un navegador, en Linux o en Windows. Pues puedes hacer un cliente de correo o un ide de la misma manera (no me atrevo a decir que Netbeans pueda ser un applet porque hace demasiadas cosas y tiene plugines de mucha gente, pero podria). Aunque estoy de acuerdo en que son mejores en entornos cerrados (que ya es estar en un monton de sitios) por si las moscas. Pero aun asi, daran menos guerra que Ajax (lo se porque uso Opera).
Y hable de applets solo como ejemplo real de algo que si unifica varios entornos, que es como surgio esta larga cadena de correos. Estoy de acuerdo en que Go es un lenguaje de servidor porque al ser compilado tiene mucha dependencia de la maquina. Lo de Python en realidad es solo por joder a un anonimo que parece muy emocionado con Python y tiene los modales empeñados. Ninguno sabemos cuanto se usan Python, C, Java o la maquina de cafe en Google porque los tios no cuentan nada, asi que todo lo que digamos son suposiciones, pero por las caracteristicas de Go, lo que esta claro es que dentro de Google es un rival directo de Python, porque ambos se usan en el servidor, ambos parecen lenguajes "agiles" (sea eso lo que sea, pero parece que es poner nombres cortos o ahorrarse puntos y coma) y, bueno, siempre se dice que Python es el lenguaje que Google usa en el servidor, asi que si sacan un nuevo lenguaje para el servidor... Tal vez es que estan tan contentos con Python que ellos mismos le cavan bajo los pies para que no se le suba el exito a la cabeza.
No dudo que Python sea la pera en rendimiento (bueno, si) pero se que Google tiene miles de maquinas, gasta millones de vatios y ahorrarse un 1% de todo eso es mas dinero del que voy a tener en toda mi vida. Y seguro que ahorran mas de 1% quitando python.
En cuanto al anonimo de las 17:10, vamos a ver, esto no es barrapunto. Aqui no basta con insinuar que los applets son malos sin decir porque, y menos, menospreciar a alguien por sus opiniones cuando pone un ejemplo. Y menos si dices cosas que se caen por su peso. ¿Como algo que se descarga y consume recursos de cada pc cliente no va a ser escalable si no consume en el servidor? ¿Como justificaria Google que GoogleDocs enviara a casa cada tecla que pulsa el usuario sin cargarse el "don't be evil"? ¿Como puedes comparar a Rossum con unos tios que coleccionan premios Turing? ¿Que sabras tu lo que yo se o dejo de saber? No soy el tio mas listo del mundo ni mucho menos, ni el que mas contribuye, ni el que mas hace ni nada, pero explico mis opiniones cuando las tengo y procuro no menospreciar a los que "hablan" conmigo, aunque opine algo radicalmente distinto, porque se puede discutir con alguien y respetar su punto de vista al mismo tiempo.
Tengo la sensacion de que si no hubiera dicho que Go esta para sustituir a Python no habrias respondido. ¿Has entrado aqui para defender Python o para hablar de Java (tematica del portal) y Go (tematica del hilo)?
Mirando un poco go y sus caracteristicas se trata de un lenguaje para sistemas, no creo que esto tenga nada que ver con sustituir a python, más bien con sustituir a C (ni siquiera a C++) y hacer la programación de sistemas un poco más amigable, sobre todo pensando en multihilo y tal (¿habeís desarrollado aplicaciones multihilo en C o C++?, un rollo tremendo), aunque lo poco que he visto de la sintaxis de Go no me ha gustado nada la verdad.
Por cierto, yo sigo a lo mio xd, segundo lenguaje que sale de las manos de investigadores de google que no utiliza herencia (de tipos en este caso que no hay clases), en este caso el argumento es que prefieren que los tipos cumplan roles, uno o varios, mediante implementación de interfaces a que los tipos sean derivados de tal o cual, es la idea de dar mayor importancia a los mensajes (definidos en interfaces) que a la estructura estatica de objetos (definida mediante relaciones de herencia de clases/tipos), un enfoque de diseño con el concuerdo bastante. Es decir, el lenguaje soporta polimorfismo mediante la implementación de interfaces y la reutilización se logra por composició, así me gusta :P
No se cuanto se usa Go, Noop y demás inventos de Google, ahora bien, hay que tener en cuenta que en Google existe la política de que el empleado tiene un 20% de su tiempo o algo así (no se el valor concreto) para inventar lo que les de la gana por si suena la flauta. El que tenga el logotipo de Google no significa que esté "bendecido" por Google mega-empresa.
Lo que me sorprende absolutamente es la ganas de reinventar la rueda DESDE CERO en vez de apoyar iniciativas que tendrían mucho más éxito como por ejemplo dar un empuje a C++0x que es en teoría la evolución de C++, o bien romper la baraja y hacer un C++ "reificado" con algunas de las cosas buenas que tiene Java y quitando aquellas más problemáticas de C++ si es necesario.
Otra cosa que me sorprende es la ganas que tienen algunos de rescatar lenguas muertas tal y como el Pascal.
Parece una tontería pero no entiendo la diferencia SUBSTANCIAL que existe entre:
int a;
var a:int; (Go utiliza una variación de esta sintáxis de Pascal)
En el primer caso es una sintaxis utilizada por la inmensa mayoría del código hecho en el mundo, en el segundo, es la sintaxis de propia de lenguajes semi-muertos y lenguajes que son "eterna promesa".
A mi no me importaría cambiar a una sintaxis tipo Pascal, de hecho doy clases con esa sintaxis, pero cuando veo sintaxis tipo Pascal en lenguajes nuevos (por ejemplo Scala) y otras sintaxis "novedosas" no puedo evitar el oler a rancio academicismo ajeno al mundo o a GANAS DE INCORDIAR, es decir a aparentar que es algo nuevo, pienso sobre todo en Scala y en JavaFx.
Olvidan que C++, PHP, JavaScript, C#, Java (o Groovy) etc se aprenden a nivel básico en dos patadas cuando tienes un bagaje de C, estoy seguro que el código generado de todos ellos juntos suman más del 90% del código existente del mundo. Por eso no puedo evitar el mirar con desconfianza a aquellos lenguajes que son más de lo mismo pero con el único mérito de inventar una nueva sintaxis, me huele a pretencioso y a soberbio y si encima quitan la herencia de implementación ya ni te cuento.
Respecto a quitar la herencia de implementación ya sabeis que en mi opinión es... suicida.
Afortunadamente el lenguaje que más apunta a ser el futuro, Scala, no sólo tiene la herencia de siempre sino que además tiene una forma light de herencia múltiple, lo cual yo hecho de menos todos los días cuando en ocasiones me veo obligado a hacer *delegaciones forzadas*.
@nilojg
"..Lo de Python en realidad es solo por joder a un anonimo que parece muy emocionado con Python y tiene los modales empeñados..."
Quien nombra inicialmente a Python eres tú, y no se en respuesta a quien...
"Ninguno sabemos cuanto se usan Python, C, Java ..."
Perfecto, es bueno que te vayas dando cuenta que comenzaste a criticar sobre una supocición tuya y sin fundamentos.
"...¿Que sabras tu lo que yo se o dejo de saber?..."
Tienes razón, no te conozco personalmente por lo que mi única opción es basarme en tus opiniones, y las muestras que has dado es que:
Hablas de Python y no sabes Python.
Hablas de Javascript y no sabes Javascript.
Hablas de Applets... conoces de applets? conoces si es para google siquiera una alternativa?.
Y luego entra el verso de que la escalabilidad, y que reemplaza a otro lenguaje, y que quien colecciona premios, y lalala.
"...Tengo la sensacion de que si no hubiera dicho que Go esta para sustituir a Python no habrias respondido. ¿Has entrado aqui para defender Python o para hablar de Java (tematica del portal) y Go (tematica del hilo)?..."
Muy gracioso, pero si busco el primer lugar donde aparece la palabra Python, adivina de quién es el post...?
Saludos.
anonimo: Hablas de Applets... conoces de applets?
Al último anónimo, creo que te estás columpiando:
http://personales.ya.com/nimrod/applet.html
Nilojg: En fin, que comparar lo que puedes hacer con esa chapuza que es Javascript y Ajax con lo que puedes hacer con un lenguaje de verdad como Java y los applets es como comparar... pues no se me ocurre una comparacion que no sea ofensiva, pero es que no tiene comparacion.
Me duele darte la razón aunque la tienes, el problema es que la "gente" quiere web, web y web, los applets perdieron la batalla, podrían tener el lugar que tiene ahora Flash pero ni eso, a estas alturas las razones ya son lo de menos.
@jmarranz
"...Al último anónimo, creo que te estás columpiando:..."
No lo creo, lo que digo fué en base a lo que @nilojg dijo en un post anterior:
"...igual es porque si GoogleDocs fuera un applet, Google no sabria lo que escribes y no podria ponerte anuncios personalizados en GMail...".
Lo cual es algo que no termino de comprender... cómo es que si se generaran documentos en GoogleDocs usando un applet, y estos se guardan en la (oooohhhh!) nube, Google no puede saber el contenido de los mismos para generar publicidad?.
Saludos.
@jmarranz
"
Parece una tontería pero no entiendo la diferencia SUBSTANCIAL que existe entre:
int a;
var a:int; (Go utiliza una variación de esta sintáxis de Pascal)
"
Entonces deberias implementar un compilador ... Pista: los de Go afirman que pueden compilar sin tabla de simbolos y bastante rapido por cierto ... Crees que Kernighan y Pike no tienen ni idea de compiladores de C?
jmarranz, tienes razon, los applets perdieron la batalla porque llegaron demasiado pronto, cuando las redes eran lentas, pero no estoy de acuerdo en que la gente quiera web, web y web.
Igual nosotros si distinguimos la web-applets (los applets tambien son web) y la web-otracosa, pero a la gente normal eso le da igual, porque no distingue que es cada cosa. La gente quiere funcionalidad y usa la que le damos.
Por ejemplo, ultimamente estan apareciendo "discos duros" en la web, almacenamiento en la nube. Yo conozco tres y los tres tienen el mismo esquema: un applet para subir cosas y un adminsitrador de archivos hecho con ajax o html mas o menos dinamico. El applet esta ahi porque ofrece una funcionalidad que no se puede obtener de otro modo, que no es ni mas ni menos que subir varios ficheros a la vez arrastrando desde el escritorio. La presencia del applet acarrea todos los insalvables inconvenientes de los applets, como es tener que tener un jre instalado, el navegador con el java habilitado y darle al boton de "aceptar" cuando un dialogo te dice que el applet lo firma "FulanitoSoft" (¿para que van a pagar un certificado de una autoridad reconocida?).
En cambio, la administracion de archivos en si se hace con html, ajax... y ofrece menos funcionalidad de la que ofrecian las pctools del msdos. Mas colorines, mas resolucion, pero menos funcionalidad. Y el aspecto tampoco esta mucho mejor que el que ofrecia el adminsitrador de archivos de Window 3.1. Tal vez con ajax se pueda hacer algo mas, acercarse a lo que hace el Dolphin de KDE, pero es mucho mas complejo, asi que se quedan en lo que los pcs hacian hace 15 años. Y nada de efectos especiales, que eso es para los iPhones.
¿Y como funcionan? Arrastras un directorio de tu escritorio al pequeño cuadradito que ocupa el applet y este sube los ficheros al directorio que esta seleccionado en el html de la pagina (y con suerte, no los va desperdigando si te dedicas a cambiar de directorio mientras suben). Funciona, si, pero si TODO fuera un applet podria arrastrar el directorio directamente a la carpeta a la que quiero arrastrar, igual que haces con tu ordenador. Incluso podria mostrar tambien el arbol local para no tener que abierto el navegador y un administrador de archivos. Y tener presentaciones preliminares, encriptar, subir a otro servidor por ftp... o lo que sea.
El usuario usa lo que le damos, y se adaptara a lo que tenga, sea lo que sea. Y si le damos poco, rebajara sus expectativas segun donde este y pensara que solo los de Apple saben hacer cosas practicas.
El problema es que la experiencia de usuario ha dejado de ser importante. Pasamos mas tiempo hablando de como desarrollamos que mirando el resultado final. Nos pasamos el dia debatiendo si ahorrarte declarar variables o usar nombres cortos aumenta la productividad, o buscando la manera de no escribir codigo boilerplate (¿como puede ser el sql boilerplate en una aplicacion que maneja datos si no hay nada mas importante que los datos?) usando decenas de librerias. Pero al usuario que le den. Por eso los applets han perdido la batalla, porque la funcionalidad es lo de menos.
Y respecto a la sintaxis de Go, pues me parece normal que la cambien. Asi nadie les acusara de copiar. ¿Nunca has oido decir que Java es una mala copia de C++? La sintaxis es parecida, asi que se ha copiado. No tiene nada que ver que en ejecucion se comporte distinto, que el concepto de lenguaje sea diferente. Ni siquiera se admite que es para reducir la curva de aprendizaje. Es por copiar.
Asi que los de Go cambian la sintaxis para que no les acusen de copiar, lo que ademas les permite no usar tabla de simbolos y compilar rapidamente, como dice nuestro experto anonimo. De hecho, solo asi puede no usarse una tabla de simbolos y hacerlo rapido. Si en vez de "var a:int" fuera "var a - int" o "int a" o incluso "bar a:int" ya estarian obligados a usarla. Y ademas se compilaria mucho mas despacio. Solo puede ser "var a:int".
PD: lo ultimo, naturalmente, es ironia.
PD: y la aclaracion es para el anonimo.
nilojg: jmarranz, tienes razon, los applets perdieron la batalla porque llegaron demasiado pronto, cuando las redes eran lentas, pero no estoy de acuerdo en que la gente quiera web, web y web.
Y porque había que descargar un plugin enorme (el JRE), porque tardaba infinito en cargarse la JVM, porque la integración con el navegador no era muy buena a nivel de JavaScript, porque cuando era necesaria una versión adecuada del plugin el plugin no te invitaba a actualizarte de una forma "para tontos", porque Microsoft con su JVM la lio parda (virus, agujeros de seguridad, incompatibilidades), porque el AWT era muy pobretón y poco "cross-platform", porque Swing en su momento no formaba parte del paquete estándar y había que descargarlo bajo demanda (un enorme jar), porque Swing hasta hace poco ha funcionado regular, porque el caché siempre se ha pasado de listo (lo estoy sufriendo ahora al soportar Batik en applet para ItsNat, estoy obligado a recargar el navegador constantemente), porque el espacio de acción visual es únicamente el cuadrado del applet, porque la renderización de HTML y soporte web en general en Java ha sido siempre siempre muy pobre (anecdótico más bien), porque el vídeo y el audio han estado totalmente olvidados en Java, porque el diseño visual es mucho más sencillo de hacer con web que con Swing, porque el mundo applet es más para programadores "hard-core" y el mundo web está más abierto a los diseñadores gráficos, porque las herramientas de integración cliente(applet)/servidor (servlets) casi brillan por su ausencia, por las dificultades de generación "dinámica" del applet obligando a cargar la aplicación entera en el cliente con evidentes problemas de seguridad, publicación no deseada del "saber hacer" etc etc
En fin... ahora ya es un poco tarde, los navegadores han mejorado muchísimo y cada vez más el entorno web es menos anémico y la integración y/o comunicación cliente/servidor puede llegar ser fabulosamente transparente y sencilla (que te voy a contar), en el mundo móvil el web se apunta como la plataforma del futuro con algo de Flash...
De todas formas te doy la razón, si a tu usuario no le importa tener sus aplicaciones "web" en applets, Java es una apuesta mucho más robusta que la locura del mundo web y la potencialidad de lo que se puede hacer es muy superior.
Escribe tu comentario