Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.
A to prave nestaci. Protoze v te strukture, kterou posilas, muze byt nejaky pointer z te odesilajici goroutiny, a ty o tom vubec nevis (nejaka funkce si tam ulozila neco, cos necekal, ze si tam ulozi).
Jak rika Idris, musel bys kontrolovat cely strom - ne jenom tu horni strukturu, ale i vsechny ji odkazovane struktury.
Tomu rozumim, psal jsem o rozumne blbvzdornosti hlavne v porovnani s C.
Mechanismus pointeru a channelu neni slozity na pochopeni.
V normalnim programu mi ty pointerovane data budou vznikat lokalne v ramci loop smycky (a nasledne hned zapominany), poslany do IN channelu a vysledek vycitan z OUT channelu.
Samozrejme nemuzu posilat pointery na volatilni data.
V Jave to same, kdyz poslu ArrayList, do jehoz polozek mi nekdo z boku hrabe, dopadne to blbe.
V Jave sice muzes tomuto zamezit (
https://dev.to/monknomo/make-an-immutable-object---in-java-480n), ale kdo to v realu dela.
Pokud opravdu nastane situace, ze mi nekdo modikuje predavaci datovou strukturu, je neco hodne blbe v samotnem navrhu programu. Ale samozrejme je pravda, ze moznost definice immutable jednoduchou syntaxi je velice prinosna featura.
Pokud budu chtit v danem pripade zamezit tomuto v GO, staci do channelu posilat pointery na hluboke kopie danych struktur a hned je v main threadu zapominat.