Taal of framework keuze op lange termijn

[Pisang]

Goedemiddag,

Voor mijn bedrijf wil ik een maatwerk (web)applicatie laten maken, het komt het neer op het volgende;

De applicatie trekt om de zoveel tijd (15 min, 30 min...is nog nader te bepalen) XML feeds uit meerdere API's. Deze feeds gaan allemaal een lokale database in en en worden daar verder (intelligent) gefilterd.
Eindgebruikers kunnen zonodig informatie doorspelen of beoordelen.

We rekenen op ± 30.000 feeds per dag aan ± 2kb per feed, welke voor 99% na een maand ook weer verwijderd worden, qua database niet heel spannend dus denk ik.

Nou heb ik wel wát kaas van ASP en PHP gegeten, maar simpelweg niet genoeg om een dergelijke applicatie te bouwen, zeker met het oog op de toekomst wat betreft schaalbaarheid niet. Uiteraard zijn er tig mogelijkheden wat betreft taal of framework, maar iedereen heeft uiteindelijk zijn eigen voorkeur.

Mijn vraag is dan ook, welke taal zou qua onderhoud (rekening houdend met outsourcing) en schaalbaarheid het best passen? Uiteraard het liefst met enige onderbouwing

Alvast bedankt voor de input!

[simon]

Ik denk eigenlijk dat het niet erg veel uitmaakt welke taal het is.

XML feeds zijn gewoon GET requests en dat kan iedere taal/framework wel, ik denk ook niet dat de prestatie in dit geval erg taal afhankelijk is.

De klus is vrij generiek wat betreft techniek als ik het begrijp.

Ga je de app nu zelf bouwen? Of ga je die uitbesteden? Als je 'm uitbesteed zou ik eerst naar de kwaliteit van het bedrijf kijken, en hun onderbouwing voor het kiezen van een techniek.

Ik denk niet dat je met deze vraag kan zeggen, doen we 't in PHP, Ruby, ASP.net, whatever. Alle grote talen zullen niet zomaar verdwijnen, support blijft sowieso nog wel.

Belangrijkere vraag is, hoe snel moet de app af zijn, wat voor load moet ie trekken, hoe wil je het hosten, hoeveel wil je er aan uit geven.

[Miyamoto]

Als je het niet zelf bouwt, geef een bedrijf dan een omschrijving van wat je wilt hebben en ga je vooral niet bemoeien met architectuur of techniek. Daarvoor huur je nou juist iemand in. Als je diegene niet vertrouwt, moet je een andere partner zoeken. Je geeft nl. zelf aan er niet voldoende kennis van te hebben, je kunt dan dus ook geen (gedegen) advies uitbrengen.

[Pisang]

Het project wordt sowieso uitbesteed, hiervoor hebben we partners welke in het verleden erg goed werk af hebben geleverd. Er wordt wellicht 5% inhouse gedaan, met name het front-end, meer niet. Uiteraard hebben we zeer uitgebreide documentatie wat betreft de functionaliteit en deze aan de developers voorgelegd. We zijn nog in afwachting van hun antwoord hierop.

Een standaard vraag richting ons is welke taal de voorkeur voor óns zou hebben. Normaliter is het geen probleem om de keuze aan de developer te laten, maar dit is voor ons echter een veel serieuzer project dan de voorgaande projecten, ondanks dat het wellicht technisch allemaal minder gecompliceerd is, vandaar de vraag.

Wat betreft hoe snel de app af moet zijn, ons streven is minder dan 3 maanden, dit moet redelijk haalbaar zijn heb ik het idee, we gaan uit van 2 fulltime medior/senior developers. De hosting zal op ons eigen Vmware platform plaatsvinden, resources zijn voorlopig geen issue, mocht dit wel een probleem gaan worden, dan is het kostentechnisch geen probleem om dit uit te besteden richting AWS/Azure of wat dan ook.

[simon]

Resources zijn geen issue en je hebt iets minder dan 3 maanden. Je weet je eigen budget, misschien gewoon offertes gaan aanvragen en kijken waar mensen mee komen.

Als je in je toekomst je eigen personeel er aan wil hebben kunnen werken zou ik kijken wat je eigen personeel kan. Zodat je niet veel geld aan cursussen kwijt bent.

Maar ik heb 't gevoel dat als je een redelijk gevestigde taal icm met een gevestigd framework kiest, er weinig vuiltjes aan de lucht zullen zijn qua continuiteit. PHP, ASP.NET, maar ook frameworks zoals RoR, Zend, CakePHP zullen nog wel even bestaan.

[ZpAz]

Momenteel maak ik een op een aantal vlakken vergelijkbaar iets voor een klant. Mijn systeem haalt ook periodiek informatie op bij diverse api's via XML (momenteel nog één maar het is zo opgezet dat het meerdere kan doen). Hier gaat het om grotere XML bestanden wat in totaal zo'n 20GB aan informatie is voor de eerste keer (opvolgende keren wordt er eerst gekeken wat de laatste update tijd van de XML was zodat ie niet elke keer weer alles ophaalt).

Hiernaast is er ook een webinterface waarmee "gebladerd" kan worden door de opgehaalde informatie. Het ophalen heb ik zelf in een Java applicatie gemaakt. De webinterface in PHP.

Je zou een cron kunnen laten lopen om de informatie via PHP periodiek op te halen, maar met 30k verschillende GET requests lijkt me dat toch niet de juiste weg om te bewandelen. Je krijgt dan waarschijnlijk problemen met max_execution_time e.d. en de mogelijkheid om het multithreaded op te lossen is niet mogelijk. De taal is imho gewoon niet geschikt voor dat gedeelte.

Voor het gedeelte waar de informatie getoond moet worden in een browser is het wel een goede kandidaat. (Hoewel dat ook bijvoorbeeld in Java zou kunnen icm Tomcat oid).

[kwaakvaak_v2]

maar...

"Het project wordt sowieso uitbesteed, hiervoor hebben we partners welke in het verleden erg goed werk af hebben geleverd"

Dan laat je de keuze van taal of framework toch aan die partners over, zet je alleen in je eisen dat je bepaalde schaalbaarheid en ondersteuning van ze verwacht?

Als ik zo'n vraag krijg binnen mijn kennisgebied zou ik een product wat ik zeg 5 jaar moet garanderen (met bijpassende SLA ) baseren op een framework waarvan ik weet dat het een LTS versie heeft.

[simon]

ZpAz schreef op donderdag 05 september 2013 @ 16:22:
Momenteel maak ik een op een aantal vlakken vergelijkbaar iets voor een klant. Mijn systeem haalt ook periodiek informatie op bij diverse api's via XML (momenteel nog één maar het is zo opgezet dat het meerdere kan doen). Hier gaat het om grotere XML bestanden wat in totaal zo'n 20GB aan informatie is voor de eerste keer (opvolgende keren wordt er eerst gekeken wat de laatste update tijd van de XML was zodat ie niet elke keer weer alles ophaalt).

Hiernaast is er ook een webinterface waarmee "gebladerd" kan worden door de opgehaalde informatie. Het ophalen heb ik zelf in een Java applicatie gemaakt. De webinterface in PHP.

Je zou een cron kunnen laten lopen om de informatie via PHP periodiek op te halen, maar met 30k verschillende GET requests lijkt me dat toch niet de juiste weg om te bewandelen. Je krijgt dan waarschijnlijk problemen met max_execution_time e.d. en de mogelijkheid om het multithreaded op te lossen is niet mogelijk. De taal is imho gewoon niet geschikt voor dat gedeelte.

Voor het gedeelte waar de informatie getoond moet worden in een browser is het wel een goede kandidaat. (Hoewel dat ook bijvoorbeeld in Java zou kunnen icm Tomcat oid).

je kunt PHP ook vanaf command line draaien, en de execution tijd verlengen. Het lijkt mij beetje rommelige omweg, maar het kan.

[kwaakvaak_v2]

simon schreef op donderdag 05 september 2013 @ 16:27:
[...]

je kunt PHP ook vanaf command line draaien, en de execution tijd verlengen. Het lijkt mij beetje rommelige omweg, maar het kan.

Hangt er vanaf hoe je het aanpakt

Je kunt in PHP ook reactief programmeren en het in een infinite loop laten draaien als process. (zie http://reactphp.org/) maar dan moet je de feeds op een of andere manier laten pushen naar je service.

(niet dat dit mijn voorkeur zou hebben, maar je kunt php oneindig laten draaien als je dat zou willen)

[DXaroth]

Bedenk ook dat meer dan 1 taal ook meer dan mogelijk is.. zolang ze maar een gemeenschappelijk gedeelte hebben om te communiceren (ik zou zelf iets van een Message Queue kiezen hiervoor)

Dan heb je dus een front-end die alles weergeeft (van hoe je het beschrijft hoeft deze enkel de database uit te lezen), vervolgens heb je een message queue die door een process gevult wordt met feeds die geupdate moet worden. Een 3e app (die N processen groot is, liggend aan hoe veel feeds je hebt.. op die manier kan je makkelijk(er) schalen) die naar de MQ luisterd, en zodra er een taak binnen komt, deze uitvoerd... dit kan dan zowel het binnenhalen of het filteren zijn van de feeds.

Ik zou persoonlijk niet php gebruiken voor command-line processen.. ja het werkt, maar je kan ook met een schroevendraaier een spijker in een muur rammen als je je best doet... zoek de beste tools uit voor elk deel, zodat het efficient en schaalbaar blijft.

[Gomez12]

Ik zou eigenlijk (in 1e instantie) maar 1 grote vraag hebben bij het project : Hoe wil je die 30.000 feeds ophalen? En hoe wil je omgaan met een verdubbeling van dat aantal feeds?

Want dat gaat je meest simpele zwakke punt worden.Single threaded ga je dat simpelweg tijdstechnisch niet redden binnen 24h, multithreaded is een leuk toverwoord maar als er zeg 10.000 feeds timeout problemen gaan geven dan wil je niet 10.000 threads hebben draaien op je server die wachten op een timeout. En omgekeerd met een thread pool wil je ook niet hebben dat die helemaal verstopt raakt op 10.000 timeout feeds, dus developer leg maar uit hoe je hiermee wil omgaan.

En als 2e vraag zou ik hebben : Hoe ga je om met invalid feeds? Het is heel leuk om enkel valid xml te accepteren bij 100 feeds, maar bij 30.000 feeds gaan er simpelweg feeds tussen zitten die invalid xml gaan produceren en ik vermoed dat jij ze niet alle 30.000 elke dag na gaat lopen of ze wel of niet data hebben ontvangen (en of ze wel of niet data moesten ontvangen).
In de praktijk zal je op 30.000 feeds als je die echt wilt ondersteunen meerdere parsing-strategieeen moeten inzetten en een overzichtelijke vorm van failures moeten hebben.

Met 30.000 gewenste feeds ga je simpelweg niet meer praten over standaard oplossingen waarbij er voor de uitzonderingen wel een aparte oplossing later gezocht gaat worden. Met 30.000 feeds zal je van te voren er al rekening mee moeten houden dat je veel bagger/serverfouten tegen gaat komen, de grote vraag is hoe wenst je developer partij daarmee om te gaan. Heeft hij daar vooraf een werkwijze voor of gaat het allemaal incidenten werk worden waarbij je de incidenten zelf moet opzoeken.

[Pisang]

Gomez12 schreef op vrijdag 06 september 2013 @ 00:45:
Ik zou eigenlijk (in 1e instantie) maar 1 grote vraag hebben bij het project : Hoe wil je die 30.000 feeds ophalen? En hoe wil je omgaan met een verdubbeling van dat aantal feeds?

Nou, niet via commandline PHP in ieder geval

Ik heb inmiddels één voorstel terug, waar als basis van het systeem Java Play (ivm multithreading) voorgesteld werd.

Want dat gaat je meest simpele zwakke punt worden.Single threaded ga je dat simpelweg tijdstechnisch niet redden binnen 24h, multithreaded is een leuk toverwoord maar als er zeg 10.000 feeds timeout problemen gaan geven dan wil je niet 10.000 threads hebben draaien op je server die wachten op een timeout. En omgekeerd met een thread pool wil je ook niet hebben dat die helemaal verstopt raakt op 10.000 timeout feeds, dus developer leg maar uit hoe je hiermee wil omgaan.

Klopt helemaal, dit dient ook netjes afgehandeld te worden. Ik ga dit ook direct voorleggen, dank voor de eye-opener.

En als 2e vraag zou ik hebben : Hoe ga je om met invalid feeds? Het is heel leuk om enkel valid xml te accepteren bij 100 feeds, maar bij 30.000 feeds gaan er simpelweg feeds tussen zitten die invalid xml gaan produceren en ik vermoed dat jij ze niet alle 30.000 elke dag na gaat lopen of ze wel of niet data hebben ontvangen (en of ze wel of niet data moesten ontvangen).
In de praktijk zal je op 30.000 feeds als je die echt wilt ondersteunen meerdere parsing-strategieeen moeten inzetten en een overzichtelijke vorm van failures moeten hebben.

Het is afhankelijk van het aantal feeds wát er daadwerkelijk fout gaat hoe we hier mee om zullen gaan, ik zie hier persoonlijk niet zo'n groot probleem in, dat heeft voornamelijk te maken dat het niet erg is als er een paar procent niet goed doorkomt.

Met 30.000 gewenste feeds ga je simpelweg niet meer praten over standaard oplossingen waarbij er voor de uitzonderingen wel een aparte oplossing later gezocht gaat worden. Met 30.000 feeds zal je van te voren er al rekening mee moeten houden dat je veel bagger/serverfouten tegen gaat komen, de grote vraag is hoe wenst je developer partij daarmee om te gaan. Heeft hij daar vooraf een werkwijze voor of gaat het allemaal incidenten werk worden waarbij je de incidenten zelf moet opzoeken.

Ik ga dit zeker opnemen, dank nogmaals!

[DXaroth]

30000 feeds is zeker het probleem niet, maar je moet ook uitgaan van het volgende:

1) met hoe veel feeds begint het systeem (ik neem aan dat dit niet -meteen- 30k is)
2) met hoe veel feeds verwachten wij dat het systeem over N maanden zal draaien (dit kan dus 30k zijn, of zelfs meer)

Daarnaast, hoe veel budget gaat er zijn, nu en in de toekomst, om met dit verschil om te gaan? wat nu als de inschatting van 30k ruim overschreden wordt, en je op 80k uit komt.. hoe verwacht men dit op te lossen, en hoe verwacht men om te gaan met de mogelijke situatie dat het concept niet toereikend gaat zijn.

Ik ben zelf altijd huiverig voor java.. we gebruiken het nu zelf ook voor onze ESB, maar dat is enkel omdat java 'goede' ESB implementaties heeft.. de ESB zelf levert het af bij andere systemen, die allen -niet- java zijn.
Het waarom gedeelte is simpel; de klant wil niet onnodig betalen voor te grote systemen.. dat er een tweetal zware ESB systemen tussen staan is prima, maar zodra zij gaan opschalen naar meer klanten, moet elk onderdeel ook kunnen opschalen, en met java betekend dit dat zij veel sneller meer kosten gaan maken.. terwijl met het huidige plan (waar die onderdelen in python zijn) krijg je nagenoeg net zo veel performance, zonder extra veel hardware kosten.

[Pisang]

Bij de start zitten we rond de 30.000 en dit zal eigenlijk vrij langzaam groeien, misschien 5k per jaar erbij. Echt niet meer. Dit is dus een vrij statisch gegeven.

Wat spannender is, is het filter gedeelte, dus het gedeelte ná dat de feeds vrij plat in de DB gestopt zijn, de queries die daar op los gelaten gaan worden zullen na een jaar jaar op z'n minst verdubbeld zijn en dáár zit dan ook het schaalbaarheidsissue (voor zover je hierover kan spreken) in. Ik kan echter niet inschatten wat voor load dat produceert, dagelijks dienen dus 30k-feeds, profielafhankelijk (rating uit het verleden, keywords, etc) voor +/- 20 man gefilterd te worden. De filtering gebeurt dus ná het binnentrekken van alle feeds.

[simon]

Toch klinkt 't niet echt enorm veel. 30000 feeds, als je dat in je DB zet heb je toch nog steeds een relatief kleine DB, ik weet niet wat voor 'spannende' dingen je er mee wil doen, maar volgens mij is dat niet zo spannend als je de juiste tools gebruikt.

[Verwijderd]

Pisang, ik lees in de openingspost "30.000" feeds per dag en je laatste post "30.000 en dan 5k per jaar erbij".

Da's wel een behoorlijk verschil als je een applicatie gaat bedenken. Het is vooral belangrijk om dat duidelijk aan je potentiele opdrachtnemer te vertellen, of eigenlijk is het nog belangrijker dat jouw opdrachtnemer dat aan jou vraagt. De vragen die Gomez daarover terecht stelt zou je opdrachtgever ook moeten stellen.

Ik zou taaladviezen naast me neerleggen. De taal is uiteindelijk een middel om een goed technisch voorstel mee te realiseren en de taal zelf is niet vaak bepalend voor het succes van een project, tenzij je tegen héle specifieke limitaties aanloopt, zoals multithreading met PHP. Ik zou met een aantal partijen gaan praten en de partij kiezen

- die de meest kritische vragen stelt
- die (dientengevolge) met de best uitgedachte plan/specificatie komt, bij voorkeur met enkele voorbeeldschermen of wireframes
- die naar je gevoel een goed team heeft zitten

/ Ik had trouwens eerst alleen JAVA! getypt, maar dat was een beetje flauw. Wat me wel nog te binnen schoot is die filtering. Solr (en tegenwoordig ElasticSearch) is de de facto oplossing voor het zoeken en filteren van grote hoeveelheden tekstuele gegevens. Funda gebruikt het voor zoeken in hun faceted search (dat ding met al die verschillende filters aan de linkerkant). Als je drilldown functionaliteit zoekt voor grote bakken tekstuele data en het moet schalen tot vele miljoenen documenten dan zit je met Solr in elk geval goed: http://lucene.apache.org/solr/. Solr deploy je als aparte applicatie en je praat vanuit je 'hoofdapplicatie' met Solr via een "rest interface" (gewone http requests die XML of JSON teruggeven) dus je kunt dan nog steeds kiezen welke taal je in de app wil gebruiken die die feeds in Solr steekt en ze er weer uit haalt met queries.

[ Voor 30% gewijzigd door Verwijderd op 06-09-2013 17:41 ]

[Pisang]

Verwijderd schreef op vrijdag 06 september 2013 @ 17:33:
Pisang, ik lees in de openingspost "30.000" feeds per dag en je laatste post "30.000 en dan 5k per jaar erbij".

Da's wel een behoorlijk verschil als je een applicatie gaat bedenken.

Het gaat om 30.000 per dag, na een jaar wellicht 35.000 per dag. Excuus voor de onduidelijkheid.

Het is vooral belangrijk om dat duidelijk aan je potentiele opdrachtnemer te vertellen, of eigenlijk is het nog belangrijker dat jouw opdrachtnemer dat aan jou vraagt. De vragen die Gomez daarover terecht stelt zou je opdrachtgever ook moeten stellen.

Daar is inmiddels duidelijkheid over!

Ik zou taaladviezen naast me neerleggen. De taal is uiteindelijk een middel om een goed technisch voorstel mee te realiseren en de taal zelf is niet vaak bepalend voor het succes van een project, tenzij je tegen héle specifieke limitaties aanloopt, zoals multithreading met PHP.

Van de 3 overige partijen zijn er al 2 met Java (in ieder geval voor het ophalen van de feeds) gekomen, dat lijkt me dus wel de juiste richting.

/ Ik had trouwens eerst alleen JAVA! getypt, maar dat was een beetje flauw. Wat me wel nog te binnen schoot is die filtering. Solr (en tegenwoordig ElasticSearch) is de de facto oplossing voor het zoeken en filteren van grote hoeveelheden tekstuele gegevens. Funda gebruikt het voor zoeken in hun faceted search (dat ding met al die verschillende filters aan de linkerkant). Als je drilldown functionaliteit zoekt voor grote bakken tekstuele data en het moet schalen tot vele miljoenen documenten dan zit je met Solr in elk geval goed: http://lucene.apache.org/solr/. Solr deploy je als aparte applicatie en je praat vanuit je 'hoofdapplicatie' met Solr via een "rest interface" (gewone http requests die XML of JSON teruggeven) dus je kunt dan nog steeds kiezen welke taal je in de app wil gebruiken die die feeds in Solr steekt en ze er weer uit haalt met queries.

Goed om te weten, we gingen uit van een 'standaard' database.

[Verwijderd]

kwaakvaak_v2 schreef op donderdag 05 september 2013 @ 16:43:
[...]


Hangt er vanaf hoe je het aanpakt

Je kunt in PHP ook reactief programmeren en het in een infinite loop laten draaien als process. (zie http://reactphp.org/) maar dan moet je de feeds op een of andere manier laten pushen naar je service.

(niet dat dit mijn voorkeur zou hebben, maar je kunt php oneindig laten draaien als je dat zou willen)

Als TS toch naar AWS kijkt, dan zou hij SQS kunnen gebruiken. En daar kun je dan iets simpels omheen bouwen dat de messages afhandelt.

[Gomez12]

Pisang schreef op maandag 09 september 2013 @ 13:25:
[...]
Daar is inmiddels duidelijkheid over!

Maar hebben ze / jullie ook de volgende vragen gesteld of is het echt alleen bij mijn lijstje gebleven, mijn lijstje waren namelijk enkel de baby-vraagjes.

[...]
Van de 3 overige partijen zijn er al 2 met Java (in ieder geval voor het ophalen van de feeds) gekomen, dat lijkt me dus wel de juiste richting.

Ik zou dan wel heel duidelijk omschreven willen hebben wat er exact gegarandeerd wordt etc.
Java / .Net etc zijn (standaard) geen lichte talen die je even inzet om 30.000 feeds op te halen...

[...]
Goed om te weten, we gingen uit van een 'standaard' database.

Tja, 30.000 entry's per dag is afhankelijk van de bewaar tijd ook niet echt spannend voor een 'standaard' database. Met na 30 dagen verwijderen zit je op <1 miljoen entry's, elke standaard database moet dat neuspeuterend aankunnen op standaard hardware.

[OrangeTux]

[b][message=40828015,noline]Je krijgt dan waarschijnlijk problemen met max_execution_time e.d. en de mogelijkheid om het multithreaded op te lossen is niet mogelijk.

Dit is niet helemaal waar.

[DXaroth]

Pisang schreef op maandag 09 september 2013 @ 13:25:
Van de 3 overige partijen zijn er al 2 met Java (in ieder geval voor het ophalen van de feeds) gekomen, dat lijkt me dus wel de juiste richting.

Als 10 partijen voorstellen om iets in basic te schrijven, dan zegt dit alsnog weinig of het de juiste richting is of niet, enkel dat die 10 partijen veel ervaring hebben met java... Java is hun hamer, en ze maken van jouw probleem een spijker.
Vraag ze -waarom- ze java willen gebruiken, en waarom hun oplossing volgens hun de beste is.. en schroom je niet om twijfels te trekken aan hun redenering.. een goede consultant zal makkelijk aan kunnen geven waarom hun idee beter is, een slechte consultant zal proberen uit te leggen dat dat komt omdat zij goed zijn in die oplossing.

[Pisang]

DXaroth schreef op dinsdag 10 september 2013 @ 08:23:
[...]


Als 10 partijen voorstellen om iets in basic te schrijven, dan zegt dit alsnog weinig of het de juiste richting is of niet, enkel dat die 10 partijen veel ervaring hebben met java... Java is hun hamer, en ze maken van jouw probleem een spijker.
Vraag ze -waarom- ze java willen gebruiken, en waarom hun oplossing volgens hun de beste is.. en schroom je niet om twijfels te trekken aan hun redenering.. een goede consultant zal makkelijk aan kunnen geven waarom hun idee beter is, een slechte consultant zal proberen uit te leggen dat dat komt omdat zij goed zijn in die oplossing.

Geen van de partijen waar we mee in overleg waren hebben Java als hun 'ding', eigenlijk werd er liever gekozen voor PHP, maar dit is technisch gezien gewoon een mindere optie. Altijd leuk, om de tafel met programmeurs waarvan de helft gewoon hun richting op pushed zonder onderbouwing...gelukkig wel een partij gevonden welke ons genoeg vertrouwen gaf wat betreft kennis.

....we zijn dus inmiddels aan de slag in Java Play icm (voorlopig) postgres, dank voor de input. We gaan zien hoe het gaat lopen

[Verwijderd]

Voor webapps / websites zou ik zeker Go (golang.org) in de gaten houden. Threading is standaard in Go (middels concurrency) en werkt heel goed. Hoe goed is Go? download.google.com draait op Go, net als delen van youtube.com. Maar het grootste voordeel is dat er nagenoeg geen valkuilen in zitten. Neem de tour en laat je verrassen.

[Gomez12]

Verwijderd schreef op maandag 16 september 2013 @ 21:52:
Hoe goed is Go? download.google.com draait op Go, net als delen van youtube.com.

Dit vind ik altijd zulke zinloze uitspraken. Een bedrijf als Google gebruikt elke programmeertaal wel ergens.