Benchmark, Requests per second, microsoft c# core wins

@IceDread: hur är det tråkig attityd att belysa att jämförelsen är ungefär lika relevant att jämföra tiden för 0-100 km/h mellan två bilar men där "konkurrenten" bara kör med 3/4 gaspådrag?

Min gissning här är att det just nu pågår en rätt rejäl dragkamp mellan två grupper inom Microsoft. Det mellan .NET-gruppen och den relativt nya grupp inom Microsoft som jobbar med TypeScript och NodeJS.

Det har ställts en hel del frågor på bl.a. Build-konventen kring om Microsoft fortfarande är 100 % dedikerade till .NET fortfarande. Man pekar på saker som att Anders Hejlsberg ("pappan" till C#) numera jobbar med TypeScript, att IE-teamet lägger krut på att få till en variant av NodeJS baserad på Chakra (senaste JavaScript motorn i IE) samt att man lagt väldigt mycket krut på NodeJS stöd i VisualStudio.

Men självklart är det positivt att man jobbar på att öka prestanda i .NET Core! Få verkar tro att man når speciellt många nya utvecklare med detta, däremot verkar många tro att .NET Core kan minska hastigheten på fallet då det gör det möjligt att köra ASP.NET applikationer på Linux. Linux är totalt dominerade i "molnet", till och med i Azure har Linux runt 30 % andel. Linux är totalt dominerande i Amazon Web Services, IBM Bluemix och Google Cloud Platform.

Att .NET Core absolut var något man måste skapa blir uppenbart när man inser att i princip alla molntjänster tar betalt per använd klockcykel, det är alltså helt kritiskt att ha en effektiv plattform då det har en direkt påverkan på kostnaden att använda programvaran i molnet.

Angående Ruby: personligen använder jag det uteslutande som jag tidigare använde Python, d.v.s. som ett generellt programspråk för allt som inte är prestandakritiskt. Har bara gjort några småsaker med Rails bara för att känna på det.

Är både förvånad och inte förvånad att Ruby inte används mer. Förvånad då det är ett extremt väldesignat språk där designen verkligen tänkt till och där man verkligen har en stark teoretisk grund för designvalen.

Inte förvånad då sådana saker aldrig haft någon större relevans för språks popularitet tidigare. T.ex. så hade Lisp redan på 50-talet de flesta finesser som "moderna" språk som C# och Swift implementerat och det togs emot som väldigt revolutionerande.

Språk som Clojure och Rust har modeller för multitrådning som omöjliggör race-conditions (de uppnår det på helt olika sätt men race är de absolut värsta buggar man kan jaga).

Erlang är specifikt designat för extrem tillgänglighet. Enda plattformen som någonsin lyckats nå 99,9999999 % (nio nior) tillgänglighet. Det under en tidsperiod på 20 år.

I stället är de populära språken C++ (enormt utbud av sätt att skjuta av sig både fötterna och huvudet), C# och Python (båda språken har enormt med finesser, många verkar tillagda av olika grupper som aldrig pratat med varandra), Java och JavaScript (tja, båda språken har en rad designmissar dock har båda idag runtime-plattformar i världsklass och dessa kan användas av andra språk)...

@IceDread: man måste alltid hålla isär två dimensioner

• statiskt typat vs dynamiskt typat, binär skala

• starkt typat vs svagt typat, gradvis skala

Ruby, Python och Clojure är alla exempel på dynamiskt och väldigt starkt typade språk.

C#, Java och C++ är alla exempel på statiskt typade och starkt typade språk.

Go, Rust och Haskell är exempel på statiskt typade och extremt starkt typade språk

C är ett exempel på statiskt typat och svagt typat språk.

JavaScript och Perl är båda exempel på dynamiskt typade och väldigt svagt typade språk.

C++ är stort därför det faktiskt är enda rimliga valet om man har prestandakrav ihop med någon form av realtidskrav. Alla språk med s.k. "tracing GC" ("äkta" GC och inte någon form av referensräkning).

C är fortfarande stort av en rad skäl. T.ex. är det enda rimliga valet för OS-kärnor, alternativet är en delmängd av C++ där man skalat bort de delar som inte lämpar sig för OS-kärnor. Vissa mikrokontrollers kör "C++", men i praktiken är "C med nykelordet class" betydligt närmare sanningen.

Att C# lyckades (som förövrigt kom ut 5 år efter Ruby) är endast en effekt av att Microsoft stod bakom och de lade all sin vikt bakom denna plattform från start. Utan det stödet hade det blivit ett i raden av språk som finns men få använder. Inte för att C# på något sätt är dåligt, det har absolut ett bra språk, men på det stora hela sticker det inte ut på något jätterelevant sätt jämfört med andra språk som fanns innan.

Att så få språk lyckas är ju trots allt en konsekvens av att programspråket betyder rätt lite för slutresultatet. Bra programmerare skriver bra program i nästan alla språk de behärskar och dåliga programmera gör kattskit oavsett. Finns vissa specialfall där språk spelar roll, men oftast spelar plattformen större roll.

Tar man exemplet Rails (som jag som sagt aldrig använt, gillar Ruby som ett generellt RAD-språk) så är den enda egentliga kritik jag sett att plattformen inte är effektiv nog att hantera större projekt. Och då klarar man ändå sådant som github, så är nog rätt få människor som jobbar på plattformar som är för stora att inte kunna hanteras av Rails.

Angående jämförelsen. Det är inte bara lite sned, den är ju totalt felaktig givet vilka siffror man får på den "konkurrerande" plattformen, min 15 W TDP laptop presterar bättre än så med det jag skriver och har aldrig gjort ett professionellt NodeJS program (har i.o.f.s väldigt bra koll på flaskhalsar runt networking och borde därför rimligen inte göra de mest löjliga misstagen).

Det du skriver på sista raden befäster lite min bild av den typiska C#/.NET programmeraren: de gillar att framhålla C# förträfflighet men ofta visar det sig att man inte har någon relevant erfarenhet av speciellt många andra språk.

Försöker själv "tvinga" mig att lära mig minst ett nytt programspråk per år, ungefär till nivån att jag utan problem skulle kunna hoppa på ett konsult-gig där man använder språket med max en dags förberedelse.

Har aldrig förväntat mig att få jobba med språk som Haskell, Clojure eller Erlang. Men genom att lära sig dem får man perspektiv på språkdesign, man lär sig hitta andra vägar att lösa vissa problem. När man lärt sig 10-15 språk märker man också det gå allt fortare att lära sig nya språk, man lär sig vilka saker man måste lära sig för att förstå grundtanken med språket. Kort och gott, det gör en till en bättre programmerare oavsett vilket språk man råkar använda för tillfället.

Sedan ska aldrig säga aldrig. Har genom åren jobbat med en del språk, som t.ex. TCL, VB, ADA och ARM-assembler, som jag aldrig skulle gissat kunde vara relevant att ha koll på i förväg. Lite besviken att aldrig ha kommit i direkt kontakt med Cobol, är i.o.f.s. ett språk jag inte heller lärt mig så kanske lika bra det

@IceDread: sa aldrig att jag skulle bli "bra" i språket, bättre än 90 % räcker för mig
Det viktigast med övningen är att i princip obehindrat kunna göra det jag vill i språket och framförallt förstå dess grundläggande filosofi. Programmering är min största hobby, lägger åtskilliga antal timmar per månad på detta utanför arbetet. Något andra kanske lägger på att titta på film, spela datorspel, lösa korsord eller liknade.

> 99% av alla programmerare producerar långsammare och på alla andra möjliga andra sätt sämre resultat i assembler än vad moderna kompilatorer fixar. Finns några extremt specifika fall där man manuellt kan använda assembler på ett sätt som inte kan uttryckas i t.ex. C eller C++ så att en kompilator kan generera samma kod. ISA i moderna CPUer är inte längre designad för att hanteras av människor, den är helt designad för att effektivt kunna användas av kompilatorer så inte så konstigt att människor har svårt att spöa kompilatorer idag.

Ett sådant fall är beräkning av internet-checksumma där man kan utnyttja "carry-biten" på ett sätt som inte har en motsvarighet i C/C++.

En börs, antar att det handlar om HFT i detta fall, har inga hårda realtidskrav. Man vill ha låg genomsnittlig latens och hög genomströmning, det är absolut möjligt även med "tracing GC". Faktum är att många algoritmer för multi-CPU-system som är i klassen "lock-free" och "wait-free" endera inte är möjligt utan "tracing GC" eller i alla fall blir väldigt ineffektiva utan GC.

Så är man ute efter låg genomsnittlig latens, hög skalbarhet och hög genomströmning är moderna JVM:er de bästa plattformar man hittar idag. Dock är C och C++ bättre val för applikationer med realtidskrav, även relativt mjuka sådana som behövs t.ex. spel. Har man hårda realtidskrav fungerar överhuvudtaget inte språk med "tracing GC" då det är omöjligt att beräkna en övre gräns för latens (i sådana fall går det normalt sett inte att använda någon form av dynamisk minneshantering).

Anledningen att inbyggda-system, även de utan realtidskrav, normalt undviker plattformar med "tracing GC" är att en sådan plattform presterar bättre ju närmare man kommer abstraktionen att det finns oändligt med RAM. Och omvänt, vill man hålla mängden allokerad mängd RAM väldigt låg presterar en "tracing GC" horribel. i dessa lägen kan man endera köra med plattformar med ARC (t.ex. Swift, Python körde i alla fall tidigre med detta men kan vara "tracing GC" idag), RAII (som C++ och Rust) eller med manuell minneshantering.