13.02.20233 min
Maciej Olanicki

Maciej OlanickiRedakcja Bulldogjob

Programistów Go czeka niemiłe zaskoczenie

Zapowiedzi jednego z inżynierów Google spowodowały silny sprzeciw – czy Golang będzie domyślnie dzwonił do domu?

Programistów Go czeka niemiłe zaskoczenie

Przyzwyczajono nas już do tego, że telemetrię wykorzystują systemy operacyjne czy oprogramowanie użytkowe. Często zgodnie z dewizą, że gdy coś jest za darmo, to użytkownik jest produktem, choć komercyjny software nie stanowi żadnego wyjątku. Zaskoczeniem mogą być jednak praktyki zapowiedziane przez Russa Coxa, inżyniera od 16 lat pracującego w Google nad rozwojem języka Go. Według niego pożądanym stanem rzeczy byłoby, aby śledziły nas języki programowania.

Telemetria w Go

Można odnieść wrażenie, że Go, podobnie jak Rust, to jeden z tych relatywnie młodych języków programowania, o którym sporo się mówi, a stosunkowo niewiele się z nim robi. Nie chodzi rzecz jasna o rozwój samego języka, ten przebiega bez zarzutu, lecz o bazę kodu spisaną w Go. Co prawda są już duże usługi, jak choćby Uber czy Badoo, zaś na polskim gruncie Allegro, które w ten lub inny wykorzystują komponenty napisane w Golang, niemniej języka utworzonego przez Google próżno szukać na szczycie rankingów popularności.

Zmianie tego stanu rzeczy nie będą sprzyjać wypowiedzi wspomnianego Russa Coxa. Na swoim blogu rozważa on sposoby, w jakie projekty open source mogą wykorzystywać telemetrię. Jeden z nich – mimo że jest to na razie luźna propozycja – już zdołał wzbudzić sprzeciw społeczności programistów Go. Według Coxa dobrym pomysłem jest bowiem to, aby narzędzia wykorzystywane do pisania oprogramowania w Go miały domyślnie włączoną telemetrię i automatycznie wysyłały dane do Google.

W rezultacie do zespołu rozwijającego Golang miałyby trafiać między innymi takie informacje, jak najczęściej wykorzystywane funkcje języka. To miałoby być czynnikiem w procesie decyzyjnym dotyczącym dalszego rozwoju Go, zgodnie z modnym paradygmatem data-driven. Pomysł jest o tyle ciekawy (i kontrowersyjny), że Cox chce w ten sposób przenieść ciężar telemetrii z użytkownika na programistę – jeśli odpowiednie dane zostałyby zebrane jeszcze na stacji roboczej programisty, wówczas w tym procesie nie musieliby już brać udziału końcowi odbiorcy oprogramowania.

Przyczyny kontrowersji 

Co zatem wzbudza takie niezadowolenie? Kluczowe zdają się dwa czynniki: po pierwsze, Cox chciałby, by telemetria w Go i projektach open source była domyślnie włączona. To dość niecodzienne podejście: z reguły zbieranie danych poprzedzone jest czytelną prośbą o zgodę na udział. Robi tak nawet Microsoft, który co prawda w przypadku Windowsa nie umożliwia całkowitej rezygnacji z telemetrii, niemniej pozwala ograniczyć ją do minimum już na etapie konfiguracji po pierwszej instalacji. 

Po drugie, Golang nierozerwalnie kojarzone jest z Google. To właśnie w tej korporacji pracowali Ken Thompson, Robert Griesemer, Rob Pike, gdy projektowali język, kierując się podzielaną między innymi przez Linusa Torvaldsa niechęcią wobec C++. Problem w tym, że o Google można powiedzieć bardzo wiele, ale na pewno nie to, że słynie z troski o prywatność użytkowników swoich produktów i usług. Recepcja pomysłu Coxa byłaby zapewne inna, gdyby rozwój Go był nadzorowany przez taką korporację, do której nie przylgnęło określenie Wielki Brat.

Telemetria w narzędziach developerskich standardem?

Od zarysowanych planów do ich realizacji i faktycznego wdrożenia w toolchainie Go domyślnie włączonej telemetrii daleka droga. Warto jednak wspomnieć, że szlaki zostały już przetarte – telemetrię stosuje choćby Microsoft w .NET. Czy zatem powinniśmy przyzwyczajać się do tego, że zintegrowane środowiska programistyczne, frameworki czy biblioteki będą „dzwonić do domu”? Bez wątpienia dla rozwijających je firm informacje o tym, co i jak robią programiści, to bardzo łakomy kąsek. Vide GitHub Copilot.

<p>Loading...</p>