Som jag skrev tidigare så anser jag att java och c# har bägge sina styrkor och svagheter, lätt att en post här kan uppfattas på fel sätt, men här följer lite åsikter. Jag tycker du har skrivit bra input men håller inte med om allt.
Skrivet av Yoshman:
I teorin är async/await ett väldigt välkommet tillägg då det möjliggör programmering på ett sätt som liknar Go/Erlang, det sättet är väldigt trevligt när man jobbar med system som utför väldigt mycket samtidig I/O men det man kör mellan operationerna inte drar supermycket CPU-kraft. Har själv lagt väldigt mycket kraft på att fundera på hur man kan få Go/Erlang modellen i C, men det är bara att konstatera att sättet Go/Erlang i sina definitioner beskriver hur anropsstacken ska hanteras är ett hårt krav för att det ska fungera bra.
Var därför väldigt förvånad när C# fick async/await för precis som C (och Java, C++, Pythot m.fl) saknar alla dessa "rätt" hantering av anropsstacken. Visar sig också att async/await har effektivitetsproblem just p.g.a. sättet man måste implementera det, så rekommendationen är att inte använda denna finess för högprestanda-servers.
Problemet kokar till stor del ner till detta:
"For asynchronous methods that actually yield execution (due to awaiting an object that’s not yet completed), the asynchronous method infrastructure needs to allocate a Task object to return from the method, as that Task serves as a unique reference for this particular invocation."
länk
Använder man detta i UI-sammanhang kommer ofta data finnas tillgängligt och man undviker denna kostnad, handlar det om I/O mot nätverk, filsystem, databaser etc så är en CPU så pass snabb att man i princip aldrig kommer ha data tillgängligt och därför måste ta de kostnader (som inte existerar i Erlang/Go) som beskrivs under "Know When Not to Use Async".
Java har överhuvudtaget ingen motsvarighet sett till koddesign, men funktionellt skulle man använda en kombination av "executors" och "NIO". Inte lika enkelt som Go/Erlang men resultat presterar lika bra.
Async, await är grymt, men måste givetvis användas rätt.
Exempelvis är await perfekt för en app /webb när du laddar olika delar av information + bilder att köra async. Lika så att skriva information / fel till en logg eller skicka meddelanden till en tjänst i bakgrunden.
Skrivet av Yoshman:
Minst två väldigt viktiga saker saknas:
[LIST]
[*]Moderna JVMer erbjuder sedan Java7 en långt mycket effektivare runtime-plattform än vad .NET har, framförallt kring multicore.
Nu kanske du missat att microsoft släpper roswell? Själv har jag inte hunnit testa eller läsa på om den så värst ännu, men den sägs vara kraftfull. Dessutom skall det vara ett öppet källkodsprojekt om jag inte mins fel vilket är rätt intressant.
Men jag måste också säga att jag håller med, multicore trådning har jag också uppfattningen om att java är effektivare på. Så har man en modul eller situation som är mycket prestanda intenstiv och tex inte är databehandling som troligen lämpar sig bäst i en databas där datan troligen redan är sparad, då är java bra.
Skrivet av Yoshman:
Det absolut vanligaste användningsområdet för LINQ är LINQ-to-objects. Java8 streams och LINQ har en del fundamentala skillnader, i det specifika fallet LINQ-on-objects så är streams LINQ-done-right. Båda är i grunden rotade i den funktionella världen, inte så förvånande i fallet LINQs då en av dess skapare Eric Meijer jobbat väldigt mycket med funktionell programmering. Men de är rotade ur olika delar, streams är typisk map/reduce vilket är förklaringen till varför det fungerar så väl i parallella-system, även GPUer som inte nödvändigtvis ens är cache-koherenta. LINQ kommer i stället från konceptet monad funktioner (vilket möjliggör saker som JOIN, något som är väldigt icke-funktionellt). PLINQ är inte i närheten lika effektiv som parallel-streams och givet utgångspunkten de designat med borde det inte förvåna någon.
[/LIST]
Då du kan både Java och C#, nämn en enda sak du kan göra med LINQ-to-objects som inte går att göra med ungefär samma arbetsinsats med Java-streams. Jämför sedan effektiviteten på din lösning, redan på en CPU-kärna är Java klart bättre, på multicore är den överlägsen.
För mig handlar det om enkelhet och läsbarhet och där tycker jag C# är bättre. Störst kostnad i de flesta system är ofta underhåll och att snabbt kunna läsa och ändra kod. Så beror lite på hur höga prestandakraven är, hur mycket data som skall behandlas.
Skrivet av Yoshman:
Finns helt klart trevliga saker, men om det bara handlar om finesser och hur kort man kan skriva något skulle alla gått till Scala. Språk som Java och C är inte populära trots att de saknar mer avancerade språkkonstruktioner, de är populära p.g.a. detta.
Prio#1 för .NET borde vara att jobba på runtime-plattformen, framförallt om molnet eller IoT blir i närheten så stort som spås.
Molnet, egentligen är det ju bara ett nytt namn på en gammal lösning, virtualiserad serverkraft. Det lämpar sig dock inte alltid bra, exempelvis har jag vissa kunder som pga säkerhet inte får eller vill lämna ut uppgifter till 3e part (tex amazon / ms). Men visst är det smidigt för vissa lösningar också.
Skrivet av Yoshman:
Tänk igen. Ihop med Javas inriktning mot effektiv parallellism och därmed mer funktionell modell enligt map/reduce så vore det fel väg att möjliggöra att returvärden också kan skickas via argument, för vilken annan vettig användning finns för pass by ref?
Generellt sett håller jag med om att by ref är onödigt och utgör också en risk.
Men i vissa situationer är det riktigt störande att sakna och kan vara kraftfullt.
Exempelvis håller jag just nu på att refakturera om en lösning med mycket logik redan skriven där objekt och delar av dem sätts om beroende på situation eller händelse och sätts om här och där.
Det är alltså legacy kod det handlar om.
Jag vill bryta ut rätt mycket kod från en gigant klass som i sig har ett gäng metoder som tar emot ny input och förändrar och utför arbeten på objekt som dessutom ibland sätts om helt, ibland efter en sparning eller inte...
Att i denna situation refakturera om och bryta ut logik till en annan klass utan att kunna använda ref.. är riktigt störande och slött. När jag blir klar har jag troligen inget större behov av ref, men just nu...
Sen finns det situationer med algoritmer där du vill sätta om ett gäng referenser och ändra pekarna hit och dit, då är ref smidigt.
Skrivet av Yoshman:
Varför irriterar du dig i så fall inte på att "extension methods" i C# inte har "dymanisk-dispatch", gillar man OOP borde det vara en riktig WTF! I Java diskuterande man väldigt läge att göra något liknande men alla förslag som hade "static-dispatch" som C# extension methods röstades ner då det finns en rad sätt att skjuta sig i fötterna. I Java8 kom till slut defender/default methods.
Det har jag inte sagt att jag inte stör mig på!
.net har sina brister också, inven tvekan om den saken. Men överlag går det snabbare att skriva tillräckligt effektiv kod som också är lätt att läsa och underhålla.
Som jag använder extensionmetoder så ofta är det mindre utökningar, som tex att utöka List med metoden addIfNotNull eller utöka med datumformateringar osv eller för att konvertera ett objekt jag fått från ett system till ett annat i det aktuella systemet.
Skrivet av Yoshman:
För att gå tillbaka till topic: det är definitivt stort om en så populär plattform som Java på ett vettigt sett man börja använda GPGPU (SIMD kan ses som ett specialfall av detta, vilket är precis vad t.ex. OpenCL gör). Utan något som är så pass enkelt lär det nog aldrig bli något en en relativt smal nisch.
Här hänger jag inte riktigt med, varken java eller c# är lämpligt för grafik. Eller tänkte du att du ville dra nytta av grafikkortetsberäkningskraft för att avhjälpa cpu?