langage Go de google

[Pierre-Alexandre Voye]

Interesting comments from forums, talking about what google think about
python :
"Well, simple common sense is going to limit Python's applicability when
operating at Google's scale: it's not as fast as Java or C++, threading
sucks, memory usage is higher, etc. One of the design constraints we face
when designing any new system is, what happens when the load goes up by 10x
or 100x? What happens if the whole planet thinks your new service is
awesome? Any technology that makes satisfying that constraint harder -- and
I think Python falls into this category -- *should* be discouraged if it
doesn't have a very strong case made in its favor on other merits. "

We could compete !

Le 12 novembre 2009 15:14, Pierre-Alexandre Voye <ontologiae at gmail.com> a
écrit :

> 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/
>



-- 
---------------------
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/bf9521c4/attachment-0001.htm>