De Devschuur Coffee Corner - Iteratie ⓬

[qless]

Blazor gebruikt toch mono in web assembly?

[ZaZ]

qless schreef op woensdag 17 juli 2019 @ 10:33:
Blazor gebruikt toch mono in web assembly?

Client side Blazor wel. Als je server side Blazor gebruikt wordt heel mono niet gebruikt.

[armageddon_2k1]

Ik ben geintrigeerd geraakt door Rust nu. En nu moet en zal ik alles in Rust doen, hoe masochistisch dat ook is als iemand zonder enige systems-level programming ervaring. En als ik al een simpel hobbyprojectje in Rust doe dan moet ik ook nog eens de hele tijd alles premature optimizen . En natuulijk moet het dan ook in WebAssembly gaan werken. Maar ach, het houdt me van de straat zeg maar.

[.oisyn]

armageddon_2k1 schreef op woensdag 17 juli 2019 @ 13:06:
Ik ben geintrigeerd geraakt door Rust nu. En nu moet en zal ik alles in Rust doen, hoe masochistisch dat ook is als iemand zonder enige systems-level programming ervaring.

Prima, maar blijf alsjeblieft uit de buurt van de Rust cult. Evangelisten zijn het

[armageddon_2k1]

Heuh, hoe bedoel je?

[DeluxZ]

ZaZ schreef op woensdag 17 juli 2019 @ 10:52:
[...]

Client side Blazor wel. Als je server side Blazor gebruikt wordt heel mono niet gebruikt.

Tot ze volgend jaar met .NET 5 komen gok ik zo

[Gropah]

armageddon_2k1 schreef op woensdag 17 juli 2019 @ 13:48:
Heuh, hoe bedoel je?

Het is een beetje een meme geworden, maar er is geen groot project geweest wat geschreven is in c of c++ waarbij de vraag: "zullen we het anders maar herschrijven in rust?" niet is gesteld. En dat heeft een aantal mensen nogal op hun teentjes getrapt. Vaak terecht ook. Een voorbeeld is bij sqlite, waar iemand er gewoon een paragraaf over heeft geschreven in een blog-achtig iets, waarvan het mij niets zou verbazen als die uberhaupt is geschreven door dat soort vragen.

Overigens is dat gedrag wel heel herkenbaar. Zo zit ik nu een beetje met Go voordeel is wel dat ik het voor mijn werk nodig heb, dus dat itch al redelijk scratcht.

[ Voor 5% gewijzigd door Gropah op 17-07-2019 14:44 ]

[.oisyn]

armageddon_2k1 schreef op woensdag 17 juli 2019 @ 13:48:
Heuh, hoe bedoel je?

Dat bepaalde Rust mensen elke C(++)-discussie aan lijken te grijpen om Rust te promoten . Onder veel CppCon talks op Youtube staan ook allemaal Rust comments . Op een of andere manier vinden ze Rust de heilige graal en moet iedereen maar overstappen.

[ Voor 13% gewijzigd door .oisyn op 17-07-2019 16:10 ]

[armageddon_2k1]

Ah op die fiets. Ik begeef me helemaal niet in C++ kringen en fora, dus dat krijg ik niet mee

[ThomasG]

armageddon_2k1 schreef op woensdag 17 juli 2019 @ 14:53:
Ah op die fiets. Ik begeef me helemaal niet in C++ kringen en fora, dus dat krijg ik niet mee

Wat doe je hier dan?

[armageddon_2k1]

Hoeveel mensen doen hier echt C++ op dagelijkse basis. Het zijn er een paar De rest van het gepeupel kloot maar wat aan met inferieure andere taaltjes En dit is geen sec C++ topic.

[ Voor 26% gewijzigd door armageddon_2k1 op 17-07-2019 15:21 ]

[ZaZ]

Ben je er nou nog?

[.oisyn]

armageddon_2k1 schreef op woensdag 17 juli 2019 @ 15:20:
De rest van het gepeupel kloot maar wat aan met inferieure andere taaltjes

Zoals Rust Hey kijk daar, een banaan!

I kid, Rust zit best aardig in elkaar, en sommige dingen zou ik graag in C++ zien.

[ Voor 18% gewijzigd door .oisyn op 17-07-2019 15:30 ]

[Merethil]

.oisyn schreef op woensdag 17 juli 2019 @ 15:28:
[...]


[font size=8]Zoals Rust[/] Hey kijk daar, een banaan!

I kid, Rust zit best aardig in elkaar, en sommige dingen zou ik graag in C++ zien.

Vliegt daar een dood vogeltje?!

[Hydra]

.oisyn schreef op woensdag 17 juli 2019 @ 14:43:
Dat bepaalde Rust mensen elke C++-discussie aan lijken te grijpen om Rust te promoten

FTFY

[.oisyn]

Hydra schreef op woensdag 17 juli 2019 @ 16:10:
[...]


FTFY

Maar is dat zo? Rust zit redelijk aan de native kant zoals C en C++. Het is zelden een valide alternatief voor iets als PHP of Javascript, om maar wat zijstraten te noemen. Maar goed, ik begeef me niet echt in andere kringen dus ik kan weinig zeggen over het gedrag van Rust-supporters daar

[ Voor 16% gewijzigd door .oisyn op 17-07-2019 16:12 ]

[Hydra]

.oisyn schreef op woensdag 17 juli 2019 @ 16:11:
Maar is dat zo? Rust zit redelijk aan de native kant zoals C en C++. Het is zelden een valide alternatief voor iets als PHP of Javascript, om maar wat zijstraten te noemen. Maar goed, ik begeef me niet echt in andere kringen dus ik kan weinig zeggen over het gedrag van Rust-supporters daar

Heb wel eens van een Rust fanaticus gehoord dat we alle Java microservices in Rust moesten herschrijven, dus vandaar

[Mugwump]

Hydra schreef op woensdag 17 juli 2019 @ 18:03:
[...]


Heb wel eens van een Rust fanaticus gehoord dat we alle Java microservices in Rust moesten herschrijven, dus vandaar

Vreemde keuze, dat moet natuurlijk Go zijn.

[Matis]

Mugwump schreef op woensdag 17 juli 2019 @ 18:45:
Vreemde keuze, dat moet natuurlijk Go zijn.

Dat was ook mijn eerst gedachte

[.oisyn]

Nee, de taal is niet zo belangrijk. Zolang het maar een filesystem op basis van INI files gebuikt

Ik moest hier op een of andere manier ineens weer aan denken. Een GoT klassieker

[Creepy]

[ThomasG]

Dan rijst de vraag: Heeft Rust native INI ondersteuning?

[diondokter]

Nee, maar er is wel een leuke crate (library) voor: https://github.com/zonyitoo/rust-ini 😎

[sig69]

.oisyn schreef op woensdag 17 juli 2019 @ 18:59:
Nee, de taal is niet zo belangrijk. Zolang het maar een filesystem op basis van INI files gebuikt

Ik moest hier op een of andere manier ineens weer aan denken. Een GoT klassieker

Bedankt hiervoor, ik kende 'm niet.

[Hydra]

Mugwump schreef op woensdag 17 juli 2019 @ 18:45:
Vreemde keuze, dat moet natuurlijk Go zijn.

Grappig genoeg was dat in een project waar 2 andere (ook Opsers, geen devs) continue zaten te emmeren dat we naar Go moesten. Ben aardig getriggered nu

[Gropah]

Maar Go en microservices zijn een match made in heaven. Hoe kun je ze dat ontzeggen?!?!

* Gropah geilt ondertussen lekker door op het werk wat hij Go doet

[Mugwump]

Hydra schreef op donderdag 18 juli 2019 @ 10:46:
[...]


Grappig genoeg was dat in een project waar 2 andere (ook Opsers, geen devs) continue zaten te emmeren dat we naar Go moesten. Ben aardig getriggered nu

Het enige waar ik nu nog voordeel zie is bijvoorbeeld bij AWS Lambda's als cold starts je echt in de weg zitten. Maar ja, hopelijk krijgen we op de niet al te lange termijn wel stabiele implementations van GraalVM runtimes en dan zijn trage cold starts ook verholpen.

[Hydra]

Gropah schreef op donderdag 18 juli 2019 @ 10:55:
Maar Go en microservices zijn een match made in heaven. Hoe kun je ze dat ontzeggen?!?!

Go is een taal ontwikkeld voor debielen beginners voor wie zaken als generics en exceptions te hoog gegrepen zijn. Go is erger dan PHP. PHP heeft tenminste nog het 'lange historie' excuus, Go is een recent ontwikkelde taal die alle recente inzichten volkomen genegeerd heeft "want bij Google weten we het beter". Als PHP, het NPM ecosysteem en Visual Basic een liefdeskindje zouden krijgen zou het minder debiel zijn dan Go.

Maar ontwikkel lekker verder, geef mij maar Kotlin

Mugwump schreef op donderdag 18 juli 2019 @ 11:06:
Het enige waar ik nu nog voordeel zie is bijvoorbeeld bij AWS Lambda's als cold starts je echt in de weg zitten. Maar ja, hopelijk krijgen we op de niet al te lange termijn wel stabiele implementations van GraalVM runtimes en dan zijn trage cold starts ook verholpen.

Cold starts komen sowieso enorm weinig voor; je Java lambda wordt gewoon 'warm' gehouden. En voor performance kritische zaken lambda's gebruiken is sowieso al vrij 'meh', alles draait op vrij grote afstanden van elkaar en al je functies communiceren in de basis via TCP.

Een jaar of 3 geleden was vooral Spring wel vrij traag bij het opstarten (13 seconden ofzo voor een service op m'n laptop = vaak wel 30+ seconden in 't kubernetes cluster), maar daar hebben ze gelukkig flink op doorontwikkeld. Hoe lang een microservice er over doet is, zo lang het maar binnen een minuut ofzo is, sowieso niet zo relevant in bijvoorbeeld een kubernetes cluster omdat upgrades toch rolling gedaan worden.

[ Voor 43% gewijzigd door Hydra op 18-07-2019 16:00 ]

[Mugwump]

Hydra schreef op donderdag 18 juli 2019 @ 15:57:
[...]


Go is een taal ontwikkeld voor debielen beginners voor wie zaken als generics en exceptions te hoog gegrepen zijn. Go is erger dan PHP. PHP heeft tenminste nog het 'lange historie' excuus, Go is een recent ontwikkelde taal die alle recente inzichten volkomen genegeerd heeft "want bij Google weten we het beter". Als PHP, het NPM ecosysteem en Visual Basic een liefdeskindje zouden krijgen zou het minder debiel zijn dan Go.

Maar ontwikkel lekker verder, geef mij maar Kotlin

Ik doe niets met Go hoor, gewoon lekker Java op het moment.

[...]

Cold starts komen sowieso enorm weinig voor; je Java lambda wordt gewoon 'warm' gehouden. En voor performance kritische zaken lambda's gebruiken is sowieso al vrij 'meh', alles draait op vrij grote afstanden van elkaar en al je functies communiceren in de basis via TCP.

Dat ligt er maar net aan hoe je het inricht. Als je lambdas hebt die bijvoorbeeld triggeren op queue inputs of DynamoDb Streams en er is sprake van een tijd zonder / met nauwelijks load en plotselinge piekloads, dan krijg je gewoon veel cold starts. Dat kun je wel afvangen met reserved concurrent executions en bijvoorbeeld trigger events om de boel warm te houden, maar het is wel iets waar je over na moet denken, ook vanuit het oogpunt van kosten.

[Hydra]

Mugwump schreef op donderdag 18 juli 2019 @ 16:27:
Dat ligt er maar net aan hoe je het inricht. Als je lambdas hebt die bijvoorbeeld triggeren op queue inputs of DynamoDb Streams en er is sprake van een tijd zonder / met nauwelijks load en plotselinge piekloads, dan krijg je gewoon veel cold starts. Dat kun je wel afvangen met reserved concurrent executions en bijvoorbeeld trigger events om de boel warm te houden, maar het is wel iets waar je over na moet denken, ook vanuit het oogpunt van kosten.

Dat laatste is zeker waar, maar dat is niet alleen van toepassing op Java. In vrijwel alle gevallen moet er 'ergens' een soort VPS opgestart worden waar je zooi in draait. En dat duurt relatief lang. (als in 1.5 seconden ongeveer).

Ik denk trouwens dat ik je "Gropah geilt ondertussen lekker door op het werk wat hij Go doet" verkeerd geinterpreteerd heb, wat bedoelde je?

[ Voor 8% gewijzigd door Hydra op 18-07-2019 18:00 ]

[Gropah]

Hydra schreef op donderdag 18 juli 2019 @ 17:59:
[...]
Ik denk trouwens dat ik je "Gropah geilt ondertussen lekker door op het werk wat hij Go doet" verkeerd geinterpreteerd heb, wat bedoelde je?

Dat zijn mijn woorden en misschien had ik die opmerking daarboven duidelijker sarcastisch moeten maken.

Betekend niet dat ik niet op je rant van Go wil reageren. Ik vraag me btw af, heb je zelf geprogrammeerd in Go?

Hydra schreef op donderdag 18 juli 2019 @ 15:57:
[...]


Go is een taal ontwikkeld voor debielen beginners voor wie zaken als generics en exceptions te hoog gegrepen zijn. Go is erger dan PHP. PHP heeft tenminste nog het 'lange historie' excuus, Go is een recent ontwikkelde taal die alle recente inzichten volkomen genegeerd heeft "want bij Google weten we het beter". Als PHP, het NPM ecosysteem en Visual Basic een liefdeskindje zouden krijgen zou het minder debiel zijn dan Go.

Maar ontwikkel lekker verder, geef mij maar Kotlin


[...]

Generics komen er aan met versie 2, en is expres ver naar achteren geschoven omdat ze vanuit verschillende taalmakers mee hadden gekregen: "als het er eenmaal in zit kom je er niet meer van af en het is verdomde moeilijk om goed te doen". Hoewel dit nooit expliciet naar buiten is gecommuniceerd (volgens mij) waardoor velen dachten (en terecht) dat het er nooit in zou komen.

Verder moet ik eerlijk zeggen dat ik generics niet echt mis, en waar ik het nodig zou hebben, heb ik met het gebruik van interfaces hetzelfde kunnen doen. Het enige waarvoor ik mij echt kan voorstellen dat het noodzakelijk is om het te gebruiken is voor containers (denk queues, lists, rings, etc) maar gelukkig heeft go daar al een hele hoop van aangeleverd

Exceptions zitten er niet in, maar error handling willen ze met versie 2 wel beter maken (en gelukkig is het eerste voorstel voor grote overhaul compleet afgeschoten, want dat was imo niet veel soeps).

Ja, het is gemaakt door Google voor hun medewerkers. Maar Google geilt op PhDs en ze hebben er een overschot aan. Het zijn qua werkervaring starters, maar echt geen domme mensen. Om het erger te benoemen dan PHP, qua reputatie gaat dat ver en ik heb geen ervaring met PHP, maar het mooie aan Go vind ik naast de snelheid, de makkelijkheid van spul parallel draaien vooral de consistentie. Spul werkt zoals je verwacht dat het werkt.

De reden dat wij het zijn gaan gebruiken is dat we snelheid en schaalbaarheid nodig hebben. Er werd op een gegeven moment C(++) overwogen, maar we vertrouwden ons zelf niet genoeg om dat consistent op hoge standaard te ontwikkelen. Maar vanuit daar zijn we gaan kijken welke talen nog meer snel waren, hoe die in de markt liggen, waar ze voor gebruikt worden etc. Daar is uiteindelijk Go uitgekomen omdat we het wel lekker vonden werken en voor REST APIs bijna alles standaard ingebouwd heeft.

Maar je moet vooral pakken wat past voor je context. Als je op microservices zit, dan is het het overwegen zeker waard imo, maar als je al wat hebt staan en dat moet worden uitgebreid dan ben je wel gek als je dat doet.

[Creepy]

Met alle respect natuurlijk, maar schaalbaarheid en snelheid zijn op meer manieren te bereiken dan alleen met Go he
Dat je met Go wat wilt proberen en ervaren, prima. Maar was je zo CPU bound met je bestaande zaken dat een overstap naar Go echt winst oplevert? En zo ja, dan ben ik wel benieuwd naar de stats..

[ Voor 9% gewijzigd door Creepy op 18-07-2019 18:52 ]

[Gropah]

Creepy schreef op donderdag 18 juli 2019 @ 18:52:
Met alle respect natuurlijk, maar schaalbaarheid en snelheid zijn op meer manieren te bereiken dan alleen met Go he
Dat je met Go wat wilt proberen en ervaren, prima. Maar was je zo CPU bound met je bestaande zaken dat een overstap naar Go echt winst oplevert? En zo ja, dan ben ik wel benieuwd naar de stats..

We doen nogal wat met asymmetrische encryptie. Precieze getallen kan ik niet geven omdat ik die niet (meer) weet, maar ik weet nog wel de resultaten van de eerste tests. We hebben een deel van ons product herschreven in Go, wat redelijk overeen kwam met gemiddelde load. Daarbij zagen we dat de latencies bij 5k concurrent requests ongeveer 1/5e waren van wat er al stond in C# op de 50% snelheid requests en dat gat alleen maar groter werd bij de hogere percentages. En dat voor iets wat door 1 persoon in elkaar was gezet die totaal geen ervaring had met Go. Toen waren we wel redelijk rap om. En ik moet eerlijk zeggen, ik vind het een erg leuke taal om in te werken.

[Mugwump]

Hydra schreef op donderdag 18 juli 2019 @ 17:59:
[...]


Dat laatste is zeker waar, maar dat is niet alleen van toepassing op Java. In vrijwel alle gevallen moet er 'ergens' een soort VPS opgestart worden waar je zooi in draait. En dat duurt relatief lang. (als in 1.5 seconden ongeveer).

Ja dat klopt, maar Java is op de reguliere JVM wel een stuk trager dan Node / Python / Go als het op cold starts aankomt. Helpt ook niet dat nog enkel Java 8 wordt ondersteund. De modulariteit uit Java 9+ biedt ook al de mogelijkheid om de omvang fors te verkleinen.
Wat je wel weer ziet is dat Java een stuk harder gaat dan bv node en python als de boel eenmaal is opgewarmd.

[RagingPenguin]

Gropah schreef op donderdag 18 juli 2019 @ 18:29:
Generics komen er aan met versie 2, en is expres ver naar achteren geschoven omdat ze vanuit verschillende taalmakers mee hadden gekregen: "als het er eenmaal in zit kom je er niet meer van af en het is verdomde moeilijk om goed te doen". Hoewel dit nooit expliciet naar buiten is gecommuniceerd (volgens mij) waardoor velen dachten (en terecht) dat het er nooit in zou komen.

Ik ben nu al ongeveer een half jaar bezig om in mijn vrije tijd een programmeertaal te schrijven en ik kan dit helemaal beamen. Generics zijn een hel om te implementeren. Opeens heb je lexial scoped types en worden functiecalls typechecken veel complexer omdat je eerst al je generics moet resolven voordat je weet wat er aan parameters word verwacht en wat je return type is. O ja, om het echt handig te maken moet je ook nog een goed systeem hebben voor het leggen van restricties op generic types (in mijn taal kan je elke type opgeven als een restrictie).

Voor de geïnteresseerde, dit is wat voorbeeld code:

code:

let compose = <a,b,c> (f :: a -> b) -> (g :: b -> c) -> (a :: a) -> g(f(a))
let add1 = (i :: int) -> i + 1
let times2 = (i :: int) -> i * 2
echo compose<int, int, int>(add1)(times2)(1)

let fst = <a> (a :: a[]) -> a.[0]
echo fst<string>(string [ "h", "e" ])

let fx = <a> (a :: { x: a }) -> a.x
let x :: int = fx<int>({x: 2, y : false})
echo x

type User = {
  Id: int
  Name: string
}

let readID = <a :: { Id :: int}> (a :: a) -> a.Id
echo readID<User>({Id: 1, Name: "Dave"})

type data <a> = { value: a }
let d :: data<<string>> = { value: "hi" }
let df = <a>(d :: data<<a>>) -> d.value
echo df<string>(d)

Aan de andere kant: ik ben maar een persoon, in z'n vrije tijd en een achtergrond als webdeveloper. Als ik het kan zou Google het toch ook zo moeten kunnen? ...

Gropah schreef op donderdag 18 juli 2019 @ 18:29:
Verder moet ik eerlijk zeggen dat ik generics niet echt mis, en waar ik het nodig zou hebben, heb ik met het gebruik van interfaces hetzelfde kunnen doen. Het enige waarvoor ik mij echt kan voorstellen dat het noodzakelijk is om het te gebruiken is voor containers (denk queues, lists, rings, etc) maar gelukkig heeft go daar al een hele hoop van aangeleverd

Ik zou het echt een drama vinden. Maak je echt nooit dingen als functors, monands en custom data structures? Als ik mijn eigen code zie dan zijn eroveral generics.

[ Voor 3% gewijzigd door RagingPenguin op 18-07-2019 19:09 ]

[BarôZZa]

F.West98 schreef op maandag 15 juli 2019 @ 02:54:
[...]

Dit is dus exact waarom ik (vooralsnog) een hekel heb aan PWA en aanverwanten. Ze proberen native na te doen, maar het is het net niet en dat is echt enorm irritant. Laggy scrolling, random missende touchanimaties, vertragingen na een druk op de knop, menuteksten die niet de system text size settings volgen (in Android kan je de letters systemwide kleiner zetten, praktisch alle apps luisteren daar naar), animaties die net niet overeenkomen met native, etc. En op desktop zijn de lettertypes vreemd..?

Tuurlijk, de meer volledige demo's zijn best impressive, en sommige animaties zien er erg goed uit. Maar dan klik je een dropdown aan en dan heb je ineens enorme lag en vertraging. De fuck? Dus ja, zorg eerst dat die basis gefixt is voordat dit soort dingen als de oplossing voor alles gepresenteerd worden.

Bij een goede PWA heb je in mijn ogen niet eens door dat het een PWA is, en daarmee bedoel ik dat het gewoon aanvoelt als een website(zeker op desktop). Een paar jaar geleden had ik een demo gemaakt van hoe een webshop bijvoorbeeld als progressive web app kan werken. Deze demo draaide op mijn webserver, dus dit was precies zoals het in de praktijk werkte. De PWA zorgde ervoor dat de volgende pagina's al gerenderd werden, de images voor de fold werden ingeladen etc zodat je geen laadtijden had als je naar een andere pagina ging.

Ik was nog wel redelijk enthousiast met de transitions destijds , maar dat was wel met een doel: namelijk dat als je terug ging naar de catalog, je meteen zag waar je was gebleven. Die konden ook makkelijk uitgeschakeld worden, al vond ik ze leuk voor de demo en het ziet r drukker uit omdat ik heel snel door de site klik. Als je ze uitschakelt ziet het eruit als een normale website, maar dan zonder laadtijden en pagina's die zichtbaar opbouwen. Alles runde trouwens in 60fps en zelfs smooth op een antieke Moto G uit 2013. Volledige page transition van rechts naar links scrollen zijn imo wel nutteloos, die maken het juist langzamer en worden inderdaad laggy.

Helaas geen tijd meer gehad om het veel verder uit te werken, maar open een willekeurige grote webshop en je zal zien dat het nog steeds retesnel is(bij de meeste webshops duurt het een paar seconde voordat de volgende pagina is ingeladen). Mijn gedachte was dat als het browsen door producten makkelijker/sneller gaat dat mensen dan meer pagina's bekijken en je een grotere kans hebt dat ze iets kopen. En daar zijn PWA technieken ideaal voor.

Krampachtig een mobile app in de browser nabouwen heb ik nooit echt begrepen, een goede PWA combineert imo juist het beste van beide werelden: de duidelijke navigatie van websites met pagina's en de snelheid van native apps. Je hoeft niet ineens de navigatie om te gooien en elke scheet te animeren.

[Hydra]

Gropah schreef op donderdag 18 juli 2019 @ 18:29:

Betekend niet dat ik niet op je rant van Go wil reageren. Ik vraag me btw af, heb je zelf geprogrammeerd in Go?

Bring it on!

Ja, vrij veel ook. Ik werd aangetrokken tot Go omdat het naar een enkele static compiled binary compiled, en je er toch vrij simpel een REST API mee kunt maken. Ik ben redelijk Raspberry Pi fan, en vooral een jaar of 5 geleden was bijvoorbeeld Spring Boot (waar ik dagelijks mee werk) op een raspberry vrij 'meh'. Ik heb redleijk veel commandline tools en een paar REST services gemaakt.

Dit geldt over het algemeen voor meer dingen waar ik sterk tegen ageer, zoals Node.js, NPM en Blockchain. Zaken waar er redelijk veel 'hype' is, maar waar als je dieper graaft eigenlijk alleen maar een beerput vindt met daaronder een nog grotere beerput.

Generics komen er aan met versie 2, en is expres ver naar achteren geschoven omdat ze vanuit verschillende taalmakers mee hadden gekregen: "als het er eenmaal in zit kom je er niet meer van af en het is verdomde moeilijk om goed te doen". Hoewel dit nooit expliciet naar buiten is gecommuniceerd (volgens mij) waardoor velen dachten (en terecht) dat het er nooit in zou komen.

Je hebt een deel goed. Generics zitten er niet in omdat het moeilijk is. Punt. Dit geldt ook voor andere zaken: interfaces zitten er niet in omdat het moeilijk is, in plaats daarvan heb je duck-typing. Method overloads zitten er niet in, in plaats daarvan moet je maar gewoon methodes met andere namen maken.

Een van mijn voornaamste kritieken is, is dat heel veel van de zogenaamde 'voordelen' van Go gewoon excuses zijn om niet de dingen te implementeren die een moderne taal gewoon nodig hebben. Go is door dit soort gebreken meer verbose dan zelfs Java, zonder alle voordelen van Java.

Op dit moment is letterlijk het enige voordeel van Go die static compilation. Maar op dat vlak zijn zowel Java als C# hard een inhaalslag aan het doen. Over een paar jaar is Go volledig irrelevant.

Verder moet ik eerlijk zeggen dat ik generics niet echt mis, en waar ik het nodig zou hebben, heb ik met het gebruik van interfaces hetzelfde kunnen doen. Het enige waarvoor ik mij echt kan voorstellen dat het noodzakelijk is om het te gebruiken is voor containers (denk queues, lists, rings, etc) maar gelukkig heeft go daar al een hele hoop van aangeleverd

Ik kan met niet voorstellen dat je ooit iets substantieels in Go gebouwd hebt en generics niet mist. Je bent in Go continue shit aan het copy-pasten terwijl het makkelijk met generics op te lossen is. Nota bene; Go heeft intern voor de API's wel een soort van generics omdat de Go bouwers het copy-pasten zat waren. Dit is alleen niet exposed.

Dit lijdt er toe dat de meeste Go codebases vervuild worden met een vorm van meta-programming. Mensen gaan dus zelf een soort generics / templates maken.

Exceptions zitten er niet in, maar error handling willen ze met versie 2 wel beter maken (en gelukkig is het eerste voorstel voor grote overhaul compleet afgeschoten, want dat was imo niet veel soeps).

Ze zijn in de afgelopen paar jaar van "generics en exceptions zijn de duivel" naar "okay okay jullie hebben gelijk het is ruk dat het er niet inzit" gegaan ja. Euh. Bravo? Je geeft dus toe dat je als language designer een fucking idioot bent. Nou; top! Misschien excuses maken voor de belachelijk arrogante houding en alle schade die je hebt gedaan bij al die junior developers die nog steeds dat "exceptions zijn evil" lopen na te kletsen zonder te snappen wat de alternatieven zijn?

Het beste alternatief voor exceptions zijn Try monads. Afgezien daarvan zijn exceptions zoals ongeveer elke moderne taal die heeft extreem veel beter dan domweg in iedere laag in je service een error te moeten checken.

Wat je in reality ziet in Go codebases is meestal ongeveer dit:

val _, result = someMethod('42')

(maar dan in Go, can't be arsed de echte syntax op te zoeken). Wat doet bovenstaande? Gewoon de error negeren. Dat dit uberhaupt kan in een moderne taal is te bizar voor woorden. Er worden hordes en hordes beginners hele HELE slechte habits aangeleerd. En dat irriteert me het meest; dat een bedrijf als Google nota bene dit accepteert.

Ik krijg sterk het gevoel dat Google het wel best vindt, omdat mensen dan moeilijk aan een andere baan waarin je met echte programmeertalen werkt

Ja, het is gemaakt door Google voor hun medewerkers. Maar Google geilt op PhDs en ze hebben er een overschot aan. Het zijn qua werkervaring starters, maar echt geen domme mensen. Om het erger te benoemen dan PHP, qua reputatie gaat dat ver en ik heb geen ervaring met PHP, maar het mooie aan Go vind ik naast de snelheid, de makkelijkheid van spul parallel draaien vooral de consistentie. Spul werkt zoals je verwacht dat het werkt.

Go is niet 'makkelijker' kwa concurrency dan andere talen. Dat het een language construct is, betekent niet dat je er geen enorm lastige fuck-ups mee kunt maken. Concurrency is lastig omdat onze hersenen die processen niet goed snappen. De oplossing is message passing; da's zo oud als het maar zijn kan. Sterker nog; het is een van de basisconcepten van 'echt' OOP.

De reden dat wij het zijn gaan gebruiken is dat we snelheid en schaalbaarheid nodig hebben. Er werd op een gegeven moment C(++) overwogen, maar we vertrouwden ons zelf niet genoeg om dat consistent op hoge standaard te ontwikkelen. Maar vanuit daar zijn we gaan kijken welke talen nog meer snel waren, hoe die in de markt liggen, waar ze voor gebruikt worden etc. Daar is uiteindelijk Go uitgekomen omdat we het wel lekker vonden werken en voor REST APIs bijna alles standaard ingebouwd heeft.

Ik snap niet dat je voor "snelheid en schaalbaarheid" op Go uitkomt. Het is niet sneller dan bijvoorbeeld Java. Het komt, zoals Java, niet in de buurt van C++ / Rust. Als je een of andere trade-engine aan het bouwen bent waar microseconden belangrijk zijn, dan komt je niet op Java of Go uit. Als dat minder belangrijk is, is onderhoudbaarheid van de software een sterkere overweging. En dan is er nul reden om voor Go te gaan.

Kan nog wel doorgaan over hoe brak het ecosysteem is (dependency management? fuck it, we trekken de master wel van github!) en dergelijke, maar deze rant is al lang genoeg.

Go is voornamelijk geschreven door een arrogante randdebiel die denkt dat 'ie het beter weet dan ongeveer de hele historie aan computer scientists, er halverwege achterkwam dat een echte moderne taal bouwen best lastig is, en omdat 'ie er geen zin meer in had toen maar z'n invloed in het bedrijf is aan gaan wenden om het als "beginners taal" neer te zetten, ongeacht van alle schade deze beginners aangedaan wordt.

PHP is een ongelukje. Als jij iemand per ongeluk aanrijdt vind ik je een lul. Als jij opzettelijk iemand aanrijdt omdat je alle regels e.d. negeert want 'je weet het beter' dan ben je een crimineel. Go is crimineel slecht.

Creepy schreef op donderdag 18 juli 2019 @ 18:52:
Dat je met Go wat wilt proberen en ervaren, prima. Maar was je zo CPU bound met je bestaande zaken dat een overstap naar Go echt winst oplevert? En zo ja, dan ben ik wel benieuwd naar de stats..

Go is een memory managed taal zoals C# en Java en loopt tegen exact dezelfde limieten aan. Go is dan ook absoluut niet sneller dan Java. En komt niet in de buurt van C++ / Rust.

Als je van C# naar Go gaat en een 500% snelheidswinst behaalt dan doet die Go implementatie gewoon niet hetzelfde als de C# implementatie.

[ Voor 4% gewijzigd door Hydra op 19-07-2019 10:12 ]

[.oisyn]

Hydra schreef op vrijdag 19 juli 2019 @ 10:09:
Als je een of andere trade-engine aan het bouwen bent waar microseconden belangrijk zijn, dan komt je niet op Java [of Go] uit.

GRmmmblluch #% kuch &#@$% proest. Sorry, schoot even een stukje boterham in mijn verkeerde keelgat. Ik heb er twee gereviewd voor een crypto exchange. Beiden waren geschreven in Java... En ik weet dat er ook een paar actief zijn die PHP gebruiken. Bij Cryptsy (bestaat niet meer) kon het orderboek weleens een half uur achterlopen op de trades. Fucking retards zijn het.

[gekkie]

Hydra schreef op vrijdag 19 juli 2019 @ 10:09:
[...]
Bring it on!
[...][...][...][...][...]

tis de koffiecornert, denk aan je rust en neem even lekker een bakkie gemalen java boontjes .

[Hydra]

.oisyn schreef op vrijdag 19 juli 2019 @ 10:59:
GRmmmblluch #% kuch &#@$% proest. Sorry, schoot even een stukje boterham in mijn verkeerde keelgat. Ik heb er twee gereviewd voor een crypto exchange. Beiden waren geschreven in Java... En ik weet dat er ook een paar actief zijn die PHP gebruiken. Bij Cryptsy (bestaat niet meer) kon het orderboek weleens een half uur achterlopen op de trades. Fucking retards zijn het.

Klinkt eerder gezegd eerder als een stel idioten die niks van software architectuur en/of informatica snappen (wat wel overeenkomt met de gemiddelde blockchain developer) dan dat het de 'schuld' van Java is. Netflix bijvoorbeeld draait vrijwel volledig op Java en die verstouwen best wat data

Iets in C++ herschrijven heeft weinig zin als je concurrency niet snapt, of het verschil tussen O(log n) en O(n2) niet snapt.

gekkie schreef op vrijdag 19 juli 2019 @ 11:01:
tis de koffiecornert, denk aan je rust en neem even lekker een bakkie gemalen java boontjes .

Go voor it zeg ik, een beetje Rust nemen tijdens je bakkie Java is belangrijk. Zolang je wel Scherp blijft Zien

[ Voor 15% gewijzigd door Hydra op 19-07-2019 11:03 ]

[.oisyn]

@Hydra Ik zei niet dat het de schuld is van Java, ik zei dat het idioten waren die, zoals je zelf zei en wat ik beaam, beter niet voor Java hadden kunnen kiezen. Of kom je nu terug van die stelling?

(En het zijn geen idioten omdat ze voor Java hebben gekozen, ze hebben voor Java gekozen omdat het idioten zijn)

[ Voor 38% gewijzigd door .oisyn op 19-07-2019 11:27 ]

[Hydra]

.oisyn schreef op vrijdag 19 juli 2019 @ 11:10:
@Hydra Ik zei niet dat het de schuld is van Java, ik zei dat het idioten waren die, zoals je zelf zei en wat ik beaam, beter niet voor Java hadden kunnen kiezen. Of kom je nu terug van die stelling?

Ik volg je niet helemaal. Ik geloof dat wat jij schetst weinig te maken heeft met de keuze al dan niet voor Java. Java is, voor wat jij aangeeft, niet per definitie een slechte keuze. Ik gaf al aan dat als het echt om microseconden gaat, het IMHO al snel wel een slechte keuze is, maar ik ben er niet van overtuigd dat dat daar een issue was, maar da's vooral omdat ik het systeem niet ken. Jij hebt het gereviewed; als jij overtuigd bent dat C++ daar een betere keuze is dan Java, dan ben ik geneigd je gewoon te geloven. Ik kan hoe dan ook vanuit mijn positie, nul kennis van het systeem, hoe dan ook niet beweren dat jij er naast zit.

TL;DR: ik ben 't gewoon met je eens

[armageddon_2k1]

Als je het over de duvel hebt. Rust keuze in de US gov:
https://www.reddit.com/r/...nancial_services_hearing/

Best onder de indruk van de technische kennis in de committee.

[ThomasG]

armageddon_2k1 schreef op vrijdag 19 juli 2019 @ 12:34:
Als je het over de duvel hebt. Rust keuze in de US gov:
https://www.reddit.com/r/...nancial_services_hearing/

Best onder de indruk van de technische kennis in de committee.

quote: https://riggleman.house.gov/about

Denver (Riggleman) has also been CEO of several defense contracting companies specializing in counterterrorism, analytic services, rapid technology development, critical infrastructure studies, C4ISR, cyber processes and support to “follow the money” organizations.

Hij weet er dus wel wat vanaf; of in ieder geval welke vragen hij moet stellen. En dat is zoals het zou moeten. Commissieleden met verstand van zaken.

[ Voor 4% gewijzigd door ThomasG op 19-07-2019 13:29 ]

[Hydra]

Ik moet ook echt eens aan de Rust. Afgelopen winter geprobeerd voor Advent of Code maar toen, omdat die borrow-checker me teveel in de weg zat, toch maar in Kotlin gedaan. Zit me nog steeds dwars dat ik die niet 'snap' (en de syntax helpt ook niet echt mee).

Of anders misschien toch maar gewoon good old C++; heb er sinds 2003 ofzo niks mee gedaan en het schijnt tegenwoordig best een stuk verbeterd te zijn. Zoveel keuzes, zo weinig tijd. Loop al eeuwen met het idee in m'n hoofd een simpel 2D spelletje te maken met SFML ofzo.

[BladeSlayer1000]

Vandaag te horen gekregen dat na 1,5 maand eindelijk de airco op het werk weer functioneerd

[Hydra]

BladeSlayer1000 schreef op vrijdag 19 juli 2019 @ 17:46:
Vandaag te horen gekregen dat na 1,5 maand eindelijk de airco op het werk weer functioneerd

Net op tijd

[farlane]

t

[.oisyn]

t?

p!

[farlane]

functioneerp?

[Douweegbertje]

Hier nog een Go gebruiker. De use-case is bij mij eigenlijk anders. Java, C++ en C# zijn voor mij niet zo interessant voor het werk wat ik moet doen. Ik zie Go meer een tegenhanger van iets als Python (al dan niet nog steeds andere use-cases).
Met Go kan ik fatsoenlijker scripts, applicaties, etc. maken die vooral de wat 'devops' gerelateerde taakjes kunnen afvangen.

Daarbij gebruik ik intensief Kubernetes en dan.. tja gebruik je Go voor de custom meuk daarin.

O.a. de reden dat ik het niet helemaal eens ben met het statement van @Hydra :

Over een paar jaar is Go volledig irrelevant.

Ik zal eerlijk toegeven dat ik een te slechte programmeur ben om inhoudelijk op de rant in te gaan. Echter zie ik zelf Java, C# never te nimmer in vele niches terug. Ligt dat dan aan te veel 'retards' die met Go of whatever bezig zijn, of dat je de beste taal voor je probleem zoekt?

Honestly heeft Go wel degelijk een gat opgevuld tussen de Java/C# en Python/bash talen.

[Hydra]

Douweegbertje schreef op maandag 22 juli 2019 @ 10:46:
Ik zal eerlijk toegeven dat ik een te slechte programmeur ben om inhoudelijk op de rant in te gaan. Echter zie ik zelf Java, C# never te nimmer in vele niches terug. Ligt dat dan aan te veel 'retards' die met Go of whatever bezig zijn, of dat je de beste taal voor je probleem zoekt?

Wat bedoel je met niches? Java is, ook in Nederland, een van de meest gebruikte talen in de 'back-end' bij grote bedrijven.

Afgezien daarvan; ik redeneer vanuit 't werk dat ik meestal doe, en dat zijn best complexe services met veel laagjes die met veel andere dingen praten. Alhoewel ik Go een kuttaal vindt; als ik een command line 'ding' moet maken dat ik statisch wil kunnen compilen naar een executable zou ik daar waarschijnlijk nu ook nog op uit komen.

Dat of Kotlin native, dat begint ook wel erg goed / gemakkelijk te worden. Nadeel is dat je daar lang niet alle libraries kunt gebruiken.

[Kalentum]

Douweegbertje schreef op maandag 22 juli 2019 @ 10:46:
Honestly heeft Go wel degelijk een gat opgevuld tussen de Java/C# en Python/bash talen.

In welk opzicht? Voor wat voor taken zet je Go in en niet bv Python?

Oprecht geïnteresseerd, bij ons op het werk wordt ook her en der Go ingezet maar ik kan maar niet achterhalen waarom...

[ThomasG]

rutgerw schreef op maandag 22 juli 2019 @ 10:59:
[...]


In welk opzicht? Voor wat voor taken zet je Go in en niet bv Python?

Oprecht geïnteresseerd, bij ons op het werk wordt ook her en der Go ingezet maar ik kan maar niet achterhalen waarom...

Go is ontwikkeld voor net afgestudeerde Google werknemers die niet kunnen programmeren

[Mugwump]

ThomasG schreef op maandag 22 juli 2019 @ 11:16:
[...]
GoPython is ontwikkeld voor net afgestudeerde Google werknemers die niet kunnen programmeren

[Hydra]

rutgerw schreef op maandag 22 juli 2019 @ 10:59:
Oprecht geïnteresseerd, bij ons op het werk wordt ook her en der Go ingezet maar ik kan maar niet achterhalen waarom...

Vooral omdat mensen het graag willen. Da's een beetje een nadeel van ons vakgebied. Ik merk dat er erg vaak naar bepaalde talen/frameworks/libraries toe geredeneerd wordt simpelweg omdat mensen er graag eens gebruik van willen maken maar dat niet in hun eigen tijd willen doen. Natuurlijk wil je innovatie niet in de weg staan, maar er zijn wel erg veel developers die de kosten van een dergelijke switch of niet zien, of wie het gewoon niet interesseert. Dat er dan een enorm gedrocht staat in "insert-taal-X" dat niemand dan meer wil onderhouden nadat die developer een paar maanden later weg is, is dan niet 'zijn probleem'.

De meeste innovaties zijn oude wijn in nieuwe zakken. Het kan best nut hebben daar gebruik van te maken. Maar aan alles zijn kosten verbonden.

ThomasG schreef op maandag 22 juli 2019 @ 11:16:
Go is ontwikkeld voor net afgestudeerde Google werknemers die niet kunnen programmeren

Go is ontwikkeld door iemand die zich verveelde en z'n invloed binnen Google aangewend heeft om, in plaats van z'n manager uit te moeten leggen dat hij heeft zitten hobbyen in de baas z'n tijd, z'n manager buitenspel gezet heeft en een eigen koningkrijkje gebouwd heeft waarin hij heer en meester is. Wel slim van hem, moet ik 'em nageven, maar het is een bizarre verspilling van tijd en geld.

Geef een dev onbeperkt tijd en geld en uiteindelijk komt 'ie uit op 't bouwen van een eigen programmeertaal.

Ik weet dat ik hierboven een beetje chargeer overigens.

[ Voor 28% gewijzigd door Hydra op 22-07-2019 11:30 ]

[Gropah]

Hydra schreef op vrijdag 19 juli 2019 @ 10:09:
[...]


Bring it on!

Sorry voor de trage reactie, druk weekend en ik wou hier even de tijd voor nemen. Uit je posts maak ik op dat je in de java wereld zit, gezien ik daar ook enigzins bekend ben zal ik wellicht af en toe naar java grijpen voor voorbeelden.

Overigens, ik ga echt niet zeggen dat Go het walhalla is. Ik vind het wel leuk werken, maar er zijn ook zeker dingen die ik mis of raar vind. Maar ik kan me niet vinden in wat je reageerde en zeker niet met die stelligheid en de rants die er tussendoor zitten.

Anyways: leesze

[...]


Je hebt een deel goed. Generics zitten er niet in omdat het moeilijk is. Punt.

Een beetje verkloot de quote, maar ok. Generics ansich zijn niet moeilijk te implementeren voor de programmeur afhankelijk van de implementatie. Java doet het redelijk, maar met erg veel boilerplate en documentatie rondom generics is moeilijker te lezen.

Java:

default <U extends Comparable<? super U>> Comparator<T>     thenComparing(Function<? super T,? extends U> keyExtractor)

leest toch gewoon minder makkelijk.

Waar ik op doelde is dat het implementeren van generics in een taal niet makkelijk is, zoals ook omschreven in deze blog en word er ook expliciet vergeleken tussen talen.

De community heeft ondertussen wel verschillende projecten lopen om generics te introduceren met behulp van code generation, maar dat zit niet in de taal zelf. Mocht je het echt nodig hebben dan kun je het dus wel gebruiken, maar het ontwikkelteam van go heeft nog geen manier gevonden om generics te implementeren op een manier die binnen go als taal goed valt, en daar heb ik wel respect voor. Voordat je het weet is je taal inconsistent zoals PHP.

Dit geldt ook voor andere zaken: interfaces zitten er niet in omdat het moeilijk is, in plaats daarvan heb je duck-typing.

Python kent geen enkele vorm van interfaces. Daar is duck-typing de standaard. Er zijn wel defaults, conventions of protocollen (hoe je ze maar wil noemen) zoals __len__ en daar hoor ik nauwelijks gezeur over. Ik ga niet zeggen dat duck typing de beste manier is om het op te lossen, maar het heeft ook een groot voordeel. Via interfaces en composition kan je namelijk heel makkelijk libraries hergebruiken mits deze functies werken op interfaces. En doordat het statically typed is krijg je gewoon compile time errors ipv runtime errors zoals bij python als je het fout doet. Daarnaast kun je met de goede tools (zoals GoLand van jetbrains) heel makkelijk checken aan welke interfaces je voldoet en stubs genereren voor het voldoen aan een interface.

Method overloads zitten er niet in, in plaats daarvan moet je maar gewoon methodes met andere namen maken.

Eensch, hier ben ik ook regelmatig tegen aan gelopen. Als je wilt kun je nog wat proberen op te lossen met een variadic parameter, maar dat vind ik persoonlijk wel een beetje een code smell, zeker als je vervolgens type assertion of reflection gaat doen, alhoewel dat waarschijnlijk voor een groot deel mijn opleiding is waar dat echt not done was en mijn achtergrond in java waar dat eigenlijk niet nodig hoeft te zijn.

Een van mijn voornaamste kritieken is, is dat heel veel van de zogenaamde 'voordelen' van Go gewoon excuses zijn om niet de dingen te implementeren die een moderne taal gewoon nodig hebben.

Je kunt het een excuus noemen, en soms mis ik ook dingen, maar met de hoeveelheid tijd en aandacht die ze in de ontwikkeling van de taal stoppen, waardoor het erg consistent is, vind ik bewonderenswaardig en door public te gaan krijgen ze feedback over hun ideeen, waardoor het wel verbeterd. Zoals dat laatst de try exception handling concept is afgeschoten. Als ze hun ivoren toren dit hadden bedacht en geimplementeerd voordat ze public zouden zijn gegaan was de taal waarschijnlijk minder goed geweest.

[...]


Ik kan met niet voorstellen dat je ooit iets substantieels in Go gebouwd hebt en generics niet mist.Je bent in Go continue shit aan het copy-pasten terwijl het makkelijk met generics op te lossen is.

Het copy paste werk valt bij mij erg mee. De reden dat het gebeurd op mijn werk is omdat we go modules nog niet helemaal goed omarmt hebben. We moesten snel wat afkrijgen en daarom is er voor nu gekozen voor copy paste werk, maar die code gaat binnenkort in een eigen repo leven en is dan gewoon te importeren en gebruiken zonder problemen. Hierbij gaat het om database en rabbitMQ spul, wat config en wat auth. Verder zie ik wel wat code duplication in error handling, maar daar zijn we ook naar aan het kijken. Maar voor de rest ben ik nog niet echt tegen copy pasting of problemen vanwege het ontbreken van generics aangelopen. Het enige wat ik echt heb gemist is method overloading. Om wat context te geven: het gaat om een micro service architectuur voor REST api met postgres, rabbitmq, redis en wat encryptie spul

Dit lijdt er toe dat de meeste Go codebases vervuild worden met een vorm van meta-programming. Mensen gaan dus zelf een soort generics / templates maken.

Heb ik eerder al benoemd, voor nu vind ik het inderdaad ook niet netjes, maar wanneer het nodig is kun je het al gebruiken. Maar zoals ik ook al eerder aangaf, ik heb tot nu toe nog niet dit probleem gehad.

Ze zijn in de afgelopen paar jaar van "generics en exceptions zijn de duivel" naar "okay okay jullie hebben gelijk het is ruk dat het er niet inzit" gegaan ja. Euh. Bravo? Je geeft dus toe dat je als language designer een fucking idioot bent. Nou; top!

Je kunt het idioot noemen, maar zoals de blog die talen vergelijkt laat zien dat genoeg talen generics niet in hun eerste versies heeft zitten. Swift wat voornamelijk van het door sommige developers aanbeden apple komt heeft het ook pas 2 jaar.

Misschien excuses maken voor de belachelijk arrogante houding en alle schade die je hebt gedaan bij al die junior developers die nog steeds dat "exceptions zijn evil" lopen na te kletsen zonder te snappen wat de alternatieven zijn?

Het beste alternatief voor exceptions zijn Try monads. Afgezien daarvan zijn exceptions zoals ongeveer elke moderne taal die heeft extreem veel beter dan domweg in iedere laag in je service een error te moeten checken.

Kun je mij een goed voorbeeld geven waarbij een exception in een functie of methode niet tot meer problemen leid in de functies of methode die hem aanroepen?

AFAIK word dan ook vaak genoeg null gereturned, of gebeurd er gewoon iets niet. Ik ben het met je eens dat het wat snel stapelt, maar het voordeel is wel dat je expliciet gaat nadenken over hoe met fouten om te gaan op verschillende niveaus en voor verschillende soorten fouten. Van er komt onverwachtte data binnen van de queue tot oh de verbinding is stuk.

Wat je in reality ziet in Go codebases is meestal ongeveer dit:

val _, result = someMethod('42')

(maar dan in Go, can't be arsed de echte syntax op te zoeken). Wat doet bovenstaande? Gewoon de error negeren. Dat dit uberhaupt kan in een moderne taal is te bizar voor woorden. Er worden hordes en hordes beginners hele HELE slechte habits aangeleerd. En dat irriteert me het meest; dat een bedrijf als Google nota bene dit accepteert.

Dat het mogelijk is om af en toe een parameter te skippen, is af en toe heel handig. Een klein voorbeeld:

Go:

    arr := []string{"hello", "wereld"}
    for _, v := range arr {
        fmt.Println(v)
    }

Dat mensen dat vervolgens gebruiken om errors te negeren is jammer, maar onontkombaar. Er zijn ook genoeg mensen die in java niets met de exceptions doen, zelfs niet het printen van de stacktrace. Dit zijn dan ook dingen die je kunt opvangen met style guides. Zo komt er bij ons op het werk geen code in de belangrijke branches van de repo die dit doen. PoCs doen het af en toe, maar die zitten in aparte branches en zullen nooit in staging of productie gaan.

Ik krijg sterk het gevoel dat Google het wel best vindt, omdat mensen dan moeilijk aan een andere baan waarin je met echte programmeertalen werkt

Ik vind het jammer dat je Go afdoet als geen echte programmeertaal en dat doet wat mij betreft ook af aan je verhaal.

edit: ik was al op zoek geweest naar deze bron maar kon hem niet vinden. Nu alsnog gevonden. Het blijkt uit onderzoek van TripleByte (een recruiter en sollicitatieafname bedrijf) dat Go developers een hoge pass rate hebben. Het gaat hierbij om gebruik van taal tijdens het interview, maar ze geven niet vrij of het ook om een baan voor go gaat, op wat voor niveau en of er andere dingen zijn die meewegen. N=1 en zo, maar om zo maar te zeggen dat Go geen echte programmeertaal is, of dat alleen het alleen voor juniors is? Sorry, maar nee.

Go is niet 'makkelijker' kwa concurrency dan andere talen. Dat het een language construct is, betekent niet dat je er geen enorm lastige fuck-ups mee kunt maken. Concurrency is lastig omdat onze hersenen die processen niet goed snappen. De oplossing is message passing; da's zo oud als het maar zijn kan. Sterker nog; het is een van de basisconcepten van 'echt' OOP.

Concurrency is niet makkelijker, maar het is wel makkelijker te implementeren omdat channels een primary type zijn, veel daar om heen is gebouwd en het opstarten van een losse thread niet moeilijk is (gebruik go voor een aanroep en voila). Dat in tegenstelling tot java. Sinds versie 8 is het wel beter geworden met parallelstream enzo, maar (zoals wel vaker) is het zelf schrijven van iets parallels veel meer werk en boilerplate.

[...]


Ik snap niet dat je voor "snelheid en schaalbaarheid" op Go uitkomt. Het is niet sneller dan bijvoorbeeld Java. Het komt, zoals Java, niet in de buurt van C++ / Rust. Als je een of andere trade-engine aan het bouwen bent waar microseconden belangrijk zijn, dan komt je niet op Java of Go uit. Als dat minder belangrijk is, is onderhoudbaarheid van de software een sterkere overweging. En dan is er nul reden om voor Go te gaan.

Wat ik als reden gaf is kort door de bocht en lang niet alles is langs gekomen. Java ging niet omdat de CTO dat niet in huis wil hebben, C++ en Rust hebben we inhouse niet echt ervaring mee maar wat we er voor ervaring in hadden was dat het we er niet snel of makkelijk in konden ontwikkelen en dat het niet makkelijk is om goed op te pakken. C++ omdat je snel verzand in alles wat het te bieden heeft en rust door het borrow mechanisme.

Kan nog wel doorgaan over hoe brak het ecosysteem is (dependency management? fuck it, we trekken de master wel van github!) en dergelijke, maar deze rant is al lang genoeg.

Dependency management was inderdaad drama, maar sinds 1.11 (en dat is waar het bedrijf is begonnen met ontwikkelen in go) word semantic version ondersteund en as we speak word er gewerkt aan proxy support. Overigens hoeft het niet op github te staan. Go maakt gebruik van version control, en dat kan github, bitbucket of whatever zoals private hosted zijn op basis van git, svn of mecurial.

Go is een memory managed taal zoals C# en Java en loopt tegen exact dezelfde limieten aan. Go is dan ook absoluut niet sneller dan Java. En komt niet in de buurt van C++ / Rust.

Bij java komt naar wat ik heb gehoord snel VM tuning kijken, dat heb je bij Go niet. Met C# weet ik niet hoe dat gaat (nooit mee gewerkt). Ja, Go is inderdaad garbage collected, maar wel standaard in parallel met erg kleine timeouts. In deze keynote kun je leuk zien hoe het door de jaren is verbeterd.

Als je van C# naar Go gaat en een 500% snelheidswinst behaalt dan doet die Go implementatie gewoon niet hetzelfde als de C# implementatie.

Functioneel deed het hetzelfde, volgens mij werd de database iets minder gehit, maar voor de rest staat me niet zo 1,2,3 meer bij wat het verschil was tussen de 2.

[ Voor 5% gewijzigd door Gropah op 22-07-2019 12:30 ]

[RayNbow]

Gropah schreef op maandag 22 juli 2019 @ 12:01:
Java doet het redelijk, maar met erg veel boilerplate en documentatie rondom generics is moeilijker te lezen.

Java:

default <U extends Comparable<? super U>> Comparator<T>     thenComparing(Function<? super T,? extends U> keyExtractor)

leest toch gewoon minder makkelijk.

Tja, use-site variance...

[ThomasG]

Java is natuurlijk niet het beste voorbeeld voor generics; het is een crappy implementatie (of eigenlijk een compiler hack dat het omzet naar code met Object-to-X casts) dat veel nadelen heeft. C# - of eigenlijk .NET - heeft generics zoals generics zouden moeten zijn, het C# concept van generics zit in tegenstelling tot Java verwerkt in de bytecode. Maar het mist mijn inziens wel een aantal features.

Ik ben zelf een fan van C++ templates, maar dat zijn uiteraard geen generics.

[Hydra]

@Gropah dude, wall of text Zal er later even voor gaan zitten. Kan daar niet ff in 5 minuten op reageren

ThomasG schreef op maandag 22 juli 2019 @ 12:11:
Java is natuurlijk niet het beste voorbeeld voor generics; het is een crappy implementatie

Absoluut. Scala en Kotlin hebben beiden reified generics. Ik ben geen grote fan van de taal Java zelf, wel van het ecosysteem (en wel van Kotlin ).

[ Voor 61% gewijzigd door Hydra op 22-07-2019 12:40 ]

[bwerg]

Hydra schreef op vrijdag 19 juli 2019 @ 10:09:
Concurrency is lastig omdat onze hersenen die processen niet goed snappen. De oplossing is message passing; da's zo oud als het maar zijn kan. Sterker nog; het is een van de basisconcepten van 'echt' OOP.

"De oplossing" is ook wel een beetje sterk gesteld. Transactional memory kan ook erg prettig werken. Dat voelt bijna als niet-concurrent programmeren terwijl het stiekem toch concurrent is.

[ Voor 10% gewijzigd door bwerg op 22-07-2019 13:31 ]

[Hydra]

bwerg schreef op maandag 22 juli 2019 @ 13:22:
[...]

"De oplossing" is ook wel een beetje sterk gesteld.

Helemaal mee eens. "Een oplossing" dan Elk voordeel hep z'n nadeel

[Douweegbertje]

Hydra schreef op maandag 22 juli 2019 @ 10:58:
[...]


Wat bedoel je met niches? Java is, ook in Nederland, een van de meest gebruikte talen in de 'back-end' bij grote bedrijven.

Afgezien daarvan; ik redeneer vanuit 't werk dat ik meestal doe, en dat zijn best complexe services met veel laagjes die met veel andere dingen praten. Alhoewel ik Go een kuttaal vindt; als ik een command line 'ding' moet maken dat ik statisch wil kunnen compilen naar een executable zou ik daar waarschijnlijk nu ook nog op uit komen.

Dat of Kotlin native, dat begint ook wel erg goed / gemakkelijk te worden. Nadeel is dat je daar lang niet alle libraries kunt gebruiken.

Niches, bedoel ik qua werkzaamheden. Zie hieronder

rutgerw schreef op maandag 22 juli 2019 @ 10:59:
[...]


In welk opzicht? Voor wat voor taken zet je Go in en niet bv Python?

Oprecht geïnteresseerd, bij ons op het werk wordt ook her en der Go ingezet maar ik kan maar niet achterhalen waarom...

Misschien is het dan mijn onkunde maar ik heb Python nooit relaxed gevonden. Gewoon qua usability, syntax, en werking. De sheer ellende van al die !()@* packages. Als we het dan toch hebben over "packaging" via git, dan heb ik dat 1000x liever dan de depency hell met pip.

Het voelt gewoon wat volwassener aan. Ik kan iets netjes builden wat overal werkt en als ik dan ga kijken naar de mogelijkheden - dus libraries, dan is daar zoveel voor beschikbaar wat IMO ook nog van goede kwaliteit is.

Besef ook dat ik op een ander niveau bezig ben dan een "native" die hard developer. In tegenstelling van wat Hydra vind, vind ik de programmeurs die libraries van Go op github plaatsen echt wel top-notch developers.

Ik zit overigens devops werk te doen. Dus mijn applicaties zijn niet te vergelijken met een financieel pakket of whatever. Echter wil ik ook niet een verzameling van random scripts hebben. Dus dan resteerd mij eigenlijk maar een paar opties. IMO vind ik dan de laagdrempeligheid van Go (niet qua learning overigens) een goede taal om je meuk mee en in te maken. Voeg daarbij toe dat je het dus kan builden, dat er concurrency in zit en IMO veel meer backing vanuit de community heeft dan Python. Vanuit development vind ik het ook iets makkelijker om met Go te developen, ook deels vanwege statically typed maar net zo goed je environment met python wat soms zwaar ruk is (my 2 cents).

Laat ik het zo zeggen, stel dat je nu nog niets hebt staan aan infra/scripts. Je kan kiezen tussen Python en Go? Mja, dan is het voor mij een redelijk simpele keuze.

Als laatste is het inherent handig voor kubernetes m.b.t. operators (https://coreos.com/operators/)

[ Voor 3% gewijzigd door Douweegbertje op 22-07-2019 13:54 ]

[Hydra]

Douweegbertje schreef op maandag 22 juli 2019 @ 13:52:
Niches, bedoel ik qua werkzaamheden.

Daar kun je Python ook niet echt met Java vergelijken. Python wordt relatief weinig voor back-end services gebruikt. Wel redelijk wat in de Data Science hoek, vooral omdat uit de 'science' kant redelijk wat libraries voor zijn. Maar da's over het algemeen geen spul dat je direct in productie wil zetten; vaak wordt dat omgeschreven (naar Scala bijvoorbeeld, veel gebruikt in de DS/DE hoek). Python zelf heeft ook nogal wat issues die het kwa performance in de weg zitten; concurrency bijvoorbeeld is gewoon stuk.

Edit: Kwam net wat leuks tegen: https://ai-arena.net/

[ Voor 3% gewijzigd door Hydra op 22-07-2019 14:29 ]

[RayNbow]

ThomasG schreef op maandag 22 juli 2019 @ 12:11:
C# - of eigenlijk .NET - heeft generics [...] Maar het mist mijn inziens wel een aantal features.

Zoals higher kinds?

[Kalentum]

@Douweegbertje bedankt voor je toelichting. Ben zelf ook niet zo onder de indruk van Python syntax maar vind Go ook niet echt mooi qua syntax. Ik doe niet veel met python (alleen wat privé projectjes) maar als ik in een dependency hell terecht komt werkt virtualenv prima. En de community, ik dacht dat die van Python groter en volwassener is... maar goed, kan aan mij liggen. Geen idee van de Go community.

[armageddon_2k1]

Vraagje aan de .NET mensen hier, ik heb zelf weinig ervaring met ASP.NET. Wel aardig wat ervaring met C#.

Wat vinden jullie van Blazor? Het is nog allemaal redelijk experimenteel, maar heeft het potentie?
YouTube: Blazor, a new framework for browser-based .NET apps - Steve Sanderson

De laatste demo (Flutter) lijkt me wat far-fetched misschien, vooral ook omdat Microsoft in mijn ogen niet de beste track-record heeft met hard inzetten op universele apps.

[armageddon_2k1]

Dubbel? Why?....

[ Voor 96% gewijzigd door armageddon_2k1 op 22-07-2019 21:39 ]

[boe2]

armageddon_2k1 schreef op maandag 22 juli 2019 @ 21:38:
Wat vinden jullie van Blazor? Het is nog allemaal redelijk experimenteel, maar heeft het potentie?
YouTube: Blazor, a new framework for browser-based .NET apps - Steve Sanderson

Ik hoop stiekem dat dit de revival van de MVVM pattern in gang zet, maar dan op het web. Degelijke clientside bindings met serverside sources zonder dat eeuwige gepriegel met javascript.

[DevWouter]

armageddon_2k1 schreef op maandag 22 juli 2019 @ 21:38:
Vraagje aan de .NET mensen hier, ik heb zelf weinig ervaring met ASP.NET. Wel aardig wat ervaring met C#.

Wat vinden jullie van Blazor? Het is nog allemaal redelijk experimenteel, maar heeft het potentie?
YouTube: Blazor, a new framework for browser-based .NET apps - Steve Sanderson

Het is een nieuwe SPA framework met een Microsoft sausje. Hoewel ik niet tegen Microsoft zou wedden hoop ik niet dat dit een "groot" succes wordt. Voor je het weet heb mensen die een database connectie proberen te openen in een blazor app want "het is C#".

[bauke1994]

DevWouter schreef op dinsdag 23 juli 2019 @ 12:45:
Voor je het weet heb mensen die een database connectie proberen te openen in een blazor app want "het is C#".

Dat is met JS niet veel anders https://stackoverflow.com/questions/37453671/run-a-sql-query-in-js

[ThomasG]

bauke1994 schreef op dinsdag 23 juli 2019 @ 13:09:
[...]


Dat is met JS niet veel anders https://stackoverflow.com/questions/37453671/run-a-sql-query-in-js

Daarvoor was er natuurlijk WebSQL Maar dat is inmiddels deprecated, en wordt vervangen door IndexedDB dat weer een NoSQL JSON database is.

[Hydra]

bauke1994 schreef op dinsdag 23 juli 2019 @ 13:09:
Dat is met JS niet veel anders https://stackoverflow.com/questions/37453671/run-a-sql-query-in-js

Dat soort shit zag je vroeger ook hoor. Gewoon SQL queries in een hidden form field en deze uit laten voeren door een generiek PHP script. Niks nieuws onder de zon; idiots gonna idiot.

[Gropah]

Nog een potentieel interessante blog van Guide van Rossum over parsers: https://medium.com/@gvanr.../peg-parsers-7ed72462f97c

schijnbaar zit hij te overwegen om wat veranderingen te maken in de python parser met nieuwe technologie en voor de moderne computer

[.oisyn]

Meh. Ik heb een hekel gekregen aan parser generators in de loop der tijd. Het probleem is dat je altijd tegen bepaalde limitaties aanloopt van de gebruikte parsersoort, of je moet een bredere set aan input accepteren dan je taal zelf. Of nog erger, je gaat je taal aanpassen zodat het past binnen de limitaties van de parser. Daarna zit je met een gegenereerde parsetree die los geprocessed moet worden naar een AST, of je moet je grammar-notatie aanvullen met code die de juiste datastructuur opbouwt terwijl je aan het parsen bent (zoals bij bison/yacc).

Ik heb heel wat parser generators versleten, maar wat een verademing was het toen ik voor KolQ het besluit had gemaakt om gewoon een handgeschreven recursive-decent parser te gebruiken (icm een variant van Shunting Yard voor expressies). Nieuwe features toevoegen is echt een eitje, itt al het werk dat je moet verzetten bij het gebruik van een parser generator.

[mcDavid]

bauke1994 schreef op dinsdag 23 juli 2019 @ 13:09:
[...]


Dat is met JS niet veel anders https://stackoverflow.com/questions/37453671/run-a-sql-query-in-js

Ik vind die antwoorden wel een beetje flauw hoor. Hoezo zou je niet gewoon een (My)SQL client in Javascript kunnen schrijven? De use-case lijkt me ver te zoeken maar wie zijn wij om daarover te oordelen

[kenneth]

mcDavid schreef op dinsdag 23 juli 2019 @ 17:06:
... maar wie zijn wij om daarover te oordelen

De maintainers van morgen

[RagingPenguin]

.oisyn schreef op dinsdag 23 juli 2019 @ 17:04:
Meh. Ik heb een hekel gekregen aan parser generators in de loop der tijd. Het probleem is dat je altijd tegen bepaalde limitaties aanloopt van de gebruikte parsersoort, of je moet een bredere set aan input accepteren dan je taal zelf. Of nog erger, je gaat je taal aanpassen zodat het past binnen de limitaties van de parser. Daarna zit je met een gegenereerde parsetree die los geprocessed moet worden naar een AST, of je moet je grammar-notatie aanvullen met code die de juiste datastructuur opbouwt terwijl je aan het parsen bent (zoals bij bison/yacc).

Hier kan ik me echt helemaal in vinden. In mijn hobby-project taal gebruik ik een yacc parser en dat is echt de grootste bron van frustratie (hoewel het wel echt fantastisch is als het werkt). Zo heb ik laatst generic types toegevoegd, de syntacs werkt als volgt:

oud:

code:

let double = i :: int -> i * 2
let add = x :: int -> y :: int -> x + y
let x = f :: (int -> int) -> f(1)

Werkte helemaal top en ziet er heel erg hip en modern uit enzo. Dus mijn oorspronkelijke idee voor het toevoegen van generics:

code:

let id = <a> a :: a -> a
let getId = <a :: { id : int }> a :: a -> a.id
let fst = <a> l :: list<a> -> l.get(0)

De eerste twee werkte prima, maar in het laatste voorbeeld ging heel de parser over de zeik. Na een dag aan kutten (die genereerde code valt ook niet zomaar even te debuggen) heb ik het maar opgegeven en inderdaad de taal aangepast aan de beperkingen van de parser.

code:

let id = <a> (a :: a) -> a
let getId = <a :: { id : int }> (a :: a) -> a.id
let fst = <a> (l :: list<<a>>) -> l.get(0)

Dus met meer haakjes en dubbele < en > voor het opgeven van type argumenten

[ThomasG]

.oisyn schreef op dinsdag 23 juli 2019 @ 17:04:
Meh. Ik heb een hekel gekregen aan parser generators in de loop der tijd. Het probleem is dat je altijd tegen bepaalde limitaties aanloopt van de gebruikte parsersoort, of je moet een bredere set aan input accepteren dan je taal zelf. Of nog erger, je gaat je taal aanpassen zodat het past binnen de limitaties van de parser. Daarna zit je met een gegenereerde parsetree die los geprocessed moet worden naar een AST, of je moet je grammar-notatie aanvullen met code die de juiste datastructuur opbouwt terwijl je aan het parsen bent (zoals bij bison/yacc).

Ik heb heel wat parser generators versleten, maar wat een verademing was het toen ik voor KolQ het besluit had gemaakt om gewoon een handgeschreven recursive-decent parser te gebruiken (icm een variant van Shunting Yard voor expressies). Nieuwe features toevoegen is echt een eitje, itt al het werk dat je moet verzetten bij het gebruik van een parser generator.

Volgens mij is KolQ inmiddels zo over-engineered dat het oorspronkelijke doel een bijzaak is geworden

Edit: nu is het wachten tot wij de kqsh-shell kunnen downloaden!

[ Voor 3% gewijzigd door ThomasG op 23-07-2019 21:29 ]

[Merethil]

ThomasG schreef op dinsdag 23 juli 2019 @ 21:16:
[...]
Volgens mij is KolQ inmiddels zo over-engineered dat het oorspronkelijke doel een bijzaak is geworden

Edit: nu is het wachten tot wij de kqsh-shell kunnen downloaden!

kolctl

[farlane]

Merethil schreef op dinsdag 23 juli 2019 @ 21:52:
[...]
kolctl

systemkolqd

Ook te gebruiken als alternatief voor je system init ....

[ThomasG]

farlane schreef op dinsdag 23 juli 2019 @ 22:31:
[...]

systemkolqd

Ook te gebruiken als alternatief voor je system init ....

Booten in single equation mode

[.oisyn]

Ik zat laatst wel naar de EFI SDK te kijken

[Gropah]

KolQOS dus

Maar even serieus, wat was het plan? Ben nu wel benieuwd

[.oisyn]

Gropah schreef op woensdag 24 juli 2019 @ 00:27:
KolQOS dus

Maar even serieus, wat was het plan? Ben nu wel benieuwd

Er is geen plan. Ik ben wel ooit bezig geweest met mijn eigen OS, dus interesse is er sowieso. Maar ik was de afgelopen week bezig met een specifiek probleem en nu weet ik alles van het UEFI boot proces (sort of ). In mijn zoektocht kwam ik ook de spec en SDK tegen van Intel

[farlane]

.oisyn schreef op woensdag 24 juli 2019 @ 00:32:
[...]
... en nu weet ik alles van het UEFI boot proces ...

[Mugwump]

Ik was even vergeten hoe frustrerend het is om te werken met klanten die een ' IT regieorganisatie' zijn, oftewel een hele lading enteprise architecten hebben die de meest onzalige XML formaten lopen te verzinnen voor berichtuitwisseling, waardoor ik een half kilometer Java code nodig heb voor het platslaan van een inputformaat met per data-element 3 overbodige tussenlagen, overal 0-n multipliciteiten terwijl enkel nul of 1 mogelijk is en ga zo maar door.

[Hydra]

Als je 'architecten' hebt die XML formaten gaan bedenken zou ik hard wegrennen. "Je werkt al 15 jaar voor ons en we kunnen je niet ontslaan, dus ga dit maar doen dan doe je vast weinig schade". Pff.

[sig69]

Ik moet naar een externe partij updates sturen, maar de eerste keer moet het dan met een tag "new" en daarna met een tag "update". Ik krijg geen enkele terugkoppeling of een bericht verwerkt is, ik kan het niet uitlezen uit hun api, en ik moet aan mijn kant maar bijhouden wat een "new" of een "update" moet zijn. Tsja probeer dat maar eens in sync te houden...
Krijg je emails van ze dat er een foutmelding is opgetreden omdat ik een "update" stuur terwijl het record niet bestaat (aan hun kant). We loggen alles, alles was netjes verstuurd, dus na 10 van die mails staat er een filter op: alles ongezien naar de prullenbak

[ Voor 27% gewijzigd door sig69 op 25-07-2019 00:45 ]

[BertS]

Mailbox uitlezen en als zo'n bericht binnenkomt alsnog een new sturen?
Of gewoon van alles twee berichten sturen: een new en een update


En over architecten: die 'titel' is de laatste tijd hard aan het devalueren.

[mcDavid]

Hydra schreef op woensdag 24 juli 2019 @ 23:24:
Als je 'architecten' hebt die XML formaten gaan bedenken zou ik hard wegrennen. "Je werkt al 15 jaar voor ons en we kunnen je niet ontslaan, dus ga dit maar doen dan doe je vast weinig schade". Pff.

Idd. In principe heb ik niets tegen een architect die meedenkt over hoe je een nieuw platform op kunt zetten oid, maar als een "architect" dat soort implementatie details (vooraf) moet uitwerken, dan is er ofwel iets mis met de organisatie, ofwel met de architect in kwestie.

[Hydra]

BertS schreef op donderdag 25 juli 2019 @ 08:19:
En over architecten: die 'titel' is de laatste tijd hard aan het devalueren.

Ik vind ons vakgebied sowieso een teringzooi. Het is echt te makkelijk om er een enorme zooi van te maken zonder dat iemand het doorheeft. En vaak worden dat soort types dan maar naar 'architect' gepromoveerd omdat ze code schrijven nooit leuk gevonden hebben en natuurlijk wel na 10 jaar een 'promotie verdiend' hebben. Geen code skills, geen people skills voor management, 'dus architect'.

Heb hiervoor bij 2 klussen een 'software architect' rol gehad en durf 't soms bijna niet te zeggen.

mcDavid schreef op donderdag 25 juli 2019 @ 08:56:
Idd. In principe heb ik niets tegen een architect die meedenkt over hoe je een nieuw platform op kunt zetten oid, maar als een "architect" dat soort implementatie details (vooraf) moet uitwerken, dan is er ofwel iets mis met de organisatie, ofwel met de architect in kwestie.

IMHO is software architect eigenlijk nooit een jobtitle maar een rol: een sterke ervaren 'lead' die de samenhang kwa software bewaakt. En daarin dus vooral een begeleidende rol speelt. Anyway; dat is hoe ik 'em invul. Ik heb nooit een goeie software architect meegemaakt die niet zelf ook meewerkte aan de software.

[ Voor 34% gewijzigd door Hydra op 25-07-2019 09:18 ]

[Styxxy]

Hydra schreef op donderdag 25 juli 2019 @ 09:16:
[...]
IMHO is software architect eigenlijk nooit een jobtitle maar een rol: een sterke ervaren 'lead' die de samenhang kwa software bewaakt. En daarin dus vooral een begeleidende rol speelt. Anyway; dat is hoe ik 'em invul. Ik heb nooit een goeie software architect meegemaakt die niet zelf ook meewerkte aan de software.

Inderdaad, vooral een begeleidende rol en bewaking dan vanuit een ivoren toren "het bepalen". Zo vul ik mijn "architecten" rol ook in .

[Hydra]

Styxxy schreef op donderdag 25 juli 2019 @ 09:38:
Inderdaad, vooral een begeleidende rol en bewaking dan wel vanuit een ivoren toren "het bepalen". Zo vul ik mijn "architecten" rol ook in .

"Ivoren toren" is letterlijk het tegenovergestelde van wat ik zei?

[Styxxy]

Hydra schreef op donderdag 25 juli 2019 @ 09:40:
[...]
"Ivoren toren" is letterlijk het tegenovergestelde van wat ik zei?

Verkeerd verwoord, ik bedoel dus net niet vanuit een ivoren toren alles bepalen .

[Hydra]

Styxxy schreef op donderdag 25 juli 2019 @ 09:44:
Verkeerd verwoord, ik bedoel dus net niet vanuit een ivoren toren alles bepalen .

Ah, dat verklaart

[Mugwump]

Hydra schreef op woensdag 24 juli 2019 @ 23:24:
Als je 'architecten' hebt die XML formaten gaan bedenken zou ik hard wegrennen. "Je werkt al 15 jaar voor ons en we kunnen je niet ontslaan, dus ga dit maar doen dan doe je vast weinig schade". Pff.

Helaas zie ik dit fenomeen bij best wat organisaties. Als je mazzel hebt, dan hebben ze in ieder geval nog enige achtergrond in development. Als je pech hebt snappen ze daar de ballen van.
De klantorganisatie waar ik het over heb besteed dus alles uit behalve het verzinnen van "welke functionaliteit hoort bij welk product / project" en "hoe vindt de informatieuitwisseling tussen systemen plaats?". Dat laatste leidt dan tot de meest onzalige XML formaten, die weer leiden tot 6000 gegenereerde Java classes en trage verwerking / hogere kosten. Het eerste wat wij doen na het ontvangen van dat soort berichten is het door een ACL heen gooien die er een intern JSON formaat van maakt die alle overbodige lagen eruit wipt en niet gebruikte informatie achterwege laat. Scheelt een factor 10-15 in omvang gemiddeld genomen.
En dan denken ze zich ook nog te moeten bemoeien met solution design waar ze echt de ballen van snappen. Zo dacht men dat het wel een goed idee was om onze transactionale store in DynamoDB ook te gaan gebruiken voor allerlei OLAP functionaliteit, zouden we geen gebruik mogen maken van AWS SQS omdat dat de volumes van enkele tientallen miljoenen berichten per dag niet aan zou kunnen en ga zo maar door.

Hydra schreef op donderdag 25 juli 2019 @ 09:16:
IMHO is software architect eigenlijk nooit een jobtitle maar een rol: een sterke ervaren 'lead' die de samenhang kwa software bewaakt. En daarin dus vooral een begeleidende rol speelt. Anyway; dat is hoe ik 'em invul. Ik heb nooit een goeie software architect meegemaakt die niet zelf ook meewerkte aan de software.

Wij hebben ook geen software architecten in ons team, gewoon een paar ervaren developers die gewoon de software architectuur erbij doen.
Ik had het overigens ook over 'enterprise architecten', niet over software / solution architecten. Dat is niet zelden een schoolvoorbeeld van het concept 'ivoren toren'.

[ Voor 19% gewijzigd door Mugwump op 25-07-2019 11:18 ]

[ThomasG]

Sowieso is een 'software architect' een nogal achterlijk iets. Het idee van een architect ligt namelijk veel dichter bij consultant dan bij programmeur.

[BertS]

ThomasG schreef op donderdag 25 juli 2019 @ 11:26:
Sowieso is een 'software architect' een nogal achterlijk iets. Het idee van een architect ligt namelijk veel dichter bij consultant dan bij programmeur.

Hmm, inderdaad. Dan kom je meer op een 'software constructeur' (als we dan toch terminologie uit de bouwsector blijven overnemen). Maar ja, dat staat een stuk minder interessant op je visitekaartje...

[Mugwump]

ThomasG schreef op donderdag 25 juli 2019 @ 11:26:
Sowieso is een 'software architect' een nogal achterlijk iets. Het idee van een architect ligt namelijk veel dichter bij consultant dan bij programmeur.

Ik zou sowieso niet weten waarom 'consultant' en 'programmeur' wederzijds uitsluitende rollen zouden moeten zijn.
Ik ben gewoon consultant bij een klant waarbij ik o.a. adviseer over de te kiezen softwareoplossingen en ik bouw gewoon mee.
De IT heeft nog steeds sterk het misplaatste idee dat ze een ingenieursdiscipline is, maar bij software zitten ontwerp en bouw veel meer verwoven dan in de elektrotechniek, werktuigbouwkunde of reguliere bouw.