Go ou C?

Programmation
#1

Bonjour programmeurs debianneux (ou pas).

Alors voilà, j’aimerais passer à autre chose que python. Parce que python c’est bien, mais il y a tellement de bibliothèque que s’y retrouver entre toutes leurs versions…
Et puis j’aimerais bien me mettre à du compilé pour gagner en vitesse… et pour apprendre.

Ces derniers temps, il y a un énorme enthousiasme pour Go sur le net. Et puis Rob Pike, c’est pas un mickey quand même. La syntaxe n’a pas l’air trop compliquée. Bref, qu’est-ce que vous en pensez? Croyez-vous que le go a une aussi bonne perspective d’avenir que le C qui reste une référence?

Tout ça pour savoir si ça vaut le coup d’apprendre le go.

À vos avis !

:006

#2

Clairement pas. Le C est indétrônable et Go ne seras probablement jamais autant utilisé que Le langage de programmation référence.

Mais ça ne dis pas que Go est pas bien juste qu’en terme de perspective rien est à mon avis comparable au C.

Go est pas mal pour y avoir un peu touché c’est amusant et ça se prend plus facilement en main qu’on ne le crois (j’ai pas touché au go-routine et au deferer). Pour faire ton choix entre les deux c’est assez simple :

Tu cherche un langage relativement bas niveau où tu gère ta mémoire (tu l’alloue et la libère toi même), avec des milliards de bibliothèques et une syntaxe simple, tu prend le C.

Tu cherche a avoir un langage moderne, qui gère la mémoire de manière automatique, tu n’a pas besoin de centaines de bibliothèque, tu prend Go.

#3

Merci pour ce premier retour, qui me conforte dans mon idée.
Le C j’avais bien aimé, mais je métais vite retrouvé perdu lorsqu’il s’agissait de compiler à la main (sans IDE). Gcc est un apprentissage suppélentaire que je n’ai pas pris le temps de faire.

#4

Tu as un fichier main.c unique (pour les débuts). Tu lance dans le même répertoire :

et c’est terminé (sans avoir écris de makefile).

Ensuite quand tu as plusieurs fichiers il faut un makefile.

[code]SRC=$(wildcard *.c)
OBJ=${SRC:.c=.o}
NAME=monprogramme

$(NAME): ${OBJ}

.c.o:

A.o: <dépendances de A>

B.o: <dépendances de B>
[/code]

Pour déterminer les dépendances de A :

Rien de plus, si tu veut ajouter des bibliothèques il faut simplement créer les variables CFLAGS et LDFLAGS.

#5

C’était au départ lors de l’ajout des bibliothèques, il fallait si je me souviens bien rajouter -F SDL/SDL.h par exemple, et au bout d’un moment je m’y perdais un peu, et par manque de temps j’ai laché.

Je garde sous le coude tes conseils avec make, ça sera en effet plus pratique (surtout avec vim). Merci :wink:

Au passage, make ou mk?

#6

Je ne connais pas mk. Mais si tu veux un peu te renseigner sur les builders libres voici un lien intéressant : linuxfr.org/news/petit-%C3%A9ve … der-libres
(les commentaires le sont autant que la dépêche)

Edit: J’ai la mémoire courte (et j’utilise peu make ces derniers temps). Il y a un super cas d’usage ici : linuxfr.org/news/petit-%C3%A9ve … nt-1267386 qui montre comment automatiser encore un peu plus le makefile (même si je pense que le second appel à gcc et l’appel à ld sont inutiles).

#7

encore un grand merci! :text-thankyouyellow:

#8

Mais make gère bien toute les options ?

[code]tt@debian-tt:~/Bureau$ cat sqrt.c
#include <stdio.h>
#include <math.h>

/* */

main() {
double x;
printf (“Saisir une valeur: " );
scanf (”%le",&x);
printf (“La racine carree vaut: %le \n”, sqrt(x) );
}

tt@debian-tt:~/Bureau$ make sqrt
cc sqrt.c -o sqrt
/tmp/ccFFLF0x.o: In function main': sqrt.c:(.text+0x31): undefined reference tosqrt’
collect2: error: ld returned 1 exit status
make: *** [sqrt] Erreur 1
tt@debian-tt:~/Bureau$ rm sqrt
tt@debian-tt:~/Bureau$ make -lm sqrt
cc sqrt.c -o sqrt
/tmp/ccos9Hdr.o: In function main': sqrt.c:(.text+0x31): undefined reference tosqrt’
collect2: error: ld returned 1 exit status
make: *** [sqrt] Erreur 1
[/code]

tt@debian-tt:~/Bureau$ gcc sqrt.c -lm -o sqrt fonctionne bien lui (l’option -lm trouvé grâce au manuel)

#9

C’est surtout qu’il faut pas s’en servir comme ça. Tente avec :

$ export LDFLAGS=-lm
$ make sqrt
#10

:023 :023 merci

Je viens de débuter en C et j’ai jamais utiliser make mais ton exemple avec l’appel a d’éventuelle fonctions auxiliaire m’a séduit

Et un man make n’apporter pas la réponse que tu viens de m’apporter

En tout cas merci je vais un peu réfléchir à tout ceci

Je comprends mieu ton explication :

#11

Make est à priori générique, il faut juste remplir un Makefile comme il faut pour qu’il demande à gcc de faire ce qu’il faut…
C’est un truc en plus à apprendre. Va falloir mettre dans un coin toutes les idées pour s’en souvenir!

#12

Bonjour,

Cette question est très intéressante.

Je pratique le C depuis 12 ans (ainsi que le PHP, le Perl, le Ruby et le Java).

Récemment, j’ai développé un client STUN en GO, pour me former sur ce langage : https://github.com/denis-beurive/GoStun

D’un point de vue technique, je conseille sans réserve le GO. Ce langage est très bien conçu. Pour développer des applications système et réseau, c’est une excellente solution. Vraiment, j’apprécie énormément la qualité de cet outil.

D’un point de vue professionnel, le C reste une valeur sûre.

Quel est ton objectif ?

Si tu recherches un travail en France, tu dois t’orienter vers le C.

Si tu souhaites développer, à titre personnel, un logiciel axé sur le réseau ou le système, je te conseille le GO. Tu avanceras beaucoup plus vite. Tu éviteras un bon nombre de risques liés au C (fuites de mémoire, problèmes d’alignement, gestion du type d’architecture, problèmes avec les threads…). Franchement, si demain, je dois lancer un projet Open Source lié au réseau ou au système, je choisis le GO, sans hésiter.

Si tu es un développeur aguerri (> 10 ans d’expérience) et que tu désires investir sur une technologie à fort potentiel, je te conseille le GO. Si cette technologie perce en France, alors tu pourras te vendre cher (en étant dans les premiers). C’est un choix stratégique à moyen terme (2-3 ans). C’est aussi un risque, car GO peut ne pas percer en France…

Cordialement,

Denis

#13

J’entend de plus en plus parler de Go. Et le truc qui me dérange c’est que c’est issu des labo de Google. Alors oui il font de bon produit / service et tout mais je suis quand même googleseptique …
Ruy (et ROR) m’avait l’air des plus intéressante, mais très orienté web, alors que Go m’a l’air plus générique.

Du coup je commence a avoir des doutes sur mon opinion et je me dit qu’il va falloir que je regarde ça de plus près … a voir

#14

@Mimoza,

Go et Ruby sont forts différents.

[ul][li]Ruby est un langage interprété hyper moderne. Ruby est un excellent langage. Il rassemble le meilleur de Perl et de Python… et il explose PHP. Pour moi, c’est le meilleur langage interprété.[/li]
[li]Go est un langage compilé. Et, forcément, il n’est pas aussi souple et sophistiqué que Ruby. Un langage compilé ne sera jamais aussi souple, élégant et raffiné qu’un langage interprété.[/li][/ul]

Google a fait de l’excellent travail. J’ai testé, et je confirme : un programme écrit en GO compile sans problème sur Linux, Mac et Windows.

[ul][li]La gestion du parallélisme est super.[/li]
[li]La bibliothèque réseau est très bien faite.[/li]
[li]Google a intégré des outils vraiment très pratiques (ex : gestion BigEndian/LittleEndian).[/li]
[li]La grammaire est pensée pour la validation.[/li]
[li]L’écosystème de compilation est très simple, élégant et puissant.[/li][/ul]

De mon point de vue, GO est le meilleur langage compilé actuel.

Ruby et GO ne sont pas comparables. Mais, tous les deux, dans leur catégorie, sont les meilleurs.

A+

#15

Discussion intéressante, bien que je n’apporterai rien, je réponds pour suivre visuellement le fil.

#16

Ne dis jamais ça sur la liste de diffusion de suckless.org, au risque de te faire lyncher :laughing:

#17

@denis.beurive : Merci de cette comparaison expresse. Finalement j’ai l’impression qu’il est intéressante d’apprendre les 2.

#18

RoR est très orienté web oui (ah ! ah !), mais ruby non. Go est orienté système et réseau.
Pour ruby comme pour go ça ne viens pas du langage mais de leur écosystème (les bibliothèques et framework).

Ouh, de manière complètement formelle quand une phrase contient « rassemble le meilleur de », je suis toujours sceptique. Pour ruby je l’aime vraiment bien, il possède un tas de choses vraiment appréciables et une grande expressivité (voir les différentes manière de faire des boucles), mais il n’en est pas moins que Perl et Python gardent des avantages indéniables.

Pour perl, il y par exemple a la gestion des expressions régulière et une expressivité parfois plus grande qu’en ruby (voir given when). Il a un paquet de problèmes, mais il seront résolu en Perl6, qui à mon humble avis sera mon langage de script préféré à moyen terme.

Pour python, il y a son écosystème (la palanquée de bibliothèque notamment dans le domaine du calcul numérique), sa simplicité (c’est le java des langages de script (ce n’est pas une insulte de ma part, il cherche à être explicite et tente de garder une seule façon de faire chaque chose)) et son mode de gouvernance.

Pour les inconvénients de ruby, je crois qu’il va falloir attendre la version 2.0 (qui sort bientôt ou viens tout juste de sortir) pour avoir des performances au niveau de ces concurrents (notamment la gestion de la mémoire). Ruby vente la propreté de son langage mais je ne suis pas totalement convaincu. Il suffit pour cela de regarder les fausses constantes stackoverflow.com/questions/1977 … stant-mean (à noter que ni perl, ni python n’ont de constantes, mais je préfère ne pas avoir de constantes plutôt que d’en avoir de fausse).

En ce qui concerne PHP, je pense que ce langage est une erreur donc inutile d’en parler.

Par souple je pense que tu parle de dynamique par contre pour l’élégance et le raffinement je ne suis pas sur de savoir de quoi tu parle. Mais les langages fonctionnels tel que OCaml et Haskel sont sacrément élégants.

#19

Ouh! Que conseillerais alors pour la conception d’un site web dynamique??

#20

[quote=“denis.beurive”][*]L’écosystème de compilation est très simple, élégant et puissant.
[/quote]

J’aime beaucoup cette phrase!! Bien que je ne sache pas vraiment ce que cela veut dire…