Go Language

Co myślicie o Go Lang?
https://golang.org/

Fajne to będzie, nie fajne? Umrze szybko? Skazany na sukces?

Działa choinka, ma przyszłość:

package main
import "fmt"

func main() {
	count := 10;
	for i := 0; i < count; i++ {
		for j := count - 1; j >= i; j--{ fmt.Print(" "); }		
		for j := 0; j < i + i + 1; j++ { fmt.Print("*"); }
		fmt.Println();
	}
}

Takie to trochę składniowo pomieszanie Pascala z C/C++, coś w ten deseń. Jakieś dobre IDE by się do tego przydało, bo przez www to testować można najwyżej.

Krytyki to to tez zebralo a chyba najwazniejszy zarzut to "nothing new".

Jako, że ostatnio sporo siedzę w tych nowych językach (głównie Rust, ale i Go się trochę liznęło) to:

Zalety:

• prosta składnia - brak wodotrysków, i prosta logiczna składnia
• go fmt - de facto wymuszenie jednolitego stylu programowania na wszystkich developerach
• proste zarządzanie zależnościami
• prosta wielowątkowość i kanały
• szybkość względem języków skryptowych
• czasy kompilacji
• statyczne binarki

Wady:

• nil - serio? 2015 rok a my dalej popełniamy błędy ALGOLa?
• obsługa błędów - naprawdę, ktoś uznaje val, err := foo(); if err { … } za dobre rozwiązanie?
• brak typów generycznych (a przynajmniej częściowo), trzeba używać interface{} lub kopiować kod
• brak własnych iteratorów (jeszcze brak przeładowania operatorów zrozumiem)
• nihil novi

Więcej http://yager.io/programming/go.html

Podsumowanie

Go jest fajnym rozwiązaniem do pisania narzędzi CLI jako, że wypluwa standalone binarki. Jednak samemu nie wprowadza za wiele nowego, jedyne co zrobił to rozpowszechnił kanały jako metodę synchronizacji wątków.

W pozostałych przypadkach są IMHO lepsze rozwiązania (z nowych języków):

• strony internetowe: Elixir - przyjazna składnia i kompilacja do kodu wykonywalnego przez VM Erlang/OTP
• biblioteki natywne: Rust - brak GC i łatwy interop C <-> Rust
• Mobile/GUI: React Native/Swift

prosta wielowątkowość i kanały

Co jest niby takiego prostego w asynchronicznej wymianie komunikatów?
Ten model lepiej się skaluje, to fakt, ale żeby był prostszy czy mniej błędogenny? Nie zauważyłem.

Poza tym w wielu językach te rzeczy można dodać jako bibliotekę.

A umialby ktos zestawic scala vs go

Jasne: https://www.quora.com/Scala-vs-Go-Could-people-help-compare-contrast-these-on-relative-merits-demerits
https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/smithbrentgibsonleon.pdf

W sumie to zle zadalem pytanie, bo nawet nie wiem czy te jezyki powinno sie zestawiac obok siebie ;)
Chyba prędzej Rust jest konkurentem.

IMHO Rust i Go nie są konkurentami a bardziej dwoma połówkami tego samego jabłka.

W mojej firmie używamy Go jako backend aplikacji webowych. Mieliśmy do wyboru PHP, Pythona, Javę i Go, pierwsze dwa odpadły z oczywistych względów, Java odpadła, bo myślałbym cały dzień o @karolinaa, więc wybraliśmy Go ;)

Nie był to zły wybór, jak się porządnie w tym pisze, to na prawdę dobrze działa. Ciężko o błędy, których nie widać już podczas pisania/kompilowania, składnia jest bardzo prosta, bardzo dużo bibliotek, co jak na tak młody język jest raczej rzadkością.

Największa głupota (na pierwszy rzut oka, znając mechanikę języka jest to zrozumiałe) to JSON (un)marshaling i pola (nie)eksportowane ze struktur. Tego typu błędy możnaby pokazywać podczas kompilacji w "lepszym" języku. Interface{} to IMO troszkę zbyt duża abstrakcja, pozwala praktycznie na wszystko. Nie żebym nie lubił abstraksji, zwykle piszę w językach funkcyjnych, ale to jest jakieś krzywe ;)

Wydawało mnie się, że Python ma silną pozycją w webie? Dlaczego odpadł? Jakie to były oczywiste względy?

Tokyo napisał(a):

Wydawało mnie się, że Python ma silną pozycją w webie? Dlaczego odpadł? Jakie to były oczywiste względy?

• Jest powolny. Piszemy ogromne aplikacje, miliardy rekordów w bazie, które przepływają z urządzeń końcowych i klientów na nikim nie robią nawet wrażenia. Przy takich wolumenach danych stała się liczy.

• W aplikacjach wymagających wysokiego bezpieczeństwa statyczne typowanie to podstawa.

• Podobnie brak rozróżnienia pomiędzy deklaracją a przypisaniem.

• GIL? Pythonie, serio? A może interfejs do multiprocessingu który jest tak przyjemny przy współdzieleniu danych... I tak lekki pamięciowo :)

• Na koniec może jeszcze scoping... W pythonie3 "poprawili" to dodając "global" i "nonlocal", ale to IMO przykrywanie kupy kocykiem, nie widać, a nadal śmierdzi ;)

Podsumowując, sam używam Pythona i jestem z tym szczęśliwy, ale zawsze trzeba dobrać odpowiednie narzędzie do pracy. Pythona używam, jak chcę coś zrobić na chwilę, małego, nie wymagającego nie wiadomo jakiej wydajności. Łatwo się pisze, a działa. Można powiedzieć, że Python to taki mój sketchpad ;)

Myslicie, ze go moze sie sprawdzic do budowy np. Malych, srednich microservices? Bo chyba predzej to konkurencja dla node. Js niz javy?

Inne pytanie.. Czemu programisci python w jakiejs duzej czesci zaczeli uczyc sie go?

Krzywy Pomidor napisał(a):

Inne pytanie.. Czemu programisci python w jakiejs duzej czesci zaczeli uczyc sie go?

Python umiera ;)

A tak serio, to nie widzę specjalnej migracji to golang. Ludzie uczą się czasami nowości licząc na to że będą jakieś ciekawe nowy oferty pracy. To jest główny cel.

A czy GO LANG się przyjmie, to się zobaczy. Z pomocą Google na pewno będzie łatwiej. Dla mnie GO to kolejny język, który tak naprawdę nie wnosi nic nowego.

Na forach poczytalem jak ludzie od pythona probowali go a skonczyli na elixirze. Ktore tez raczej nie rozwiazuja tych samych problemow.

To ze nie wnosi nic nowego nie znaczy ze to zle. Bo jest stosunkowo latwy. Ale probuje sobie umiejscowic jakie go ma zastosowania. Wydaje mi sie ze do devops tools wydaje sie bardzo ok. I do high concurrency rowniez.

Budowa czegos malego sredniego co dziala natywnie nie jedzac tony ramu i szybko majac sporo rzeczy potrzebnych do tego zadania w samym jezyku jest atrakcyjna. A to ze w takim go nie da sie wszystkiego zrobic moze byc rowniez zaleta.

https://github.com/golang/go/wiki/SuccessStories

http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ apples vs oranges

http://blog.jonathanoliver.com/why-i-love-go/

Go vs java for service oriented architecture

https://m.reddit.com/r/golang/comments/4w4sws/go_vs_java_for_service_oriented_architecture/

Mały Szczur napisał(a):

Krytyki to to tez zebralo a chyba najwazniejszy zarzut to "nothing new".

Python też nothing new nie wprowadził, a znalazł sobie miejsce

Ja wiem że ten wątek ma pół roku, ale ciągle ktoś tu coś piszę, więc i ja odpiszę.

Po pierwsze, go ma już prawie 10 lat. Trochę późno zakładać o nim wątek i pytać "czy się uda".

Python też nothing new nie wprowadził, a znalazł sobie miejsce

Python nic nowego nie wprowadzał? Python powstał w ~~1991 roku (python 2.0 w 2000 roku). To wcześniej niż Ruby, Visual Basic, Java, JavaScript, PHP..., oraz ledwo kilka lat po Perlu.

Fakt faktem, że był wtedy dość biedny, ale...

Oczywiście nic "naprawdę nowego" czego nie było wcześniej nie wprowadził, bo podobno wszystko co kiedykolwiek powstało było wcześniej w Lispie (to w sumie tylko troche przesadzone stwierdzenie). Natomiast tak z głowy wymieniając, do mainstreamu wprowadził chociażby:

• list comprehension
• metody lambda (!)
• map/filter/reduce
• argumenty keywordowe

Oczywiście (jak pisałem) to wszystko było inspirowane lispem, ale tak czy inaczej to był dużo bardziej "odważny" język niż np. C#.

Kończąc dygresję...
W przypadku Go, największą innowacją są chyba goroutines. Można coprawda zastanawiać się czy ten ficzer na poziomie specjalnej składni języka faktycznie ma uzasadnienie, ale fakt jest faktem że działa dośc dobrze. Dzięki temu może świecić w jednej ze swoich nisz, czyli programowaniu równoległym.

Wydaje mi się też, że go było jednym z pierwszych języków które miało ustandaryzowany system paczek od początku (ale pewnie się mylę i jakiś język miał to 30 lat temu :P).

Ale języka Go nie lubię. Już tłumaczę dlaczego:

• Brak szablonów/generyków. Poważnie? Wszystkie "generyczne" kontenery są przez to bardzo brzydkie.
• System typów Go jest bardzo słaby (zarówno w porównaniu z "teoretycznymi" językami jak Haskell/Rust, oraz "praktycznym" C++).
• Range (foreach) można robić tylko na builtinach. Huh, ok.
• Zwracanie kodów błędu wszędzie zamiast wyjątków.
• Nie potrafię tego wytłumaczyć, ale ogólna "prostota" języka. Język był jawnie projektowany tak, żeby nie był zbyt trudny dla "szarego programisty", i ogólnie zakłada że programista jest głupi - więc na wszelki wypadek dba o programistę (np. operatora trójargumentowego nie ma, bo mozna go abusować. Przeciążania funkcji nie ma - bo można je abusować. Hashtablice używają hashy, ale nie można ich nadpisywać, bo można to abusować, albo zrobić źle, albo... - i tak dalej).

Edit: tak mi przyszło do głowy, kumulacja powyższych punktów i szczytowe osiągnięcie Go jako języka - funkcja "max":

• nie mamy szablonów, więc nie możemy zrobić:

T max(T a, T b) { ... }

// użycie
int x = max(a, b);

• nie mamy overloadowania funkcji, więc nie możemy zrobić:

int max(int a, int b) { ... }
short max(short a, short b) { ... }
unsigned max(unsigned a, unsigned b) { ... }
unsigned short max(unsigned short a, unsigned short b) { ... }
float max(float a, float b) { ... }
double max(double a, double b) { ... }

// użycie
int x = max(a, b);

*Nie mamy operatora trójargumentowego więc nie możemy zrobić

// użycie
int x = a > b ? a : b;

*Co mamy? Mamy ifa.

// użycie
int x;
if a > b {
    x = a
} else {
    x = b
}

Język na miarę XXI wieku.

No ale to jest tylko moja opinia, niektórzy używają go i lubią (jak widać w tym wątku) więc dla każdego jest dobre coś innego.

Ja tam Go dopiero musze sprobowac. Malo mnie obchodzi czy jezyk ma perspektywy czy nie. Wiekszosc jezykow poznaje, zeby miec wiedza ze pewne rzeczy mozna zrobic inaczej.

Zwlaszcza ze Go jest reklamowany jako prosty. Plus licze ze moze da sie go wykorzystac pod pare use casow.

Ale przegladajac opinie dp wielu rzeczy sie nie nadaje i wtedy lepiej uzyc javy lub scali.

Chcialbym sprawdzic Go do czegos stosunkowo malego, ewentualnie z duzym ruchem requestow albo jakis real time stuff.

msm napisał(a):

Ale języka Go nie lubię. Już tłumaczę dlaczego:

• Brak szablonów/generyków. Poważnie? Wszystkie "generyczne" kontenery są przez to bardzo brzydkie.
• System typów Go jest bardzo słaby (zarówno w porównaniu z "teoretycznymi" językami jak Haskell/Rust, oraz "praktycznym" C++).
• Range (foreach) można robić tylko na builtinach. Huh, ok.
• Zwracanie kodów błędu wszędzie zamiast wyjątków.
• Nie potrafię tego wytłumaczyć, ale ogólna "prostota" języka. Język był jawnie projektowany tak, żeby nie był zbyt trudny dla "szarego programisty", i ogólnie zakłada że programista jest głupi - więc na wszelki wypadek dba o programistę (np. operatora trójargumentowego nie ma, bo mozna go abusować. Przeciążania funkcji nie ma - bo można je abusować. Hashtablice używają hashy, ale nie można ich nadpisywać, bo można to abusować, albo zrobić źle, albo... - i tak dalej).

Właśnie wymieiłeś jego największe zalety

Odnośnie golang to zastanawiam się czy nie warto się trzymać gołego golanga zamaist korzystać z 'frameworków'.

np. http://nordicapis.com/writing-microservices-in-go/ wygląda bardzo prosto a czasem zyllion frameworków może przeszkadzać.

Pijany Terrorysta napisał(a):

msm napisał(a):

Ale języka Go nie lubię. Już tłumaczę dlaczego:

• Brak szablonów/generyków. Poważnie? Wszystkie "generyczne" kontenery są przez to bardzo brzydkie.
• System typów Go jest bardzo słaby (zarówno w porównaniu z "teoretycznymi" językami jak Haskell/Rust, oraz "praktycznym" C++).
• Range (foreach) można robić tylko na builtinach. Huh, ok.
• Zwracanie kodów błędu wszędzie zamiast wyjątków.
• Nie potrafię tego wytłumaczyć, ale ogólna "prostota" języka. Język był jawnie projektowany tak, żeby nie był zbyt trudny dla "szarego programisty", i ogólnie zakłada że programista jest głupi - więc na wszelki wypadek dba o programistę (np. operatora trójargumentowego nie ma, bo mozna go abusować. Przeciążania funkcji nie ma - bo można je abusować. Hashtablice używają hashy, ale nie można ich nadpisywać, bo można to abusować, albo zrobić źle, albo... - i tak dalej).

Właśnie wymieiłeś jego największe zalety

Serio @pijany Terorysta? Uważasz to wszystko za zalety? Zwłaszcza tragiczną obsługę błędów? Nie mówię, że wyjątki są dobre, ale to co robi Go jest jeszcze gorsze od wyjątków.

Go at Dropbox - Zviad Metreveli - Gopherfest - November 18, 2015

Czy w Go uzywa sie dependency injection?

Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby
https://hashrocket.com/blog/posts/websocket-shootout

czy takie benchmarki na pewno mają sens?

najz
https://text.sourcegraph.com/google-i-o-talk-building-sourcegraph-a-large-scale-code-search-cross-reference-engine-in-go-1f911b78a82e#.o3m48ov91

@biały Mleczarz testowałem tą samą aplikację napisaną przez nas w Go i Java - produkcyjnie. Z tym, że Go wykorzystywała Revel, zaś wersja w Java Playframework. Responsywność była wyższa po stronie Javy, po prostu było to czuć (nawet bez benchmarków) przy większym obciążeniem.

Problemy zaczynały się przy większej ilości sesji. W tej sytuacji wychodziły problemy z wydajnością driverów MySQL. Teoretycznie wersja w Go potrafiła obsłużyć około 3000 sesji, jednak w praktyce - serwer dławił się przy około 250 sesjach. Wersja w playframework działała znakomicie przy ponad 300 sesji - nadal bardzo wydajnie.

Problemem były także wycieki pamięci po stronie Revel'a - który miał ich dość sporo. Sam Go w stosowanej wersji także miał troszkę za uszami. Po rocznej produkcji, mogę powiedzieć Go jest naprawdę świetny - jednak z wydajnością jest różnie i na pewno nie tak kolorowo jak na wykresach.

Ważnym czynnikiem było wykorzystanie pamięci. Wersja Java wykorzystywała około 2,5 GB RAM w 150 sesjach. Wersja w Go około 600 MB

@dabra
Widać, że w Go jest jeszcze dużo miejsca na poprawki.
I ostatnio poprawiono chyba ogólny performance, pojawił się też lepszy lib do JSONa, stop the world GC w nowej wersji ma być na poziomie max 100 mikrosekund i przede wszystkim ponoć poradzono sobie z latency.

Mógłbyś poradzić, gdzie to można jakoś za darmo zdeployować w jakiejś chmurze? Heroku? 4fun. Można na jakimś cloud deployować kontenery Dockera? ;)

Ciężkawy artykul
https://hackernoon.com/golang-or-the-future-of-the-dev-984c2f145bbe#.3utchwlst