Προγραμματισμός σε Go

[gon1332]

Dont like it.

 

Δεν καταλαβαίνω γιατί φτιαχνεις c like γλώσσα, και παράλληλα τα πιο βασικά πράματα τα αλλαζεις.

 

Όνομα τύπος. Γιατί; Γιατί να τα βάλεις ανάποδα;

Func foo() (string){}. Γιατί πρέπει να υπάρχει το func? Και γιατί ο τύπος επιστροφής να το γραφείς μετά τα agrs.

 

 

Πάλι καλά που δεν έχεις func call κάπως!έτσι. ("Ηελλο ςορλδ")println.ftm

Κι εγώ είχα αυτό το ερώτημα, αλλά το δικαιολογούν κι έχει κάποια λογική αν το σκεφτείς. Όπως και να έχει, έχω συνηθίσει σε C like καταστάσεις.

[παπι]

Θα μπορούσε να έχει c like syntax για τα βασικά, και έπειτα να βάζει features. Οκ κοίταξα το syntax μιας closure. Τι ναπω... Μια nested func.. Και τίποτα άλλο. Δεν μπορούσε να αντιγράψει το lamda της c#?? Δηλαδή στη c# που είναι strong type το closure το γραφείς απλά ως x=> x ενώ στην go που είναι weak type πρέπει να γράψεις nested function με types!!!

[brute-force]

Θα μπορούσε να έχει c like syntax για τα βασικά, και έπειτα να βάζει features. Οκ κοίταξα το syntax μιας closure. Τι ναπω... Μια nested func.. Και τίποτα άλλο. Δεν μπορούσε να αντιγράψει το lamda της c#?? Δηλαδή στη c# που είναι strong type το closure το γραφείς απλά ως x=> x ενώ στην go που είναι weak type πρέπει να γράψεις nested function με types!!!

Δεν υπάρχουν generics στην Go σε επίπεδο χρήστη οπότε οτιδήποτε κάνεις πρέπει να δηλώνεις τύπους. Οι λόγοι έχουν να κάνουν καθαρά με την σχεδίαση της γλώσσας.

 

Όσον αφορά τα closures, τυχαίνει και τα χρησιμοποιώ συχνά χωρίς κανένα παράπονο. Τα πάντα είναι variables oπότε δηλώνεις ένα closure πάνω σε ένα variable και μετά το χρησιμοποιείς όπου θες μέσω του variable.

 

Δεν θέλουν να καταλήξουν με δεύτερη c++ αλλά με αυτή γράφουν. Χαχα

 

Από google από τα project της που ςεχω δει. Μόνο v8, το οποίο θεωρώ αριστούργημα από όλες!τις απόψεις.

 

Το κακό με την google είναι ότι δεν φτιάχνει τα project από το 0. Αλλά αγοράζει startup και μετά ρίχνει χρήμα..

 

Τα feature δεν έχουν σχέση με αυτά που λέω.

Mέσα στη Google δουλεύουν πολλές διαφορετικές ομάδες και χρησιμοποιούν πολλές γλώσσες. Δεν θα τους έβαζα όλους στο ίδιο καζάνι (αυτό της C++) αλλά σίγουρα έχουν πολύ λογισμικό σε C++. Το οποίο δεν είναι παράξενο αν κοιτάξεις ποιές γλώσσες τόσα χρόνια μπορούσαν να την αντικαταστήσουν (καμία). 

 

Αυτό που λες για το ότι δεν ξεκινάει projects από το 0 εννοείται πως δεν ισχύει. Όλες οι μεγάλες εταιρείες κάνουν αγορές start-ups ώστε να μένουν σχετικές αλλά όλες ξεκινάνε και projects από το 0 (πρόσφατα Kubernetes όσον αφορά τη Google - https://github.com/GoogleCloudPlatform/kubernetes)

[brute-force]

Όσοι έχετε ασχοληθεί με MPI στη C, θα θέλατε πολύ να ρίξετε μια ματιά στα κανάλια, τις ρουτίνες, και τη select της Go.

 

[defacer]

Θα μπορούσε να έχει c like syntax για τα βασικά, και έπειτα να βάζει features. Οκ κοίταξα το syntax μιας closure. Τι ναπω... Μια nested func.. Και τίποτα άλλο. Δεν μπορούσε να αντιγράψει το lamda της c#?? Δηλαδή στη c# που είναι strong type το closure το γραφείς απλά ως x=> x ενώ στην go που είναι weak type πρέπει να γράψεις nested function με types!!!

 

Δε γίνεται να τους έχεις όλους ευχαριστημένους. Αν είχε C-like syntax εκεί θα έβγαινε άλλος να πει "καλά είπαν να το βελτιώσουν και τις μεγαλύτερες βλακείες τις αφήσαν ανέγγιχτες". Επίσης με τη λογική "παίρνω το γνωστό και βάζω κι άλλα features" καταλήγεις σε κάτι τερατουργήματα (language-wise) όπως η C++.

 

H go είναι strongly typed και όχι weak όπως γράφεις.

 

Και τέλος το lambda syntax που τόσο μας αρέσει μη ξεχνάς ότι δεν ήρθε παρά μόνο με τη C# 3.0.

[brute-force]

H go είναι strongly typed και όχι weak όπως γράφεις.

Duh, για το type system μιλούσε; Για ένα σημείο νόμιζα πως υπήρχαν weak και strong closures...

 

Strongly typed με type inference το οποίο δίνει ένα αίσθημα πιο scripting γλώσσας, πχ.

id := 1

[defacer]

Ναι, και η C# έτσι είναι. Και μάλιστα το type inference είναι απαραίτητο για μερικά από τα πιο βολικά features που έχει

var list = new[] { 1, 2, 3.14 };
var doubled = list.Select(n => n * 2);

Εδώ έχουν γίνει inferred:

• το τι είδους πίνακα έφτιαξα
• ο static τύπος των list και doubled
• η πλήρης signature της lambda
• το generic type argument της Enumerable.Select

Mάλιστα το inference στη C# είναι πολύ hardcore ώρες ώρες π.χ.

 

class Granny {}
class Mommy : Granny {}
class Baby : Mommy {}

void Inferred(Granny g) { Console.WriteLine("Inferred Granny"); }
void Inferred(Mommy m) { Console.WriteLine("Inferred Mommy"); }
void Inferred(Baby  { Console.WriteLine("Inferred Baby"); }

// play with the types here
Inferred(DateTime.Now.Second >= 30 ? new Baby() : new Mommy());

Επεξ/σία 25 Ιουλίου 2015 από defacer

[brute-force]

Xμμ, i see... Σ'αυτόν τον κώδικα υπάρχουν πράγματα που δεν ισχύουν για την Go:

 

* function overloading

* ternary operations

 

τα οποία σε συνδυασμό με το type inference έχουν τέτοιο "hardcore" αποτέλεσμα. Στην Go τα πάντα έχουν κρατηθεί σε απλό επίπεδο και το inference γίνεται μόνο σε δηλώσεις μεταβλητών **μέσα** σε συνάρτηση ie. παντού εκτός globally.

[defacer]

Το overloading είναι απλά ο ευκολότερος τρόπος για να δεις το αποτέλεσμα του inference, δεν έχει να κάνει με την ουσία της υπόθεσης.

 

Ο ternary είναι το απλούστερο παράδειγμα που μπορούσα να σκεφτώ που δείχνει κάτι πέρα από τα "απλά" του άλλου παραδείγματος.

 

Το spec αφιερώνει 5 σελίδες (!!) στην περιγραφή των περιπτώσεων που γίνεται type inference και των αλγορίθμων που ακολουθούνται.

[brute-force]

Το overloading είναι απλά ο ευκολότερος τρόπος για να δεις το αποτέλεσμα του inference, δεν έχει να κάνει με την ουσία της υπόθεσης.

Κι όμως το πως αλληλεπιδρούν τα features της κάθε γλώσσας μεταξύ τους παίζει μεγάλη σημασία και για όλη την εικόνα της γλώσσας (orthogonality) αλλά και ξεχωριστά για το κάθε feature.

[defacer]

Σύμφωνοι, αλλά και πάλι το overloading εδώ ήταν λεπτομέρεια. 

[παπι]

Δε γίνεται να τους έχεις όλους ευχαριστημένους. Αν είχε C-like syntax εκεί θα έβγαινε άλλος να πει "καλά είπαν να το βελτιώσουν και τις μεγαλύτερες βλακείες τις αφήσαν ανέγγιχτες". Επίσης με τη λογική "παίρνω το γνωστό και βάζω κι άλλα features" καταλήγεις σε κάτι τερατουργήματα (language-wise) όπως η C++.

 

H go είναι strongly typed και όχι weak όπως γράφεις.

 

Και τέλος το lambda syntax που τόσο μας αρέσει μη ξεχνάς ότι δεν ήρθε παρά μόνο με τη C# 3.0.

Δηλαδή αυτό είναι καλύτερο; func name() return type? Από το return type name()

 

Το lambda είναι ο ορισμός του syntax sugar. Και πραγματικά δεν καταλαβαινω γιατί να λείπει από μια νέα γλώσσα με τα χαρακτηριστικά της go πχ.

[brute-force]

Βασικά υπάρχει διαφορά ανάμεσα στα lamdas της C# (και τα lamdas γενικότερα) με τα closures της Go (και τα closures γενικότερα).

 

http://stackoverflow.com/a/220728

[defacer]

Ε κοίτα, "καλύτερο" ή "χειρότερο" με τη μαθηματική έννοια δεν είναι. Το κάθε ένα έχει τα προβλήματά του. Αν ήταν άσπρο/μαύρο δε θα υπήρχαν γλώσσες που το κάνουν είτε με τη μία είτε με την άλλη. Εξάλλου μη ξεχνάς ότι ακόμα και στη c++ πλέον μπορεί να εμφανιστεί το return type "after" σε μια lambda, π.χ.

[]() -> int { return 42; }

αν και βέβαια στο συγκεκριμένο παράδειγμα θα μπορούσε να παραληφθεί επειδή το standard επιτρέπει inference.

 

Στην προκειμένη για να είμαι ειλικρινής νομίζω ότι χώνεις επειδή ζούσες μια ζωή ανάμεσα στους λευκούς και πήγες μια μέρα Αφρική και σε χάλασε. Give it time.

 

Το γιατί να λείπει το syntactic sugar.... επειδή συνήθως είναι sugar και άρα υπάρχουν πολύ σημαντικότερα (ουσιώδη) πράγματα που μπορεί να θέλεις να πάρουν προτεραιότητα.

 

Ξανατονίζω στη C# πήρε πόσα χρόνια παρόλο που μιλάμε ίσως για τη #1 τεχνολογία (πακέτο με .NET) στην οποία ο κολοσσός Microsoft πόνταρε το στρατηγικό της μέλλον. It's sugar. Μπορεί άμα δοκιμάσεις μετά να μην έχει γυρισμό αλλά κανείς δεν πρόκειται στην τελική να αλλάξει πλατφόρμα και γλώσσα επειδή έχει τόσο γαμάτο lambda syntax.

Βασικά υπάρχει διαφορά ανάμεσα στα lamdas της C# (και τα lamdas γενικότερα) με τα closures της Go (και τα closures γενικότερα).

http://stackoverflow.com/a/220728

 

Απλά το παπί είπε στην αρχή closure ενώ ήθελε να πει lambda. Απο κει και πέρα σε όλη τη συζήτηση για lambdas μιλάμε.

[brute-force]

Να με συγχωράτε, ξεχνάω τα ελληνικά μου. Γενικά υπάρχουν πολλοί που παραπονιούνται ότι λείπει το τάδε feature από τη γλώσσα (συνήθως έχουν πέραση τα generics).

 

Εγώ προσωπικά είμαι ευχαριστημένος με αυτά που μου δίνει - με ένα τόσο απλό εργαλείο είμαι πολύ πιο παραγωγικός από ότι θα ήμουν αν μου εδίναν όλα τα features. Θα ήθελα να λύσουν το πρόβλημα με το vendoring το οποίο φαίνεται πως πάει να λυθεί τώρα officially γιατί third party λύσεις υπάρχουν πολλές. Ελπίζω να μην κατασταλάξουν σε JSON μόνο

 

Eπίσης ζηλεύω πολύ το design της Rust, free από race conditions και nil dereferences που είναι τα 2 τοπ είδη bugs στη Go.