Je répond juste à cette question directe pour clarifier : (oui, j’ai du mal à tenir mes propres don’t feed the troll ;))
Je conçois la nécessité d’un outil de compilation pour un langage compilé. Mais je veux qu’il reste simple : si, au nom de la gestion des dépendances, de l’intégration continue, ou que sais-je encore, je me retrouve avec une usine à gaz comme maven, je passe.
Avant l’outil go, les makefile en gros c’était
TARGET=test
GOFILES=test.go foo.go bar.go
Note : test.go peut très bien utiliser des libs, j’ai rien à déclarer dans le makefile, c’est juste que c’est de ma responsabilité de les installer avant de compiler.
C’est ça que je cherche. La suggestion de CrEv s’en rapproche pas mal, mais il y a toujours une gestion des dépendances. Je crains que cette gestion soit inévitable en Java, et c’est ça que j’appelle « lourdeur de l’écosystème Java » : une mini-distribution dans ma distribution.
[^] # Re: Intérêt
Posté par Moonz . En réponse à la dépêche Sortie d'une première version stable de Go. Évalué à 0.
Je répond juste à cette question directe pour clarifier : (oui, j’ai du mal à tenir mes propres don’t feed the troll ;))
Je conçois la nécessité d’un outil de compilation pour un langage compilé. Mais je veux qu’il reste simple : si, au nom de la gestion des dépendances, de l’intégration continue, ou que sais-je encore, je me retrouve avec une usine à gaz comme maven, je passe.
Avant l’outil
go, les makefile en gros c’étaitNote : test.go peut très bien utiliser des libs, j’ai rien à déclarer dans le makefile, c’est juste que c’est de ma responsabilité de les installer avant de compiler.
C’est ça que je cherche. La suggestion de CrEv s’en rapproche pas mal, mais il y a toujours une gestion des dépendances. Je crains que cette gestion soit inévitable en Java, et c’est ça que j’appelle « lourdeur de l’écosystème Java » : une mini-distribution dans ma distribution.