Mono

[pascal]

Recentelijk instaleerde ik een pakketje en zag dat het zwaar op mono leunt.
In een grijs verleden eens wat mee geexperimenteerd en ik moet toegeven dat ik destijds angenaam verrast was.
Zonder ook maar enige kennis van zaken had ik in notime een multithreading socket client demo in elkaar gezet,
dit zonder visual studio maar gewoon met mijn favoriete vi editor en de documentatie van MSDN
Voor documentatie over mono moet je zeer zeker niet bij Linux zijn, en ik heb ook geen flauw idee hoe ik had uitgevonden hoe het te gebruiken, welke monolibraries mee te nemen ect. het werkte en het werkte goed, iets wat ik van java nooit heb kunnen zeggen.

Mijn grote aversie tegen mono was ook niet de taal maar dotnet, een grote verzameling stieren sediment met als doel om microsoft afhanekelijk te kweken en ongekwalificeerde knutselaars een baan als developer te kunnen bieden. tot zo ver mijn rant.

Wat mij eerder opviel is dat mono reeds lang niet meer ondersteund word door de OpenBSD developers.
Wat daar de reden voor is ben ik vergeten, maar deed mij vermoeden dat Linux distro's snel zouden volgen.

Kenlijk is het zo ver nog niet.

[bart]

De laatste tijd doe ik een hoop programmeerwerk in go (golang). Dat programmeert lekker, overzichtelijk. Heeft een paar eigenaardigheidjes, naar over de hele linie gezien heel prettig. Kan mono niet aan tippen.

[iswrong]

Edit: sorry dat dit wat rant'y is. Als je tevreden bent met Go is dat natuurlijk tof!

De laatste tijd doe ik een hoop programmeerwerk in go (golang). Dat programmeert lekker, overzichtelijk. Heeft een paar eigenaardigheidjes, naar over de hele linie gezien heel prettig. Kan mono niet aan tippen.

Ik heb ~2 jaar bijna al m'n programmeerwerk in Go gedaan (academische vrijheid). Had zelfs een mild populaire binding voor Tensorflow. Ik kan de hele ervaring samenvatten als: meh. Maar ik zal positief beginnen: Go heeft een geweldige standaardbibliotheek, heel erg UNIXy, en bevat alle basisbehoeftes. En het compileert naar native code en gebruikt geen VM.

Go als taal is niet vreselijk, had je ook niet verwacht van de mensen die ondermeer achter Plan 9 zaten. Maar de Go mensen lijken ook circa 20-30 jaar in ontwikkeling in programmeertalen niet mee te hebben gekregen. Wat je krijgt is een taal dat heel erg op Java pre-generics lijkt, behalve dat het structural typing voor interfaces heeft en naar native binaries compileert. Als je Java 1.4 niks vond, dan vind je Go waarschijnlijk ook niks.

Go lost veel problemen niet op, Go heeft bijvoorbeeld nog steeds null pointers en heeft het zelfs erger gemaakt door meerdere soorten nil (null) pointers te introduceren (zeg maar fat en niet fat), waardoor je dit soort onzin krijgt:

Code: Selecteer alles

var a interface{} = nil
var b *int = nil
fmt.Println("a == b:", a == b) // Print a == b: false

Interoperabiliteit met C is matig. De overhead van C calls is heel erg groot (ondermeer wegens stack switching, andere calling conventions, extra checks). Dus even wat C functies aanroepen in een tight loops is er niet bij als performance belangrijk is. Verder is het heel beperkt wat je kunt doen in C interop. Je kunt bijvoorbeeld geen data die in Go is gealloceerd (dus niet met malloc) tussen cgo calls onderdeel maken van een C datastructuur (wat bijv. callbacks lastig maakt), omdat de Go garbage collector het geheugen zou kunnen reclaimen.

Go's 'claim to fame' is concurrent programming. Maar eigenlijk werkt dat alleen vrij redelijk als je channels gebruikt. Als je geen channels gebruikt val je gewoon weer terug op mutexes en omdat het typesysteem van Go heel erg beperkt is, voorkomt het geen data races. Channels hebben het probleem dat ze relatief langzaam zijn (vroegere Go packages vingen het gebrek van for-each style loops voor je eigen data types op door channels te gebruiken met het gevolg dat iteratie tergend langzaam was). Ook kun je met channels relatief eenvoudig goroutines maken die blijven hangen.

Omdat Go geen generics ondersteunt zijn er een paar datastructuren die eersteklas burgers zijn, bijv. maps en slices. Die datastructuren hebben de luxe van for-each stijl loops, etc. Maar je kunt geen andere datastructuren implementeren die dezelfde luxe hebben, omdat Go geen generiek mechanisme heeft voor bijv. iterators. Ook loop je bijv. tegen problemen als dat je niet generiek met numerieke types kunt werken, waardoor veel bibliotheken bijv. alle functionaliteit apart voor 32-bit en 64-bit floating point types moet implementeren. Veel bibliotheken gebruiken daarom ad-hoc code generatie, etc. Verder eindigt veel 'generieke' code met het gebruik van interface{} (zeg maar Go's void *). Lelijk en vereist runtime introspection om de data later te kunnen gebruiken (yep, net als in pre-generics Java, toen alles een Object werd en je ook achter moest uitvogelen met introspection wat je mee te maken had).

Go's compiler is gebaseerd op de Plan 9 C compiler, die op een gegeven moment semi-automatisch naar Go is geconverteerd. De compiler is geleidelijk wat beter geworden, maar ik heb een tijdje terug eens een paar uur gespendeerd aan het vergelijken van machine-code output van gcc, gc (de Go compiler), en rustc (Rust compiler met LLVM backend). Even los van het feit dat do Go compiler geen autovectorizatie doet, is de gegenereerde ronduit bedroevend. Vaak faalt basale escape analysis, vind er amper inlining plaats (waardoor allerlei andere optimalisaties ook niet mogelijk zijn), etc. Daarbij werden er ook nog opvallen vaak onnodige functieaanroepen in hot paths gedaan. Het gevolg is dat vaak code identiek herschrijven in C of Rust 2x-5x sneller is. En dan hebben we het nog niet over numerieke code ofzo, waar door beter optimalisatie + autovectorisatie het verschil nog veel groter is. Er is een gcc frontend, maar die geeft blijkbaar de gcc backend te weinig informatie, want in de praktijk produceert het geen snellere code dan gc.

Ik stop hier maar voordat het een te lang monoloog wordt (no pun intended ). Go is een best aardige taal voor UNIX dingen, met een mooie standaardbibibliotheek, een goed boek (The Go Programming Language van Donovan en Kernighan). Maar er zijn veel betere alternatieven.

---

Terug naar Mono. Mijn kritiek is op Mono eigenlijk precies het omgekeerde van mijn kritiek op Go. C# is een prima, moderne taal, wat anders zouden we van Anders Hejlsberg verwachten. Er zijn goede JIT en AOT compilers voor C# (waaronder Mono). Alleen net als bijv. Java is de standaardbibliotheek niet heel erg UNIXy. En je zeult (tenzij je AOT gebruikt) altijd een VM mee. En je krijgt DLLs op je filesystem. Bah, vies!

Als je een Windows developer bent en van Windows-conventies houdt, dan is er niets mis met C# en .NET.

[bart]

In grote lijnen ben ik het redelijk eens met je kritiek op go. Maar geen enkele taal is perfekt, hé.

Als je goroutines gebruikt zonder channels, dan moet je idd weer ouderwets gaan zitten mutexen. Maar die twee samen is juist een gouden combi.

Binnenkort zal ik 's naar je tensorflow binding kijken. Vooralsnog ben ik op dat vlak met handen en voeten gebonden aan python (yuck!).

Maar om even op pascal's voorbeeld terug te komen; ik ken geen taal waarin je dat vlotter in elkaar klust dan in go.

En m'n grootste bezwaar tegen mono noem je zelf al in je laatste 3 zinnen .

[pascal]

Daniel,

Currently niet heel erg in staat alles te doorgronden maar je voorbeeld

Code: Selecteer alles

var a interface{} = nil
var b *int = nil
fmt.Println("a == b:", a == b) // Print a == b: false

Zou het niet als volgt moeten zijn ? :

Code: Selecteer alles

var a interface{} = nil
var b *int = nil
fmt.Println("a === b:", a === b) // Print a === b: true

Ik weet verder absoluut niets van go.
Kunnen we hier niet een eigen threat over openen ?
is het overigens threat of treath ? en hoe vertaal je "Van de mup geflupt" ?

[iswrong]

In grote lijnen ben ik het redelijk eens met je kritiek op go. Maar geen enkele taal is perfekt, hé.

Eens! M'n verhaal kwam misschien ook wel heel erg negatief over. Met Go werken is zeker geen straf .

Binnenkort zal ik 's naar je tensorflow binding kijken. Vooralsnog ben ik op dat vlak met handen en voeten gebonden aan python (yuck!).

Upstream Tensorflow heeft ook al een tijdje een Go binding. Aangezien die onderhouden wordt, is dat aan te raden boven mijn binding. Ik ben ermee gestopt omdat ik naar Rust over ben gegaan, dus overgegaan naar de Rust Tensorflow binding. Inmiddels gebruik ik Torch, en met de tch Rust binding kan ik netwerken gewoon rechtstreeks in Rust bouwen. Bijv. hier een port van Huggingface Transfomers' BERT model:

https://github.com/stickeritis/sticker- ... ert/mod.rs

Maar om even op pascal's voorbeeld terug te komen; ik ken geen taal waarin je dat vlotter in elkaar klust dan in go.

Dat is denk ik ook een kwestie van gewenning en in welke mate je het ecosysteem kent. Ik denk dat ik inmiddels een stuk vlotter in Rust ben. Maar ik gebruik veel van dezelfde crates opnieuw. Maar Rust heeft ook veel ergnomische handigheden, zoals hoe iterators opgezet zijn, compactere error handling, (beperkte) operator overloading.

Ik denk wel dat er bijna geen statisch getypte taal is waarmee je zo snel aan de slag kunt dan met Go. Als je bijvoorbeeld C, Java, of wat dan ook kent, kun je al Go schrijven in 1-2 dagen. Misschien nog niet ideomatisch, maar genoeg om productief te zijn. Dat is in bijv. Rust absoluut niet het geval .

[iswrong]

Daniel,

Currently niet heel erg in staat alles te doorgronden maar je voorbeeld

Code: Selecteer alles

var a interface{} = nil
var b *int = nil
fmt.Println("a == b:", a == b) // Print a == b: false

Zou het niet als volgt moeten zijn ? :

Code: Selecteer alles

var a interface{} = nil
var b *int = nil
fmt.Println("a === b:", a === b) // Print a === b: true

Drie equals signs, het is toch geen Javascript?!?

Overigens zou de code verkort kunnen worden tot bijv.:

Code: Selecteer alles

var a interface{}
var b *int
fmt.Println("a == b:", a == b) // Print a == b: false

Want `nil` is de standaard-initialisatie voor pointers en referenties.

Wat hier fout gaat is dat

Code: Selecteer alles

var b *int

Een traditionele pointer is zoals je die in C kent. Terwijl je

Code: Selecteer alles

var a interface{}

Zou kunnen zien als een fat pointer, bestaande uit twee pointers: een pointer naar de daadwerkelijke data en een pointer naar de itable (vergelijkbaar met een vtable in bijv. C++) die pointers naar methodes bevat (dus hier {nil, nil}).

Go heeft hier een wat merkwaardige benadering. In dit geval zou je zeggen dat de expressie a == b een type error zou moeten zijn.

Maar ook bij het vergelijken van referenties gaat het vaak fout, omdat bijv. {nil,nil} niet gelijk is aan {nil,itable pointer voor een type}.

[pascal]

Ik ben niet bekend met Go anders dan wat mij eens een enkele keer gedemonstreerd is.
Bij al deze hogere talen word getracht om de hiaten op te lossen, maar in werkelijkheid lijken ze vooral vervangen te worden door andere uitdagingen.

Ik denk dat elke taal wel wat heeft, ik refereerde elders al aan VHDL (Niet echt een Programeer Taal maar een Hardware Defenition Language afgeleid van talen als ADA)
Wat mij erg aanspreekt is de 'strongly typed" eigenschappen noodzakelijk om voorspelbaar gedrag te realiseren.
Maar ook vhdl blijkt niet waterdicht te zijn, en ook hier geld dat de meeste bugs op het toetsenbord onstaan.
"Ahhh joh laat maar is niet nodig, dat fixen we later wel" is ook hier garantie tot de meest bizare resultaten.
En hier is het niet een debugger die je verder helpt en zelfs een logic analyser is maar beperkt inzetbaar.
Tja... het blijft toch een vak he.

[iswrong]

Ik ben niet bekend met Go anders dan wat mij eens een enkele keer gedemonstreerd is.
Bij al deze hogere talen word getracht om de hiaten op te lossen, maar in werkelijkheid lijken ze vooral vervangen te worden door andere uitdagingen.

Ik ben niet zo pessimistisch. Het wordt tijd om C langzaam in de UNIX community te vervangen. Ongeveer 70% van alle security kwetsbaarheden in C projecten worden veroorzaakt door geheugenfouten (een paar organisaties en bedrijven hebben studies gedaan en ze lijken redelijk consistent op 70% uit te komen). Deze hele klasse van fouten heb je niet meer (of leiden tot een nette panic) zodra je op een veilige taal als Go of Rust over gaat. Even los van alle andere verbeteringen die deze talen bregen boven C en C++.

Het verschil met voorgaande pogingen C te vervangen is dat Rust en Go echt vooruitgang lijken te maken. Docker is bijvoorbeeld in Go geschreven (terwijl dat vroeger een typisch C project zou zijn). Firefox heeft al een redelijke hoeveelheden C++ code met Rust vervangen, bijvoorbeeld de CSS layout code en de WebRender implementatie, maar ook Amazon's Firecracker VMM for lightweight VMs, kleine stukjes van GNOME (librsvg).

Zelf ben ik meer fan van Rust. Omdat het geen garbage collector en zero cost abstractions gebruikt is het in veel gevallen een geschiktere vervanging voor C en C++. Ook is Rust veel sterker qua typing, met generics, traits (die zowel voor runtime als compile-time polymorphisme gebruikt kunnen worden), algebraic data types, etc. Als Rust er niet was geweest dan had ik zeker Go gebruikt. Beide talen zijn een grote vooruitgang boven C. Veilig, maar toch in de UNIX traditie.

Ahhh joh laat maar is niet nodig, dat fixen we later wel" is ook hier garantie tot de meest bizare resultaten.

Ja, dat is helaas de dagelijke realiteit. Een product snel afleveren wordt vaak belangrijker gevonden dan een product goed afleveren .