langage Go de google

Thu Nov 12 14:14:53 UTC 2009

English (for Jeremy, at least) :
I made it from google translate and reread it to remove misunsderstanding
:

Indeed, google works on our flowerbeds, google actually has enormous
resources. Moreover, there are two gurus behind, which may have given weight
admiration (deserved) one can testify to these people.
But we must see that Go is a compromise based on existing technologies as
standard within the industry. It is a language with pointers (even when
removing the possibility of too much crap with), not object, so everything
that follows (genericity, inheritance, etc. ...), no exception system and
assertions, nothing to handle errors. No operators either!
It remains to separate compilation, which involves limited performance
This page http://golang.org/doc/go_for_cpp_programmers.html particularly
http://golang.org/doc/go_for_cpp_programmers.html#Interfaces explains the
system object of Go .. Say it is original, but far from the power Lisaac.

Another point: The audit compilation
Lisaac's philosophy is to have a compiler ultra uncompromising, like Caml.
It is also why I choose "compilation" on the issue of Mildred yesterday.
There's nothing worse than to debug as you go. A compiler uncompromising
assure you that you won't have too many more problems when the compiler say
"OK".
It is very important because it avoids a lot of problems, and it saves a lot
of _productivity_
The null detection at compile time, it's huge.
I spent several years coding in Java in IT companies and now I can tell you
that the bug fixes like cast and especially Call on Null is usualy 10% of
costs in a project! It's huge!
Must realize that in a software companies, on large programs, a bug, it's a
whole cycle to meet: assignment of the anomaly to a programmer who have to
understand code someone else has written, bug fix, launch whole string of
tests, etc. ...

I think that this language has much future as he filled out the condition
defined by Richard P. Gabriel (Models of Software Acceptance)
http://www.dreamsongs.com/Files/AcceptanceModels.pdf (review this
presentation is fabulous!)
- Accessible language without requiring too many abstractions
- Gurus behind
- Google behind (no gambler can ruin)
- Language similar to the existing
- Language design relatively simple, consistent and sufficient for its
target.

Despite all this, Lisaac has :
- Truly Object: need to see that for a lot of people, and particularly a fan
of C + +, there is less stuff in Go:  No template, really powerful features
of the object, no type blocks, etc. ... Gonna make frustrated!
- Performance: Even with a good compiler and a language easier to optimize,
separate compilation  will anyway be a cul de sac
- Deactivated GC: yes in lisaac can do it easily
- COP: COP I think is slightly better than CSP: not manage channel, for
example, automatically.
- Compiler uncompromising: it is a fundamental point, I repeat: the guy code
on the board knows it has much less potential errors when the compiler says
that everything is ok. And as Nicolas has often said : when you got 64K of
memory, you're not up to a debugger.
- Some features really high level, that are happening in the language
- Introspection, suspicion appearance with contracts that will make very,
very driven frameworks (frameworks web oriented rules, etc ...)
- The templates automatically, which will explode shack level perf.

I'll talk more specifically later, but our added value is: "expand quickly
with the best possible perfs. And what has been occurring now?
Smartphones! They are needed everywhere ... In a few years they will start
the mobile concuurencer classic is that they will connect a keyboard or a
larger screen, and they will serve as office equipment. This will mean - not
to mention the change in attitude towards ecology and therefore the best
eco-efficiency (also Americans who were behind us 10 years ago, will go
ahead, so it will be a huge change) - that software can offer the same
service using less (because the code will be more effective), will become
very interesting.
Same for the Game you imagine UT2003 in Go ?
Hmm ... One can easily beat them in terms of perf.

In short, do not get discouraged, it is not exactly the same target, and
there are big advantages, he will have to tackle to implement them properly,
and good sauce to go around (that's my job) .

French :

Effectivement, google marche sur nos platebandes, effectivement google a des
moyens énormes. Qui plus est, on a deux gourous derrière, ce qui risque
d'avoir du poids vu l'admiration (méritée) qu'on peut témoigner à ces gens
là.
Mais il faut bien voir que Go est un compromis basé sur les technologies
existant en standard au sein de l'industrie. Ca reste un langage avec des
pointeurs (en enlevant quand même la possibilité de faire trop de conneries
avec), pas objet, donc tout ce qui s'ensuit (généricité, héritage, etc...),
pas de système d'exception et d'assertions, donc rien pour gérer les
erreurs. Pas d'opérateurs non plus !
Ca reste de la compil séparée, ce qui implique des performances limitée
Cette page http://golang.org/doc/go_for_cpp_programmers.html et
particulièrement
http://golang.org/doc/go_for_cpp_programmers.html#Interfaces explique le
système objet de Go... Disons que c'est original, mais loin de la puissance
de Lisaac.

Un autre point : La vérification à la compilation
La philosophie de Lisaac, c'est d'avoir un compilateur ultra intransigeant,
un peu comme Caml, c'est pourquoi d'ailleurs, j'ai répondu "à la
compilation" sur la question de Mildred hier.
Ya rien de pire que de debugguer au fur et à mesure. Un compilateur
intransigeant t'assure que t'auras plus trop de problème dès lors que le
compilateur est content.
C'est très important parce que ça évite énormément de problèmes, et ça fait
gagner beaucoup de _ productivité _
La détection des null à la compilation, c'est énorme.
J'ai passé quelques années à coder en Java en entreprise et je peux vous
dire que les corrections de bugs style cast et surtout Call on Null, c'est
10% des coûts dans un projet ! C'est énorme !!!
Faut bien voir que dans une SSII, sur des gros programmes, un bug, c'est
tout un cycle à respecter : affectation de l'anomalie à un programmeur,
compréhension du code qu'un autre a écrit, correction du bug, lancement de
toute la chaine de tests, etc...

Je pense que ce langage a beaucoup d'avenir, car il rempli bien les
condition définies par Richard P. Gabriel ( Models of Software Acceptance )
http://www.dreamsongs.com/Files/AcceptanceModels.pdf  (relire cette
présentation, c'est fabuleux !!) :
- Langage accessible sans nécessiter trop d'abstractions
- Gurus derrière
- Grosse boite derrière (pas de gambler ruin possible)
- Langage ressemblant à l'existant
- Langage au design relativement simple, cohérent et suffisant pour sa
cible.

Malgré tout cela, Lisaac a :
- Véritablement objet : faut bien voir que pour pas mal de monde, et
particulièrement les fan de C++, ya moins de trucs dans Go. Pas de template,
de features vraiment puissante avec l'objet, pas de type blocks, etc... Ca
va faire des frustrés !
- Performance : même avec un bon compilo et un langage plus facile à
optimiser, la compil séparée les bloqueras de toutes façon
- GC désactivable : eh oui en lisaac on peut le faire facilement
- COP : je pense que COP est légèrement mieux que CSP : pas à gérer de
channel, par exemple, c'est automatique.
- Compilateur intransigeant : c'est un point fondamental, je le répète : le
type qui code sur de l'embarqué saura qu'il aura beaucoup moins d'erreurs
potentielles une fois que le compilateur dit que tout est nickel. Et comme
Nicolas l'a souvent dit : qu'en t'as 64ko de mémoire, t'as pas la place de
mettre un debugger.
- Des features véritablement haut niveau, qui sont en train d'arriver dans
le langage
- L'introspection, le soupçon d'aspect avec les contrats qui permettront de
faire des frameworks très très poussés (frameworks web orienté règles,
etc...)
- Les templates automatique, ce qui va exploser la barraque niveau perfs.

J'en parlerai plus précisément plus tard, mais notre plus value c'est :
"développez vite avec les meilleurs perfs possible". Et qu'est-ce qui est
entrain de se passer aujourd'hui ?
Les smartphones ! Ils s'imposent partout... Dans quelques années ils vont
commencer à concuurencer les portable classiques : on aura qu'à leur
connecter un clavier, voire un écran plus grand, et ils feront office de
machine de bureau. Cela voudra dire - sans compter le changement de
mentalité vers l'écologie et donc la meilleur efficacité écologique
(d'ailleurs les américains qui étaient en retard sur nous il y a 10 ans,
vont nous devancer) - que les logiciels capable de proposer les mêmes
service en consommant moins (parce que le code sera plus efficace),
deviendront très intéressant.
Pareil pour le sjeux, vous imaginer UT2003 en Go ?
Hum... On peut facilement les battre en terme de perfs.

Bref, ne nous décourageons pas, on ne vise pas exactement la même cible, et
on a des gros atouts, il va falloir s'atteler à les implémenter proprement,
et à bien faire monter la sauce autour (ça c'est mon boulot).

Le 12 novembre 2009 14:02, Nicolas Boulay <nicolas.boulay at gmail.com> a écrit
:

> Tu as vu leur système de type ? Cela ressemble tellement au type match ! :)
>
> Nicolas
>
> Le 12 novembre 2009 13:43, Xavier Oswald <xoswald at gmail.com> a écrit :
> > On 12:46 Thu 12 Nov     , Nicolas Boulay wrote:
> >> Je pense tout de même que Lisaac va beaucoup plus loin. Mais disont
> >> que Go va suffisamment loin pour rendre Lisaac moins intéressant.
> >>
> >> Il faut dire qu'il annonce des perfs inférieurs à C de 20%.
> >
> > Ouais ca d'accord.. Mais ca ce programme mieu que du C, de plus il y a
> > l'aspect low et high level. Gestion de la mémoire par un GC mark & sweep.
> > Et ils ont deja pas mal de lib réseaux et autres + un modèle à eux pour
> la
> > concurrence qui est plus simple que les threads + un modèlede compilation
> ultra
> > speed ( c'est vraiment impressionnant la vitesse, mais c'est normal vu
> leurs
> > méthodes.) et il ne faut pas oublier qu'ils ne sont pas en compilation
> globale.
> >
> > Comme il y a google derriere, je pense que ca va aller loin cette
> histoire.
> >
> > @Benoit: Tu veux pas aller bosser sur Lisaac chez google ?? ;) (joke or
> not ? :)
> >
> > Greetings,
> > --
> >  ,''`.| ====== Xavier Oswald  ====== | mail: xoswald at debian.org
> |
> > : :' :| Engineer at CALDERA GRAPHICS | http://www.caldera.eu
>  |
> > `. `' | GNU/LINUX Debian Developer   | http://debian.org
>  |
> >  `-  | Isaac Project Developer      | http://isaacproject.u-strasbg.fr |
> >
> > _______________________________________________
> > Lisaac-devel mailing list
> > Lisaac-devel at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/lisaac-devel
> >
>
> _______________________________________________
> Lisaac-devel mailing list
> Lisaac-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/lisaac-devel
>

-- 
---------------------
Isaac Project - http://isaacproject.u-strasbg.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20091112/103af241/attachment-0001.htm>