vikkio

ah ok purtroppo (o per fortuna) no, ricordo che era su telemontecarlo forse ma non ricordo di averlo mai visto forse ero troppo piccolo. sono classe 88

sono out of the loop o non capisco proprio il senso di questa immagine? chiedo venia 😅

il titolo è un po’ troppo clickbaity

carbonara ❤️

ahahah è verissimo, telefonatissimo, ma intendo nel mondo del libro lo presentano come un mistero da risolvere, invece pare quasi ovvio. poi non so se mi ricordo benissimo l’ho letto anni fa.

io ho finito il primo a fatica proprio per via dell’orribile modo nel quale sono stati scritti i personaggi. e certi aspetti strani, quasi incomprensibili della storia, tipo perché fare un videogioco che nasconde la verità? mi è sembrata quasi una stupidata da bambini. chiunque con un cervello e internet sarebbe arrivato a capire cosa “nascondesse” il videogioco o di cosa si parlasse. appena ho finito di leggerlo mi sono sentito libero e mi sono costretto ad evitare di caderci di nuovo.

😍 grazie @alephoto85@feddit.it , per chi fosse interessato c’è anche un piccolo followup con codici esempio per un side project qua

io cambierei se fossi in te. spendiamo un sacco di tempo della nostra vita a lavoro ed è un incubo lavorare in un posto del genere.

io ho lavorato a livello enterprise con entrambi e Go è quello più facile da mantenere e scrivere. La produttività dei team che adottano go è insuperabile.

questa storia della memoria e di quanto sia importante la trovo spesso un po’ forzata. Dipende spesso anche da come scrivi i programmi e usare solo script con soluzioni a problemi matematici non è mai lo stesso di applicazioni reali nel mondo reale, sono solo approssimazioni. Le GCSpikes che la gente attribuisce ai webserver scritto in Go sono raramente un problema se hai usato i giusti paradigmi/design per risolvere il problema.

Una cosa che invece ho trovato con Go a livello enterprise, invece di Rust, è che è più facile fare onboarding da altri linguaggi e che se anche non tocchi una codebase per mesi ritornarci è semplice.

EDIT: aggiungo un memino come TLDR

finiti tutti in due sessioni separate a due anni di distanza. Sono utili per acquisire familiarità ma lavorare a piccoli progetti con difficoltà incrementale, imho, è un approccio migliore per capire le potenzialità di un linguaggio.

a parte quelli ho lavorato tantissimo agli exercism

il risolvere problemi e vedere un progetto che avevi su una nota diventare un prodotto funzionante e utile, prima di tutto, per te stesso.

non mi pare graphql puro, è una bastardata tra soap e graphql.

esattamente quello che intendevo. Ogni linguaggio ha i suoi perchè e i suoi gotcha. Che poi perl è in disuso da decenni, ha anche lui i suoi perchè, come fortran e cobol, vecchie architetture specialmente in Banking/Finance hanno sistemi scritti decenni fa in linguaggi arcaici che nessuno vuole cambiare.

ahaha a parte gli scherzi, ho cominciato con php e ci ho lavorato fino ad un paio di anni fa. uno dei migliori per fare web api

i fanboy, ogni linguaggio di programmazione ha un suo perchè ed è solo uno strumento che serve a risolvere un problema.

Nessun linguaggio è in generale migliore di un altro, dipende solo da quello che ci devi fare.