Linguaggio consigliato per i futuri strumenti

[lucat1]

So che è un topic controverso e non voglio che vediate la discussione come il dittatore che impone la sua decisione. Sappiate dunque che sono aperto alle alternative e possiamo discuterne. Prima vi do dei buoni motivi per cui avere un linguaggio consigliato, per alcune parti del software che scriviamo, sarebbe importante:

1. Facilita l'interoperabilità. Ad esempio, attualmente l'idea è di creare una libreria condivisa per il controllo dei nomi dei file da usare in:

   • CI su github
   • rename automatico con un cli nostro
   • controllo dei nomi nel nuovo sistema di caricamento degli appunti
   • controllo dei nomi quando si caricano appunti dal bot telegram

   Sono tutte applicazioni che potrebbero essere scritte in linguaggi diversi, l'interoperabilità potrebbe essere molto difficile (c-go) o quasi impossibile senza hack strane (rust, necessiterebbe di scrivere assembly).
   Usare un unico linguaggio per queste componenti critiche ci semplificherebbe moltissimo la vita.

2. Chi contirbuisce a csunibo deve conoscere un linguaggio e con questa conoscenza può contribuire a quasi tutto.

Ora vi spiego perchè il mio linguaggio consigliato sarebbe go, e quali vantaggi ha rispetto alle altre opzioni:

1. Facile: sintassi semplice, vicina a python lo rende molto leggibile. Non c'è gestione della memoria come in tutti i linguaggi interpretati.
2. Buone performance: essendo compilato, batte nettamente python e js nei benchmark. Anche se non in tutto quello che facciamo sono vitali le performance, aspettare meno tempo per il CI, avere il bot di telegram veloce e i futuri applicativi web reattivi sarà sicuramente un bonus. Inoltre, visto che andremo ad hostare noi stessi parte di questi software (come già avviene per il bot di telegram) sarà importante guardare anche all'utilizzo delle risorse.
3. Il punto più importante assieme all'1: mantenibilità: è un linguaggio fortemente tipato, con un type system semplice, non serve impararsi concetti strani cone trait ne inheritance. Ha un sistema di tipi estremamente semplice, come C, ma ha più garanzie rispetto a quello che avevamo nel '70. Impone dunque, a mio avvio, il giusto livello di rigore senza constringere nessuno a imparare concetti nuovi. Tutto quello che serve per capire go viene spiegato nel corso di programmazione del primo anno.
4. Funziona bene per le nostre necessità: i suoi punti di forza sono applicazione command line e interazioni web: noi scriviamo software command line (controlli per il CI, auto renamer), o software web (bot telegram, servizio di creazione PR facilitato, scraper automatici per contenuti).

I motivi per cui ho scarato altre popolari opzioni, come python. js, rust, c, spero siano chiari da quello che ho scritto sopra. Go non è ne il mio linguaggio preferito ne il mio secondo linguaggio preferito (potrebbe essere il terzo ;)). È a mio avviso il linguaggio giusto per il lavoro, e mi sentirei di consigliarlo come organizzazione, per i progetti futuri, in modo che sia tutto coeso e facilmente interoperabile.

[VaiTon]

Nonostante in generale:

• Non sia d'accordo con il "un linguaggio per tutto"
• Non mi piaccia particolarmente
  • la sintassi di Go
  • il miscuglio che fa tra concetti di alto livello e concetti di basso livello (vedi pointers e channels)
  • il fatto che sia GC nonostante non offra una grande astrazione
  • la gestione degli errori via return di tuple
  • il modo in cui sono sviluppati i canali (lo switch sui canali mi fa rabbrividire sinceramente)

capisco che magari sia necessario utilizzare un linguaggio GC e con una libreria standard estremamente estesa come Go.

In generale, non per togliere qualcosa, non penso che scegliere un linguaggio senza un obiettivo abbia un senso. Proporrei quindi di almeno considerare vari punti e vari "template".

Ad esempio, potremmo considerare Go, e in seconda battuta Rust per le CLI e il "backend". SvelteKit e in seconda battuta React per il frontend.

[lucat1]

Non avevo nessuna intenzione di usare Go sul frontend, tranquillo.
L'obbiettivo per cui sarebbe usato Go o qualunque altra cosa scegliamo è scrivere backend del servizio che crea le PR, CI e tool command line per il controllo dei nomi del file che attualmente è quello che ci serve. Il frontend per caricare gli appunti sarebbe sempre in svelte integrato dentro dynamik ovviamente. Non voglio rifare del lavoro che va perfettamente bene così com'è.
Essendo un consiglio l'idea è sempre che lo si può ingorare con motivi validi, e non andrei a riscrivere qualcosa che va bene così com'è solo per "uniformare".

Se fosse per me, userei Rust, che preferisco a Go, però voglio priotizzare la mantenibilità e la facilità di contribuire per chi non conosce il linguaggio come ho detto prima. Secondo me Go ha una learning curve molto bassa ed è leggibile come python, anche se ha una buona performance. Per quello che dobbiamo fare mi pare giusto, ma penserei anche ad altro se hai idee.

[foxyseta]

Non sia d'accordo con il "un linguaggio per tutto"

Forse dal messaggio originale non traspare che non sia un "linguaggio per tutto", bensì un linguaggio per le sole componenti del backend di csunibo (che sono più di una). Bot, web scraper, front-end, CLI, etc. etc. sono scelte indipendenti.

non penso che scegliere un linguaggio senza un obiettivo abbia un senso.

Quindi è un linguaggio scelto con lo specifico obiettivo di sviluppare uno particolare tipo di componenti (quelle che formano il back end).

[VaiTon]

Essendo un consiglio l'idea è sempre che lo si può ingorare con motivi validi, e non andrei a riscrivere qualcosa che va bene così com'è solo per "uniformare".

Va bene allora, se si esprime in questo modo sono d'accordo anche io

[konova8]

Mi sono appena inserito nel progetto, ma avere un linguaggio bene o male "unico" mi darebbe la possibilità di contribuire più facilmente.

Con questo non dico che sia d'accordo con una scelta vincolante (non credo sia mai stata così pensata l'idea), anche perché come già proposto se venisse diviso per settori sarebbe meglio. Ma l'idea in sé secondo me ripagherebbe a lungo andare.

Soprattutto se venisse scelto un linguaggio come Go, che per quanto non sia il massimo è estremamente semplice ma l'ecosistema che c'è intorno è molto maturo da quel che so.

[foxyseta]

Sappiatemi dire se e quando una decisione e'presa perche' csurename fa parte degli strumenti che servono anche al backend e al momento scritto in rust e' difficilmente integrabile con il resto (quindi se so che c'e' un linguaggio backend lo riscrivo in quello).

[foxyseta]

(Alla fine è stato scelto Go per le componenti del backend.)