Czy Google's Go to język bezpieczny dla typu?


14

ta strona http://golang.org/doc/go_faq.html pisze:

chociaż Go ma typy statyczne, język próbuje sprawić, że typy będą lżejsze niż w typowych językach OO

Więc moje pytanie brzmi: czy jest bezpiecznie wpisane za pomocą generycznych (jak C #), czy luźno (jak javascript), czy opcjonalnie (jak opcja ścisła w Vb.Net)


@JamesMcNellis, co oznacza, że ​​jeśli typ się nie powiedzie, może to wynikać tylko z tego, że dokonuję rzutowania (żadna inna akcja nie powinna powodować wyjątku typu)
Pacerier

1
@ davidk01 Java skompiluje się (1 + „boo”), a Java jest bezpieczna dla typu. Wyrażenie to ma określone znaczenie statyczne, ponieważ język + jest przeciążony dla obiektów typu String, a wszystkie prymitywne literały można podnosić czcionką do obiektów zawiniętych, które można następnie przekształcić w łańcuchy.
Trixie Wolf,

Odpowiedzi:


26

Bezpieczeństwo typu nie jest bezpieczne dla typu czarno-białego, czy nie. Jest to bardziej spektrum, a niektóre języki mogą być bardziej bezpieczne dla tekstu niż inne (i odwrotnie). Myślę jednak, że to, co myślisz o C # vs. JavaScript, to prawdopodobnie pisanie statyczne (gdzie sprawdzanie typów odbywa się w czasie kompilacji) vs. pisanie dynamiczne (gdzie sprawdzanie typów odbywa się w czasie wykonywania) - z pewnością to o czym mówi Go FAQ.

Google Go jest wpisywany statycznie, ale wiele funkcji sprawia, że ​​„wydaje się” być (przynajmniej nieco) dynamicznie wpisywanym. Na przykład nie musisz jawnie oznaczać swojej klasy jako implementującej jakiekolwiek interfejsy. Jeśli sygnatury metod twojej klasy są zgodne z podpisami w interfejsie, twoja klasa automatycznie implementuje ten interfejs (rodzaj pisania kaczego). Jest to przydatne do rozszerzania wbudowanych klas i klas w bibliotekach stron trzecich, ponieważ możesz po prostu skonfigurować interfejs tak, aby pasował do metod w klasie innej firmy i automatycznie go zaimplementuje.

Bezpieczeństwo typu jest w rzeczywistości inną „osią” systemu typów. Na przykład C jest językiem o typie statycznym, który nie jest bezpieczny pod względem typu - wskaźniki pozwalają robić prawie wszystko, co lubisz, nawet rzeczy, które powodują awarię programu. JavaScript jest wpisywany dynamicznie, ale jest także bezpieczny pod względem typu: nie możesz wykonywać operacji, które spowodowałyby awarię programu. C # jest w większości bezpieczny dla typu, ale możesz jawnie oznaczyć obszary kodu, które są, unsafei robić rzeczy, które nie są już bezpieczne dla typu.

Google Go jest również bezpieczny pod względem typu, ponieważ nie można manipulować typami i zawieszać programu (brak bezpośredniego dostępu do wskaźników).


Chyba że użyjesz „niebezpiecznego” pakietu, w którym to przypadku możesz zawiesić program w dowolny sposób :)
Eloff

Państwo może poeksperymentować z typami i masz dostęp do wskaźników. Tak, w ten sposób możesz łatwo zawiesić swój program.
wyjechał

4

Jest bezpiecznie wpisany, że typ nigdy nie zostanie źle zinterpretowany, ale niepoprawny typ może spowodować, że program wpadnie w panikę.


nie rozumiem, czy to oznacza, że ​​można skompilować kod inny niż bezpieczny? (co nie jest możliwe w języku C #, chyba że użyjemy dynamiki)
Pacerier

Robi twierdzeń, typ-mądry, jest w zasadzie jak wywołanie metody na typ dynamicznego
dan_waterworth

ok, więc w skrócie nie ma tego rodzaju bezpieczeństwa typu c # pozwala?
Pacerier

Dzieje się tak, jeśli nie wpisujesz asercji.
dan_waterworth

5
@Pacerier: Jest całkowicie możliwe uruchamianie niepoprawnych wyrażeń w języku C # bez dynamiki: wystarczy wstawić rzutowania wszędzie (co w zasadzie jest typem asercji).
sepp2k

-1

Typ mapy Go nie jest bezpieczny dla wątków, jest wpisywany statycznie. Nie ma ona dziedziczenia typu, programowania ogólnego, asercji, przeciążania metod ani arytmetyki wskaźników i nie bez powodu.

Bezpieczeństwo typu i bezpieczeństwo pamięci są celami długoterminowymi, tu leży problem.

Typ bezpieczeństwa stanowi narzut, w kilobajtach i megabajtach, co jest dopuszczalne. Go jest zaprojektowany z MapReduce i „Big data”, egzobytuje petabajty danych, co przedstawia problemy z wydajnością związane z bezpieczeństwem typów, sprawdzanie typów (boxing / unboxing) powoduje koszty ogólne i zabiera cykle przetwarzania.

Bezpieczeństwo typów może być ograniczające w zakresie podtytułu i polimorfizmu oraz podczas pisania kaczego (rzutuj obiekt na obiekt), co stwarza zagrożenia, a także przestrzeń, w której języki takie jak Go są bardzo przydatne. C ++ i Java nie są zastępowane przez Go, jest to nowy język, który pomaga w rozproszonym programowaniu i masowo równoległym systemie.

Duża wypowiedź Bruce'a Eckela - „Go ma znacznie więcej sensu dla klasy problemów, które C ++ pierwotnie zamierzał rozwiązać”, jest dyskusyjna. C ++ jest bardzo wydajnym językiem, a implementacja Boost MapReduce jest bardzo wydajna.

Prymitywy współbieżności są przyszłością. Bezpieczeństwo typu zawsze było bardzo kontrowersyjnym tematem, a Go może być pierwszym językiem, który rozwiązuje ten problem od 20 lat lub od Algolu.


3
Niestety potrzebuję więcej reputacji, aby -1 odpowiedź. Bezpieczeństwo typów nie jest narzutem, narzut nie jest zdecydowanie mierzony w jednostkach bajtów, a go ma boxing / unboxing w sensie Java. Wpisywanie statyczne pozwala kompilatorowi na dokonanie większej liczby optymalizacji niż w przypadku języka dynamicznego. Zmniejszenie mapy nie jest ani tu, ani tam, to samo z bezpieczeństwem wątków.
Eloff,

Idiom Golanga polegający na tym, że podajesz typy przy użyciu pustego interfejsu jako wspólnego wzorca, aby uniknąć implementacji generycznych jako funkcji językowych, z pewnością nie jest czymś, co uważam za „bezpieczne dla typu”, i chociaż może to ułatwić określenie specyfikacji języka, gdy problem powstaje (i będzie) pozostawia złożoność na talerzu osoby, która teraz została, aby rozwiązać problem z rolką kranu kanałowego Golang nazywa funkcję. Z pewnością nie wygląda to na język, który został zaprojektowany w ciągu ostatnich dwóch dekad, ponieważ istnieją języki, które znacznie poprawiają bezpieczeństwo typów.
tsturzl
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.