NSA - Non Solo Amiga
SOFTWARE => Linguaggi di programmazione e scripting => Topic aperto da: legacy - 18 Maggio 2013, 15:37:09
-
dead
-
Un nuovo linguaggio?
Com'è? Qualcuno ci ha messo le mani?
-
è un linguaggio sviluppato da Google con la supervisione di alcuni luminari informatici tra cui Ken Thompson (co-inventore di Unix) e Rob Pike (altro grande luminare di Unix e di Plan 9).
Lo usano per sviluppare parecchia della loro roba web, anche se non so di preciso quali applicativi Google sono basati si Go Lang, quali su Python e quali su Java.
-
Gcc pare supportarlo, boh, e' da provare.
generalmente diffido dei linguaggi troppo giovani perchè c'è poco supporto e il suo futuro è ancora da disegnare. Però sulla carta è un ottimo linguaggio, simile a Pascal ma con la sintassi del C
-
per quanto possa capirci io mi sembra molto interessante... :D
-
C’è posto per Google Go? Prime impressioni sul nuovo linguaggio di BigG (http://www.appuntidigitali.it/4998/ce-posto-per-google-go-prime-impressioni-sul-nuovo-linguaggio-di-bigg/) ::)
-
C’è posto per Google Go? Prime impressioni sul nuovo linguaggio di BigG (http://www.appuntidigitali.it/4998/ce-posto-per-google-go-prime-impressioni-sul-nuovo-linguaggio-di-bigg/) ::)
Grande compare!
Al solito mi son letto tutto (pure i commenti) e ne ho compreso forse un decimo (Rambo direbbe: "ci sono abituato") ma mi ha fatto un gran piacere quel decimo.
Quindi siamo ancora un po' sull'acerbetto eh? ;)
Dietro c'è Google, si vedranno evoluzioni. ;D
-
Sono passati 3 anni e mezzo dall'articolo, per cui penso che qualcosa sia cambiato. Go viene usato internamente da Google, che lo propone, sebbene in versione sperimentale, anche sul suo Google App Engine.
-
chissa' come si comporta e se ha vantaggi per l'embedded
e' da provare
è pensato per i web service. Fossi in te non ci perderei tempo per l'embedded.
-
si, ok, ma si presenta come + robbusto, dato che ADA e' un casino da supportare e che il C e' pieno di trapple ed insidie, ... why not ?
gira che ti rigira non ci si schioda dal C, non c'e' mai nulla da fare.
C'è sempre il C++: ignorando RTTI, eccezioni e funzioni virtuali ti viene un linguaggio migliore del C ma con le stesse prestazioni. :D
-
che pero' permette ancora di fare porcate e che come core gcc-c++ e' un casino da compilare
go lang ha un core molto piu' snello e permette molte meno porcate
poi, scrivere la maestrina per il C++ ...... io non ci riesco, e' troppo complesso
per go lang non c'e' bisogno di scrivere la maestrina
e anche questo è vero :)
-
che pero' permette ancora di fare porcate e che come core gcc-c++ e' un casino da compilare
go lang ha un core molto piu' snello e permette molte meno porcate
Dipende da cosa intendi per porcate. :P
Il mio ragionamento era che è più probabile che una piattaforma abbia un compilatore C++ che Go (ovviamente tralasciando C che è onnipresente).
E' un peccato che LLVM non abbia ancora backend per architetture di microcontrollori o altri embedded, perchè sarebbe figosissimo e si potrebbe usare qualsiasi linguaggio che ha un compilatore che si appoggia su LLVM (come C/C++/ObjectiveC con Clang).
-
Il mio ragionamento era che è più probabile che una piattaforma abbia un compilatore C++ che Go (ovviamente tralasciando C che è onnipresente).
Molto probabile, al momento al di fuori di piattaforme desktop/server non credo si trovi Go da nessuna parte.
E' un peccato che LLVM non abbia ancora backend per architetture di microcontrollori o altri embedded, perchè sarebbe figosissimo e si potrebbe usare qualsiasi linguaggio che ha un compilatore che si appoggia su LLVM (come C/C++/ObjectiveC con Clang).
Ne ha qualcuno, c'è un backend per il TI msp430 ad esempio. C'è comunque un problema ad utilizzare linguaggi diversi dal C con LLVM, se è richiesto un runtime complesso (come nel caso di C++) bisogna molto probabilmente scrivere a manina le funzioni di supporto per il runtime (la parte per la gestione delle eccezioni/stack unwinding/etc., bisognerebbe in sostanza estendere anche compiler-rt/libc++abi per offrire pieno supporto al C++). Notare che alcune cose si possono tagliare, ma ad esempio non si può compilare libc++ senza supporto RTTI, mentre si può linkare ad un programma senza RTTI.
-
"No generics, no overloading, and no adding methods to existing types. How....useful."
ROFL. Il titolo è già tutto un programma. ;D
-
Infatti c'è da spaccarsi :-)
Dopo la prima pagina (ne sono 5) ho abbandonato. Anche se devo ammettere, un bel flame ;)
-
Ne ha qualcuno, c'è un backend per il TI msp430 ad esempio. C'è comunque un problema ad utilizzare linguaggi diversi dal C con LLVM, se è richiesto un runtime complesso (come nel caso di C++) bisogna molto probabilmente scrivere a manina le funzioni di supporto per il runtime (la parte per la gestione delle eccezioni/stack unwinding/etc., bisognerebbe in sostanza estendere anche compiler-rt/libc++abi per offrire pieno supporto al C++).
Per la prima parte, si può compilare il programma disabilitando eccezioni e RTTI, e ciò fa risparmiare memoria (le prestazioni rimangono essenzialmente le stesse); nel secondo caso, compiler-rt almeno provvede funzioni di fallback per i target che non supportano soluzioni custom, quindi almeno il programma potrà essere compilato e eseguito.
Notare che alcune cose si possono tagliare, ma ad esempio non si può compilare libc++ senza supporto RTTI, mentre si può linkare ad un programma senza RTTI.
Se l'ambito che si propone è l'embedded, si potrebbe avere una libreria standard c++ ottimizzata per questo ambito (tipo MHVLib (http://www.makehackvoid.com/project/MHVLib)) che non ha dipendenze sulle eccezioni e su RTTI, in modo che il compilatore non debba generare codice per queste ultime. Inoltre non credo che nessun programmatore possa lamentarsi se in un micro a 8 bit non può avere la STL. :P
Ormai i compilatori e linker moderni hanno capacità di ottimizzazione veramente aggressive, e credo riescano tranquillamente a rimuovere il codice per le eccezioni e RTTI anche se non espressamente richiesto se vedono che in nessun punto del codice ciò è usato.