Uma linguagem com as facilidades sintáticas de Python, porém estática e que gere executáveis com opcodes com pouca dependência e desempenho similar aos de C e que desfrute dos recursos computacionais de concorrência que os atuais processadores e computadores oferecem com facilidade é algo que muitos, a muito tempo desejavam.  Conheço engenheiros que só tem C e Assembly como opção e que sempre costuma afirmar que “odeiam C”, pelos clássicos problemas da linguagem e compiladores.

Para minha surpresa li este artigo ontem no Slashdot:

Go, Google’s New Open Source Programming Language

E como ele fazia referência a um artigo na ARS Technica, fui conferir a notícia:

Go: new open source programming language from Google

Go, como toda linguagem,  nasceu de necessidades, frustrações e certamente surpreenderá,  logo criará uma legião de fãs assim como frustrará muitos outros, mas sendo Open Source e com uma licença BSD-Style ela tem potencial de agregar muitos  desenvolvedores ao seu core-development. Particularmente eu já instalei, comecei a brincar já me frustrei mas amei as goroutines.

O dilema que está em sua motivação é muito parecido com o que alguns já passaram em certos desenvolvimentos, escolher entre uma linguagem com compilação eficiente, execução performática e facilidade de programação; para oferecer tudo isto nativamente numa única linguagem de programação os autores resolveram partir para seu desenvolvimento.

Para quem dizia que eu era meio maluco por gostar de Haskell, Erlang, C++ e Python e uma linguagem ideal seria a que fosse uma composição de características de todas elas, tive uma fantástica surpresa, além de uma (quase) decepção!

A surpresa fantástica, veio pelo fato que o Google busca com este empreendimento:

- “Uma nova linguagem de programação que busca a performance com concorrência embutida, que é quase comparável a C, mas com a sintaxe mais expressiva e compilação rápida” e além de tudo ela tem pedigree! Pois entre seus projetistas estão Robert Griesemer, Russ Cox, Rob Pike (um dos pais da linguagem Limbo e do Plan9) e Ken Thompson;  K, apesar de dispensar apresentações  apenas para recordar ele  é um dos pais da linguagem B,  do UNIX e também trabalhou no projeto do Plan9.

Da ARS Technica eu fui direto para o site do projeto: golang.org

E encontrei mais algumas definições curiosas:

- “Go” buscou inspirações em todas estas linguagens para criar uma de propósito geral, projetada com “systems programming” em mente, “fortemente tipada” (aqui eles não beberam na fonte de Python) e com uso de garbage-collect (tsc) com suporte nativo a programação concorrente  e com gramática compacta e regular, isto tudo soa muito interessante.

Porém, no site do projeto um dos links me chamou muito a atenção:

Go for C++ Programmers

Como o foco dela é “system programming” e por  suas características performáticas, de cara já forçar um replace de C++ era esperado. Será este um grande golpe em C++ ou um golpe mortal na linguagem D? Por outro lado lembro-me da afirmação do Herb Sutter que os programadores C++ são os mais abertos a aprenderem novas linguagens, esta afirmação nem sempre me parece verdadeira, mas para os casos onde ela se aplica (que são muitos) o foco do Google parece estar correto.

Agora, veja esta simples comparação sintática:

Go                           C++
var v1 int;               // int v1;
var v2 string;            // const std::string v2;  (approximately)
var v3 [10]int;           // int v3[10];
var v4 []int;             // int* v4;  (approximately)
var v5 struct { f int };  // struct { int f; } v5;
var v6 *int;              // int* v6;  (but no pointer arithmetic)
var v7 map[string]int;    // unordered_map<string, int>* v7;  (approximately)
var v8 func(a int) int;   // int (*v8)(int a);

De cara ela me irrita  pois var me lembra Pascal, mas a declaração de struct me pareceu mais elegante e prefiro declarações explícitas de funções, classes e métodos, ponto para Go.

Outro detalhe que me chamou a atenção é que por enquanto há compiladores disponíveis para Linux e Mac OS X que geram opcodes para AMD64 (x86 e 64 bits), x86 de 32 bits e está no forno um compilador ARM! Será que ele permitirá compilação bare-metal para produção de firmware? Tenho suspeita que sim.

Vejam algumas diferenças conceituais entre C++ e Go:

• Go não tem classes com  construtores ou destrutores. Mas sim  métodos de classe, uma hierarquia de herança de classes e funções virtuais, ela  fornece interfaces que são utilizadas como os templates de C++; portanto ela oferece programação genérica.
• Go  usa garbage collection.  Não é possível  liberar memória explícitamente.  Este gerenciamento de memória “pretende” ser incremental e  altamente eficiente em processadores modernos.
• Go tem ponteiros, mas não a aritmética de ponteiro. Não é possível empregar um ponteiro para percorrer os bytes de uma string.
• Arrays são valores de primeira classe. Quando um array é usado como um parâmetro de função, a função recebe uma cópia da matriz, não um ponteiro para ele. No entanto, na prática, muitas funções usam “slices” de parâmetros; “slices” suportam os ponteiros para arrays subjacentes. “Slice” é um recurso importante da linguagem.
• Strings são fornecidas pela linguagem. Mas elas não podem ser alteradas depois de sua criação.
• Tabelas hash são fornecidas pela linguagem. Eles são chamados de maps.  Velhos conhecidos de outra linguagens.
• Threads são separadas da execução, e os canais (channels) de comunicação entre eles, são fornecidos pela linguagem.
• Certos tipos (maps e channels)  são passados por referência, não pelo valor. Ou seja, passar um map para uma função não é copiar o map, e  as alterações da função do map são vistas pelo invocador.  Como referências de tipos de C++, porém mais similar como é em Python.
• Go não usa “header files”. Em vez disso, cada arquivo fonte é parte de um package definido, similar a Python, Oberon e Pascal. Quando um package define um objeto (tipo, constante, variável, função) com um nome começando com uma letra maiúscula, esse objeto é visível a qualquer outro arquivo que importe esse package.
• Ela não oferece suporte a conversão implícita de tipo. Operações que misture tipos diferentes requerem casts (que em Go são chamadas de conversions).
• Go não suporta sobrecarga de funções e não suporta os operadores definidos pelo usuário.
• Go não suporta os qualificadores const ou volatile.
• Ela  usa nil para ponteiros inválidos e  C++ usa NULL ou simplesmente 0.

Sobre as diferenças sintáticas recomendo realmente a leitura da página Go for C++ Programmers, mas antes a leitura dos documentos Tutorial, Effective Go,  Language Design FAQ, Language Specification entre outros documentos para o  entendimento de alguns conceitos como as fantásticas goroutines. Porém se o tempo permitir, assista a apresentação do Rob Pike  no Tech Talk, chamada What is Go?

Confesso que algumas características não me agradaram muito, já outras me pareceram muito interessantes, porém ainda é cedo para apresentar uma avaliação. Entrei na Go Nuts! que é a lista oficial da  linguagem e com 2 dias de existência ela já tinha mais de 800 mensagens e 1.200 membros. Será que esta linguagem irá revolucionar? Um ponto positivo é que ela é Open Source porém patrocinada pelo Google, well… tenho minhas suspeitas que sim e em pouco tempo ela irá causar uma reviravolta.

Maiores detalhes acessem o site oficial do projeto: golang.org

PS: Já estou vendo os anúncios de emprego solicitando programadores com 2 a 5 aos de experiência em G0, antes mesmo do lançamento da linguagem completar 1 ano!

É com grande prazer que depois de alguns meses sem postar nada por aqui, venho quebrar o silêncio com uma notícia super interessante.

Depois do sucesso do evento do ano passado, este ano o Portal Embarcados, a Tempo Real Eventos e o grupo C & C++ Brasil realizará a segunda edição do Seminário C & C++ para Sistemas Embarcados.

Com palestrantes  de alto-nível e conteúdo super-interessante,  como o do ano passado, ele está imperdível!

Ele  acontecerá no dia 14 de novembro de 2009, em São Paulo, no Century Hotel, maiores detalhes vejam aqui.

Nos vemos lá.

Nasmastê!

    Em 1996 eu fiquei extremamente feliz quando recebi minha edição da Dr.Dobbs e vi um artigo escrito por brasileiros chamado “Lua: an extensible embedded language”, confesso que fiquei tão surpreso que acabei comentando com vários colegas sobre o artigo e sobre esta linguagem que eu já tinha ouvido falar mas não conhecia ainda e acabei ficando com o estigma de ser o “cara do Lua” por alguns meses. Oito anos depois, ao encontrar um colega de faculdade ele veio me perguntar se eu “ainda” programava em Lua.

    Após 11 anos, tive outra boa surpresa quando conheci o projeto eLua, que é mantido pelo romeno Bogdan Marinescu em conjunto com o brasileiro Dado Sutter  do laboratório LED da PUC-Rio, que basicamente é um projeto que insere Lua no contexto de programação de microcontroladores, oferecendo melhor reusabilidade de código e redução de complexidade e custo de desenvolvimento. 

    Hoje ele tem suporte para as plataformas LM3S, AT91SAM, STR9, STR7, LPC2888, i386 e segundo o Dado Sutter logo o eLua estará suportando novas MCUs, assim como mais exemplos tem sido escritos com boa frequencia e novos módulos estão em desenvolvimento.  Eu o testei no meu AT91SAM7×256 e  fiquei muito entusiasmado com o projeto.   

    Para quem ficou interessado em saber um pouco mais sobre o e-Lua,  o projeto está com um novo site – baseado no Sputnik  que é um Wiki engine 100% escrito em Lua –  e a URL oficial do projeto é   www.eluaproject.net

Talvez um teco influenciado pelo documento “Prospectiva Estratégica, Metodologia de Descrição de Cenários” temperada a puro palpite visionário, outro dia quando na piclistbr o Mak lançou esta:

1996 – um supercomputador usava 10 mil processadores Pentium Pro clocados a
200 MHz pra atingir 1 teraflops (um trilhão de operações matemáticas por
segundo). ocupava um andar inteiro de um laboratório no Novo México. Ele
consumia absurdos 500 kW e, pasme, mais 500 kW só de cooler, ar-condicionado
e tudo o mais para manter a sala geladinha e não pifar a bagaça.

2008 – uma Radeon HD 4870, placa de video das mais rápidas atualmente,
atinge esse mesmo número de flops com apenas um chip. A placa de vídeo da
AMD, assim como as outras dessa categoria, cabe num slotzinho PCI Express e
gasta 110 watts, o que já é uma cavalice.

2015 – tentem fazer uma projeção…

Fonte: PAPO DE MICREIRO: O lado hardcore da tecnologia,    Placa de vídeo ou arma de detonação em massa? por Marco Aurélio Zanni

E lancei o seguinte cenário:

2050: Life, the Universe and Everything: q-bits e processamento de
chuckflops por segundo serão triviais. Seth Lloyd e Miguel Nicolelis
serão mais populares que Von Newman e Alan Turing. Haverá dispositivos
computacionais com processamento de chuckflops do tamanho de um
alfinente usados como implantes com baterias recarregáveis via
wireless. Todo boteco terá um recarregador wireless. Estes implantes
computacionais usarão o protocolo 802.11xyz para se conectar com a
spacenet, seja da Terra ou de Marte e a segunda língua mundial será o
chinês. Via 802.11xyz q-telepatia será algo muito comum; porém isto
será coisas para os jovens, a galerinha de 80 e 90 anos ainda usará
menssegers baseado nos protocolos XMPP em seus handhelds.

A plebe ainda usará estes dispositivos de 2015, com PCs digitais com
placas de vídeo com meros 100 teraflops consumindo os exagerados 70
Watts, utilizando toda a arcaica tecnologia digital binária. Ainda
existirão analfabetos digitais e ONGs lutando contra a fome mundial,
isto em 2050.

2100: Em 2100 os Estados Unidos elegerá o primeiro presidente
marciano, descendente de terráqueos chineses e brasileiros, que foram
para a colônia marciana em 2060, que se promoveu a base de q-telepatia.

(…)

OK: Para justificar este minha prospecção eu teria que escrever um relatório de mais de 100 páginas, mas está aí um cenário factível, não exatamente nestas datas e com esta terminologia, mas num futuro não muito distante.

Numa conversa de boteco a uns 6 anos atrás com alguns colegas, falávamos de bits, bytes, C, programação, redes e clusters; eis que surge uma idéia  (talvez inovadora) de distribuição de carga em clusters utilizando pirometro óptico, termômetro digital, amperímetros criando uma grande rede de sensoriamento visando não apenas o balanceamento computacional mas também a economia de energia através do equilíbrio térmico e de consumo de energia no datacenter. Foi neste contexto que foi inserido o assunto microcontroladores na conversa e a maioria dos colegas que estavam na mesa ficaram fascinados. Curiosamente, lendo o blog Arquitetura em Pauta o Otávio comentou que no PDC houve uma apresentação que demonstrou solução similar e vejo agora que a viagem não era tão grande.

Mas voltando às conversas de boteco, já naqueles tempos conversávamos sobre a idéia de encontros e eventos específicos para programadores de C & C++, sendo-se que dentre estes ao menos um deveria ser exclusivo de embedded systems voltados para microcontroladores e como já comentado anteriormente que iria ocorrer, foi realizado no dia 08/11 o seminário C & C++ para Sistemas Embarcados, onde o foco foi adivinha o quê? Sobre o que lá ocorreu, é possível ficar sabendo pelos blogs do DQ , P. e do Diego, assim como por threads na ccppbrasil, programa embedded software e sis_embarcados.

Em paralelo, num outro evento que estava ocorrendo no mesmo dia em São Paulo, o Lameiro e uma galera do Grupy-SP  fez uma implementação pitoresca de sensor networks utilizando AVR numa placa Arduino Diecimila que pela idéia inovadora recebeu um prêmio especial.

Portanto vemos que o assunto microcontroladores está ficando cada vez mais pop, assim como sensor networks que tem sido o campo onde microcontroladores tem sido largamente utilizados, seja para segurança da informação, segurança privada ou telemetria; tornando telematics algo cada vez mais presente em nosso dia-a-dia.

E os feedbacks do seminário foram excepcionais, muito acima do normal, mais críticos do que recebemos dos outros eventos, superando expectativas e nos mostrando que este público de embedded systems quer eventos diferentes do que eles estão acostumados a presenciar, quase nos intimando a repetir a dose e experimentar outros formatos mais ousados; o que na medida do possível tentaremos realizar. Portanto, pedido anotado!