re: Long post

@uriel

E in questo caso sarebbe una cosa buona, almeno le macchine non sparerebbero cazzate!

@uriel

Oh, loro sono fissati con i processi "automatizzati".

Solo che non prevedono flessibilita' alcuna. Esiste una via, una sola e se anche osi pensare di deviare (magari per un motivo valido), tu sarai punito.

Per capirci: stiamo preparando la migrazione ad un nuovo OS del nostro software. Cosa banale in se': ci sono dei playbook ansible da adattare e generalizzare, delle CI/CD da espandere, pacchetti nuovi da creare, software da verificare, cose cosi'. Nulla di stratosferico.

Bene.

Il loro merdosissimo e ultra rigido processo di rilascio dal nome pomposissimo, ci obbliga a fare temporaneamente revert dell'automazione, perche' se tu osi creare un pacchetto per un altro OS, questo deve essere installato per forza, pena il non andare in produzione. Non puoi, che so, marcare qualcosa come eccezione, o buttarlo via, o cose del genere, no.

fucking seriously???

Io subito pensavo che il mio collega mi prendesse per il culo e dicesse cazzate, invece aveva fottutamente ragione. Ero pronto ad insultarlo, poveretto.

@uriel

Ah no, ti diranno: "Dobbiamo riscrivere in Rust, questo risolvera' i bug!".

Scusa, questa era troppo ovvia :P

@uriel

Si lamenteranno, come al solito e magicamente non sbragheranno piu' di essere "engineers", forse?

"Ma come, che significa che ora ho delle responsabilita'?"

@uriel

Una breadboard, un ATMega 8-bit, due fili sulla seriale e il manuale degli op codes.

Questo gli si deve dare, prima che possano parlare!

Odio anch'io i Gen-Z che "non serve studiare, internet sa tutto". Sono la condanna a morte del nostro settore.

@uriel

Ma neanche in quel caso, se parliamo specificamente di Go (o Erlang).

Ammenoche' le cose non siano cambiate, un programma Go partira' con un numero di thread uguale al numero di cores di default. Se la tua ipotetica CPU avesse un solo core con un solo thread e tu avessi, che so, 100 goroutines in parallelo (magari tests, come nel tuo caso), a livello di runtime Go schedulerebbe l'esecuzione delle funzioni delle varie goroutine sull'unico thread con il quale il runtime partirebbe. Il programma sarebbe logicamente concorrente, ma non lo sarebbe l'esecuzione.

Per questo stanno dicendo boiate ancora piu' grosse di quello che credi anche tu. Non possono in nessun modo ingolfarti alcunche' in Go, solo per il fatto di creare molte goroutine, non e' possibile per come il runtime funziona.

Digli che sono dei cazzari completi, e che leggano qualche manuale.

@uriel

Oh signur......

"ingolfano la CPU" anche non ha senso. Se lanci piu' test in parallelo quello che succedera', e' che Go su una CPU schedulera' un test alla volta.... E io non sono un programmatore Go espertissimo.

Almeno sapere come funziona di base il runtime di quello che stai usando, non mi pare chiedere molto.

@uriel

Si torna sempre indietro, alla fine :D

@uriel

E????? Scrivi i post a mano, ora? :D

@stefano

Oh c'mon, fuck it.

I live in Switzerland and you may understand what does that mean, chocolate-wise.

Moderation always win!

@uriel

E' un'implementazione puramente in Erlang di Lua. Gira come codice nativo BEAM. Non ha dipendenze esterne.

Lo fai girare in una BEAM come app Erlang, gli dai in pasto stringhe o file contenenti codice LUA e lui li interpreta senza problemi, restituendoti un risultato.

@uriel @la_mosca_2

Uhuh....

"Poi mi tengo Kubernetes"......

Stavo contando i giorni che sarebbe durato.