Microsoft Visual Studio 2022 stapt over op 64bit en komt eind dit jaar uit

Microsoft heeft Visual Studio 2022 aangekondigd. Het programma voor softwareontwikkelaars wordt 64bit en belooft sneller en toegankelijker te zijn dan zijn voorganger. Een preview wordt deze zomer uitgebracht, eind 2021 volgt de releaseversie.

Dat maakt Microsoft bekend in een blogpost. De nieuwe versie van Visual Studio wordt sneller, toegankelijker en meer lichtgewicht, zegt het bedrijf. Voor het eerst zal Visual Studio een 64bit-applicatie zijn, 'zonder 4GB-beperking in het devenv.exe-proces', schrijft Microsoft. Door over te stappen op 64bit denkt Microsoft dat het makkelijker moet worden om grote, complexe applicaties te openen, bewerken, draaien en debuggen zonder tegen geheugenproblemen aan te lopen. Ontwikkelaars kunnen nog steeds 32bit-applicaties ontwikkelen in Visual Studio 2022.

De nieuwe versie van Visual Studio krijgt een nieuwe interface, waardoor het minder ingewikkeld moet ogen dan de huidige versie, stelt Microsoft. Er komen nieuwe iconen, nieuwe thema's en een nieuw font, Cascadia Code. Ook krijgt Visual Studio 2022 meer ruimte om het integrated development environment naar eigen smaak aan te passen, al vertelt Microsoft nog niet hoe dat precies eruit zal zien.

Visual Studio 2022 krijgt verder ondersteuning voor cloudapplicaties met Azure, waardoor het makkelijker moet zijn om met repositories te werken in Visual Studio. En ook krijgt de software volledige ondersteuning voor .NET 6, waaronder voor .NET MAUI voor het ontwikkelen van cross-platform apps voor Windows, Android, MacOS en iOS. Visual Studio krijgt daarnaast een hot reload-optie voor .NET, zodat ontwikkelaars veranderingen kunnen aanbrengen in code zonder dat ze moeten herstarten.

Ook krijgt het volledige ondersteuning voor C++ met productiviteitstools en IntelliSense. Daarnaast wordt er ondersteuning ingebouwd voor CMake, Linux en WSL om het makkelijker te maken om cross-platform apps in C++ te ontwikkelen met Visual Studio.

Microsoft voegt aan Visual Studio 2022 meer mogelijkheden toe voor gezamenlijk werken aan projecten, onder andere met nieuwe ondersteuning voor Git en GitHub. Microsoft introduceert ook Live Share, waarbij er een geïntegreerde tekstchat komt om gesprekken te hebben over de code van projecten, zonder van context te hoeven wisselen. Live Share brengt ook de mogelijkheid om sessies in te plannen voor samenwerken, waarbij dezelfde link kan worden gebruikt voor terugkerende sessies, zoals wekelijkse samenwerkingsafspraken.

Ook de Mac-versie van Visual Studio krijgt een update, met plannen om over te stappen naar 'native macOS UI', met als doel dat het programma beter werkt op de Mac en zodat de software gebruik kan maken van ingebouwde macOS-features. Nieuwe menu's moeten de Windows- en Mac-versies van Visual Studio dichter bij elkaar brengen. De Mac-versie krijgt ook de nieuwe Git-ervaring, met een Git Changes-toolvenster.

Reacties (89)

[R4gnax]

Microsoft introduceert ook Live Share, waarbij er geïntegreerde tekstchat komt om gesprekken te hebben over de code van projecten, zonder van context te moeten wisselen. Live Share brengt ook de mogelijkheid om sessies in te plannen voor samenwerken, waarbij dezelfde link kan worden gebruikt voor terugkerende sessies, zoals wekelijkse samenwerkingsafspraken.

LiveShare is al lang beschikbaar voor VS 2019.
Eerst als optionele extensie die MS ongevraagd naar gebruikers duwde.
Toen als verplichte extensie die met een update mee geinstalleerd werd; die je nog wel uit kon zetten, maar niet meer kon deinstalleren.
En sinds een paar updates is het klaarblijkelijk niet meer een extensie maar gewoon ingebouwd.


Het werkt voor geen meter.
Het maakt het opstarten van VS 2019 suuuu---per sloom (geverifieerd toen het nog een extensie was die je uit kon zetten: maakt letterlijk 1 minuut verschil in het laden van een grote C# solution, alleen zou niet weten waarom en wat dat kreng dan onder de kap aan het doen is)
Oh - en het is een fucking instabiel stuk broddelwerk wat voor 'tig exceptions in allerlei andere stukken code van VS 2019 zorgt. Nieuwste pareltje is dat het een crash veroorzaakt in de Test Explorer als je een unit test suite draait in Debug mode; één van de tests breekt; en VS 2019 wil het file waar de test in zit openen om te stoppen op het breakpoint waar de assert faalt.

Dus... tenzij MS heel; heel; HEEL veel zeilen bij heeft gezet om van deze shit-show nog iets te maken, is LiveShare niet iets waar je als developer blij van hoeft te worden.

[Wolfos]

Het zou eens tijd worden. Zelf ben ik door Visual Studio's traagheid al lang op Rider over gestapt, en ik kan me voorstellen dat veel meer mensen dat gedaan hebben.

De 64-bit versie hadden ze 10 jaar geleden al moeten doen.

[Reactie gewijzigd door Wolfos op 23 juli 2024 03:08]

[D-Raven]

64 bit gaat het denk ik niet sneller maken. Grootste probleem met de snelheid is dat veel van de plugins en andere IDE integraties op de UI thread draaien.

Hier zijn ze al langer mee bezig om dit op te lossen. En misschien is daar in deze release ook iets aan gedaan. Maar puur het overstappen op 64bit gaat dat niet oplossen.
Hier hebben ze in het verleden al meerdere blogpost aan gewijd.

[Wolfos]

Ze zeggen zelf dat het de prestaties bij grote projecten moet verbeteren.

Die blogposts in het verleden waren gewoon smoesjes. Visual Studio is verreweg de laatste ontwikkelsoftware die nog op 32 bit draait. De meesten zijn al 10 jaar over.

[Reactie gewijzigd door Wolfos op 23 juli 2024 03:08]

[SillieWous]

Wat maakt het uiteindelijk uit of je IDE 64bit draait? Voor 99.9% van de gevallen is het totaal nergens voor nodig. Op het moment dat je het nodig zou hebben, kun je waarschijnlijk de boel beter op splitsen in kleinere projecten, wil je het overzicht bewaren.

Dat veel andere IDE's 64bit draaien is ook logisch aangezien ze niet dezelfde omvang en historie hebben als VS. Een project van 5 jaar oud omzetten naar 64bit is vele malen gemakkelijker dan een 25 jaar oud project.

[beerse]

Zelf heb ik wat zitten prutsen met software in de tijd van de 16-bits machines. In die tijd was het grootste probleem het draaien van een debugger rond de applicatie. Als/zodra de applicatie zo groot is dat ze meer dan de helft van het adres bereik gebruikt, moet de debugger al moeite doen om de applicatie te bevatten.

Bedenk dat een IDE iets heel anders is dan een tekstverwerker. In de regel is het een verzameling van ontwikkel, bouw en test tools: editor, compiler, linker, debugger en alles bij elkaar. Die moeten gegevens aan elkaar overbrengen over de applicatie die wordt ontwikkeld. Natuurlijk is het goed mogelijk om met een 32 bits applicatie een 64 bits applicatie te ontwikkelen. Maar een 64 bits applicatie om een 64 bits applicatie te ontwikkelen is veel makkelijker.

[MSalters]

De Visual Studio debugger is al lang een separaat sub-proces. Dat is ook waarom je een 64 bits proces kunt debuggen in 32 bits Visual Studio, of hoe je remote kunt debuggen, of hoe je Linux executables kunt debuggen.

[PolarBear]

1600 projecten laden, het is niet een use case die elke dev tegenkomt zullen we maar zeggen.

[Motrax]

Probeer maar eens een SSDT database project te openen, met 1000+ tabellen. En een beetje database heeft dat wel... Met de laatste versies is het wel beter geworden, maar je kan VS2019 niet uitschelden voor snel!

[Friemel]

Een beetje database heeft 1000+ tabellen ?!?!

Dat is een beetje overdreven. Ik heb met forse databases gewerkt en die hadden minder dan 1000 tabellen. Soms is het ook slecht ontworpen als er zoveel tabellen zijn.

[Raymond Deen]

Atomic design doorgetrokken naar de database
Dan heb je voor elk uniek identificeerbaar gegeven een aparte tabel gemaakt die dan weer gerelateerd wordt aan andere tabellen die weer relateren aan andere tabellen, enz, enz. Overerven op databases is volgens mij minder efficiënt dan met objecten en ik denk dat een database die zo veel tabellen bevat veel beter opgehakt zou worden in losse databases die data bevatten die echt wat met elkaar te maken hebben.
Of hij moet het datagram eens laten zien en ons allemaal verrassen.

[raptorix]

Ik doe nu een migratie van Oracle Database naar SQL Server, 10K tabellen en 8 Terrabyte aan data
Gelukkig hoeft alleen de data over en niet de functionaliteit

[david-v]

Een beetje database 1000+ tabellen? Ik heb met wat grote applicaties en bijbehorende databases gewerkt, maar 1000+? Nee, dat is niet echt "standaard" scenario.

[pleiadian]

Genoeg databases gezien met 1000+ tabellen. Bij mijn huidige opdrachtgever werk ik met een applicatie met 3600 tabellen op een Oracle Enterprise database. Daar wordt volop in VS ontwikkeld.

[nubro01]

De vraag rijst, waar staan die tabellen, in welke dataspaces? Allemaal op dezelfde schijf of NAS, waar staan de indexen en waar staat de logfile? De meesten weten niets eens waar hun tabellen fisiek staan, omdat tegenwoordig alles voor de meesten een blackbox is en opslag onder beheer valt van een andere afdeling.

[Oxidda]

Idd 64-bit gaat het niet sneller maken. Verre van, memory adressen worden 2x zo groot alleen al. Er komt meer overhead bij kijken en meer RAM tot je beschikking resulteert niet in meer performance, verre van.

In 2016 was er een MSDN post hierover, voor diegene die wat meer achtergrond info willen mbt waarom VS zolang geen 64bit was :
https://web.archive.org/w...re-no-64-bit-version.aspx

Basically kan er veel meer performance gehaald worden uit andere zaken dan meer RAM er tegenaan smijten.

[EraYaN]

Nouja meer RAM gaat dingen als ReSharper wel weer een stuk sneller maken, omdat het dan eindelijk gewoon in RAM past.

[JustFogMaxi]

R# draait nog gedeeltelijk in de UI thread. Echt een gedrocht van een applicatie. Heb 'm op het werk, maar meestal staat ie uit totdat ik ECHT nodig heb.

Ze zijn bezig die out of process te halen. Maar ze nemen de tijd daar bij Jetbrains...

[Robbaman]

Zoals ik het begrepen had liepen ze daar ook heel erg tegen de 32 bit 4GB memory limit aan. Mijn eerste gedachte toen ik dit artikel las was dan ook meteen of hiermee die gasten van R# niet zullen denken "Lekker, had dat even eerder gedaan, dan was dat out-of-process niet nodig geweest".

Ik neem tenminste aan dat de dingen die op de UI-thread draaien daar echt op moeten draaien. Ook binnen een in-process-model kun je immers dingen op een andere thread dan de UI-thread uitvoeren.

[Fluttershy]

ReSharper is dan ook de eerste die de kogel krijgt bij mij, precies om die reden.

[nubro01]

Jullie vergeten het belangrijkste verschil tussen X32 en X64. Het grotere adres bereik is qua move instructies natuurlijk groter maar duurt ook ietsje langer, maar jullie vergeten dat een Computer een rekenmachine is en niet alleen een geheugen verplaatser en vergelijker! Het aantal Registers is in X64 verdubbeld!!! dus geen 8 maar 16 registers van de verschillende soorten registers!
Register toegang is 1 klokcycle, geheugen toegang 100 cycles. We hebben het over minimale verschillen voor ons mensen, maar voor een Computer is 1 of 100 cycles een eeuwigheid.
Men beweerd dat een quantum computer zo veel sneller is dan de huidige, zou mij niet verbazen als die Quantum Computer nog meer dan 16 registers heeft, wat het verschil zou kunnen verklaren.

[Thomzh]

Dat van die quantum computer is nu wel een beetje appels met peren vergelijken.

[MSalters]

Nah, dat maakt niet uit. Moderne x86 CPU's hebben meer dan honderd hardware registers, ook in x32 mode. Het relevante voordeel van x64 is dat er 16 register names zijn, maar met register renaming worden die dynamisch naar de hardware registers vertaald.

[gast128]

Ik ken deze link en Microsoft's argumentatie van pointer grootte en daarmee de verhoogde druk op de (gelimiteerde) cache. De toolset (compiler / linker) is overigens al wel in 64 bit beschikbaar. Dat is geen overbodige luxe want met /LTCG nam de linker maar liefst 8GB in beslag.

[bbr]

En niet alleen dat - veel van de plugins zijn niet uit te zetten, en staan standaard altijd aan.
Of hebben een onderlinge koppeling, waardoor - al zou je er 1 uit willen zetten, zorgt een andere plugin dat hij weer aan gaat.

Zo bijvoorbeeld de git integratie.

[rko4u]

Interessante opmerking, alle plugins zullen waarschijnlijk opnieuw gebouwd moeten worden voor 64 bits. Dat gaat nog interessante problemen opleveren.

[Bigs]

Leuke van Rider is dat je meteen Resharper erbij krijgt wat voor mij toch wel een onmisbare tool geworden is moet ik zeggen. Voor C# development op macOS zeker de beste IDE.

[jerkitout]

Voor mij is het juist andersom. Vroeger was Resharper onmisbaar, maar nu zijn meeste refactorings mogelijk binnen VS. Resharper zorgt vaak voor ontzettend traagness. Ik vind het jammer dat het niet meer modulair beschikbaar is, ik zou graag alleen Resharper build en Resharper test gebruiken en al het andere meuk disablen.

[ManIkWeet]

ReSharper is vooral langzaam in VS (zal nu beter worden) in Rider merk je er vrij weinig van, aangezien die fatsoenlijk multithreaded werkt.

[Robbaman]

Ik meen op het R# forum gelezen te hebben dat het verschil vooral zit in het feit dat Rider 64 bits is en R# daardoor veeeeel meer dingen in cache kan houden. In VS is het ook al een aardige tijd mogelijk om plugins op een andere thread te laten werken, maar zolang ze in-process zijn, zijn ze wel gebonden aan de 4GB geheugenlimiet.

[Mijzelf]

traagness

Au. Ik zie mezelf niet als taalnazi, maar dit doet wel pijn.

[jerkitout]

Nederlands als tweede taal Wat moet het zijn?

[Reactie gewijzigd door jerkitout op 23 juli 2024 03:08]

[wind-rider]

traagheid

[SnijtraM]

logness

[realbart]

Het is toch loch Ness?

[xFeverr]

Op Mac wel, want VS for Mac werkt nog niet echt lekker. (al zou die 2022 versie ook weer flink beter moeten zijn volgens de blogpost.)

Op Windows heb ik Rider ook geprobeerd maar ik ben zelf toch meer gewend aan Visual Studio en dat is wel prima eigenlijk. Wat mij betreft gewoon de beste IDE.

[Niemand_Anders]

Rider heeft geen multi-monitor support. Die feature request staat al sinds 2011 open op hun forum. Ik heb zowel thuis als op kantoor drie monitoren. VS staat op monitor 2 (alleen code scherm + menu), monitor 3 bevat de windows als 1 docking window (full screen). Waarbij ongeveer 25% aan de linker kant wordt opgeslokt door the solution explorer, team explorer and properties windows. Het resterende deel is voor de build & run, output, unit test sessions, stace trace explorer, error list en debug windows..

Op monitor 1 draaien alle andere applicaties (git bash, browsers, cmd, SSMS, RoyalTS, postman, etc).

Ik hoop echter wel dat Microsoft eerst hun nieuwe git window heeft voltooid voordat deze verplicht wordt gesteld. Momenteel kun je de oude git window terug krijgen door 'new git user experience' bij preview settings uit te zetten. Waarom preview features standaard enabled zijn kan niemand ons vertellen. Echter in VS 16.9.4 kun je nog steeds geen work items koppelen aan een git commit. Bij ons moeten alle commits aan een work item worden gekoppeld. Anders wordt de commit niet aan de server kant geaccepteerd (policy rule) bij een push.

Ik hoop echter wel dat Microsoft niet te veel aan VS aanpast wat betreft interface aanpast, want juist de interface van VS vind ik de beste van alle IDE's. De traagheid bij grote projecten (en af en toe een crash) zijn voor mij veel minder een probleem dan het gemis aan multi-monitor support bij Rider..

[Korben]

Ik vind het gebrek aan multi-monitor support niet echt een gemis. Tool windows openen en sluiten voortdurend afhankelijk van je context, en daar heb je weinig last van. Het enige dat ik bijna voortdurend open heb staan is de solution explorer, maar dat is eigenlijk alleen nuttig als ik iets wil toevoegen of als ik iets zoek waarvan ik niet weet hoe het heet. Voor de rest: Find Everything.

[jimshatt]

Ik ben zelf voor het grootste deel overgestapt naar Visual Studio Code maar gebruik soms VS2019 nog.

Rider ziet er wel interessant uit, al vind ik het font niet geweldig op de screenshots, maar dat is vast aan te passen. Ik ga het zeker eens proberen!

[Senaxx]

Helaas zitten wij nog steeds aan visual studio vast voor SSIS en SSAS. Maar i.c.m. met TFS of Git is het echt een draak geworden. We werken er mee op een TS maar vaak is het is erg instabiel.

Helaas voor onze SSIS en SSAS development is er geen alternatief.

[terror538]

Zou mooi zijn als ze dan ook eens een recente versie van C zouden supporten.

[yade]

Ze ondersteunen nu al C17 en C++17, waarbij je ook al een preview optie hebt op C++20 features. Ik vind het best snor zitten met het ondersteunen van recente C en C++ versies.

[terror538]

Ik zie inderdaad dat C11 en C17 support recent met de release van 16.8 toegevoegd is, daarvoor is het tijden bal geweest zelfs C99 niet volledig gesupport iirc.

[Icelus]

C99 wordt nog steeds niet 100% ondersteund. Variable length arrays ontbreken bijvoorbeeld.

[MSalters]

Klopt, maar dat is een redelijk achterhaald feature. Het is geen toeval dat VLA's in C11 optioneel zijn gemaakt. Voor het soort kleine micro-controllertjes waar je C moet gebruiken omdat C++ te groot is, zijn VLA's ook niet handig.

[ANdrode]

Wat voor mij het relevantste is hier: Cascadia code.

cascadia code is open source en heeft (als je het wilt) ligatures en powerline symbols. Die moet ik een keer proberen

[Friemel]

Ik heb dit font al langere tijd in gebruik en het bevalt prima!

[Ferdinand Oeinck]

Weet je wat veel sneller zal gaan binnenkort in Visual Studio 2019 version 16.10 Preview 2?

Het uitvoeren van C++ code die in DEBUG mode is gecompileerd: 3x!

Debug mode performance improvements
Removed unnecessary overhead due to runtime checks. This may increase performance of your code compiled in debug mode by up to 3x.
https://devblogs.microsof...-version-16-10-preview-2/

[MeMoRy]

Binnenkort? Preview 2 is op 14 april gereleased.

[Jeffrey_KL]

Hopelijk werkt die versie stabieler dan de huidige versie. Man man man wat is dat een beestje om mee te werken. Git integratie blijft maar zeuren bij elke actie dat er iets fout ging maar toch lijkt alles goed te gaan. Automatisch referentie naar ander project toevoegen duurt lang?(Na 5 min zelf de referentie maar gelegd) En dan mijn favoriet: een panel die ik uit visual studio heb gesleept die nu niet meer terug gesleept wilt worden aangezien vs2019 dan gewoon doei zegt.

[R4gnax]

Hopelijk werkt die versie stabieler dan de huidige versie. Man man man wat is dat een beestje om mee te werken. Git integratie blijft maar zeuren bij elke actie dat er iets fout ging maar toch lijkt alles goed te gaan. Automatisch referentie naar ander project toevoegen duurt lang?(Na 5 min zelf de referentie maar gelegd) En dan mijn favoriet: een panel die ik uit visual studio heb gesleept die nu niet meer terug gesleept wilt worden aangezien vs2019 dan gewoon doei zegt.

Hey. Dat klinkt bekend. Ben je een tweede 'mij' of zo?
Ik heb de hoop op degelijke Git integratie ondertussen maar opgegeven. Doe tegenwoordig alles wat boven een simpele stage -> commit uitstijgt gewoon via de command line. Gelukkig heeft VS 2019 tegenwoordig net als VSCode een geintegreerde terminal. Deze loopt - helaas net zoals met veel andere features - nog hopeloos achter op VSCode, maar om met Git te werken is het goed genoeg.

[Proliges]

Ben benieuwd. Ik heb eigenlijk altijd ontwikkeld met Visual studio, werkt gewoon prima.

Dat het minder ingewikkeld wordt is altijd wel positief. Ben benieuwd.

[geoffrey.vl]

Ook de Mac-versie van Visual Studio krijgt een update, met plannen om over te stappen naar 'native MacOS UI', met als doel dat het programma beter werkt op de Mac en zodat de software gebruik kan maken van ingebouwde MacOS-features. Nieuwe menu's moeten de Windows- en Mac-versies van Visual Studio dichter bij elkaar brengen.

Aangezien ze spreken van een "native UI" vraag ik me af in welke mate ze nog zullen blijven verder bouwen op MonoDevelop, aangezien deze met het Gtk UI framework gemaakt is. De documentatie over MonoDevelop is de laatste 2j niet echt meer geüpdated, maar aan de git repo's te zien is het zeker en vast nog niet dood. Ik vraag me wel af hoelang dat nog gaat duren, nu MS de Mac gebruikers van MonoDevelop via deze weg probeert weg te snoepen, en MS met VSCode een redelijk deftig alternatief heeft voor de echte linux gebruikers.

[GertMenkel]

Ik denk dat MonoDevelop vooral was gekocht om C# op telefoons een hit te maken. Mono heeft weinig bestaansrecht voor Microsoft naast .NET Core, dus ik denk dat ze het liefste gewoon focussen op hun nieuwe technologieën en niet te veel aandacht meer willen besteden aan hun oude producten.

[rko4u]

Ik denk dat het juist andersom is en mono is gebruikt om .Net core op te bouwen.

[KRBM123]

Krankzinnig laat. Intussen heeft Apple ze met Xcode volledig gelapt door een jaar eerder een volledige ARM-versie van Xcode uit te brengen. En dan gaat het niet om een beta maar om een stabiele release.

[Reactie gewijzigd door KRBM123 op 23 juli 2024 03:08]

[BugBoy]

Ik programmeer al bijna 20 jaar in C#, maar de taal is wel heel erg uitgebreid geworden. Als je gepokt en gemazeld bent in C# dan is het wel een fijne taal. Ik merk echter dat collega's die er nieuw in zijn er erg veel moeite mee hebben. Ik vraag me niet af of de taal niet wat te complex is geworden. Ik programmeer sinds een tijdje ook in Java en Go. Nu hebben die ook zo hun eigenaardigheden, maar ze zijn wel wat toegankelijker dan C#.

Een aantal voorbeelden om het concreter te maken:

• Heel het async/await patroon is erg complex. Vooral als je te maken gaat krijgen met context (bijv. in WPF applicaties of oudere ASP.NET code). Daarbij is het een olievlek, want alle aanroepende code moet ook ineens awaitable zijn. Zo zijn er nog wel meer problemen (hoe ga je om met een functie die synchroon werkt en toch een exceptie wil gooien?). Een taal als Go heeft dat veel sjieker opgelost met go-routines.
• Lambda's zijn bijzonder krachtig, maar soms is een lambda "gewone" functie, maar op andere plekken wordt het vertaalt naar een expressie (bijv. IQueryable interfaces). Dat is aan de syntax vaak niet te zien en omdat het zoveel op elkaar lijkt geeft het heel veel verwarring.
• Waar een switch-case constructie nog heel basic was een aantal versies geleden, zijn die nu bijzonder krachtig geworden. Pattern matching, switch expressions, ... is allemaal mogelijk, maar als je begint met C# weet je amper nog wat je moet gebruiken.
• Niet zozeer C#, maar wel .NET gerelateerd is het gebeuren rondom de verschillen tussen .NET Framework en .NET Core. Als dat nog niet complex genoeg is bestaat er ook nog .NET Standard voor libraries die met beide compatibel zijn.
• Verschil tussen structs (stack-based) en classes (heap-based) was er al, maar nu zijn er ook nog weer records toegevoegd. Heel prettig, maar nog meer keuze-stress.

Als ervaren C# programmeur zijn heel veel verbeteringen erg fijn, maar instappen wordt steeds lastiger. De taal wordt langzaam toch weer bloated. Daarentegen zijn andere functies nooit in de taal doorgedrongen. Voor het implementeren van INotifyPropertyChanged (noodzaak in XAML based apps) is nog altijd iets als Fody noodzakelijk om dat niet elke keer met het handje te moeten doen.

Ook een fijne features in Typescript (ook Anders Hejlsberg) zoals automatisch declaratie en initialisatie van fields in de constructor zit niet in C# (deels opgelost met records). Vooral fijn in moderne applicaties die veel werken met DI. Nu heb je die variabele 3x (field declaratie, constructor parameter en field initialisatie) en in TS slechts 1x. Zal ook nog wel komen.

Ik snap dus de keuzes niet altijd. De nameof() heeft ook verschrikkelijk lang geduurd. Was geen Framework update voor nodig, dus er was eigenlijk geen reden om het niet eerder toe te voegen.

[Reactie gewijzigd door BugBoy op 23 juli 2024 03:08]

[Korben]

hoe ga je om met een functie die synchroon werkt en toch een exceptie wil gooien?

Gewoon, door een exception te gooien en die ergens op te vangen? Dat is juist het krachtige van async/await, dat exception handling werkt zoals je verwacht. Ofwel de functie die de Task (of ander soort awaitable) teruggeeft gooit een exception voordat die de awaitable teruggeeft, ofwel de exception treedt op bij de continuation.

[BugBoy]

Dat wordt een ander verhaal als je een Task teruggeeft maar de functie synchroon is. Komt wel eens voor als een asynchrone interface method implementeert. Dan wordt het weer Task.FromException als je geen async keyword gebruikt (geeft vaak een warning in non-async code). Probleem van async/await is vooral dat het heel eenvoudig lijkt, maar er zit heel achter... Steven Cleary heeft er een goed boek over.

[Korben]

Nergens voor nodig om Task.FromException te gebruiken; je kunt die exception gewoon normaal gooien. Het klopt dat de verwachting is dat zo'n exception asynchroon aankomt, maar dat is niet per se noodzakelijk. En als dat per se wel moet, dan kun je simpelweg de functie async maken; dat werkt beter dan Task.FromException, tegen de kosten van een wellicht onnodige state machine.

[BugBoy]

Als je de exceptie gewoon gooit, dan krijg je die synchroon terug en niet via je task. Heb je code die Task.ContinueWith gebruikt, dan komt die opeens op een ander moment. Dat is een vrij subtiel verschil, maar kan ander gedrag geven. Bij gebruik van ContinueWith kan dat problemen opleveren (die is sowieso al beter te vermijden i.v.m. nog meer complexiteit van schedulers en andere opties). Dat geeft precies aan wat ik in mijn originele post wou aanhalen. Het lijkt heel simpel, maar er zijn zoveel nuances dat er al gauw wat fout gaat.

Async/await is heel krachtig om een schaalbare server op te zetten of om taken van de GUI thread af te halen. Als schaalbaarheid niet het hoogste goed is in een applicatie, dan vind ik het tegenwoordig best een optie om het lekker synchroon te houden. Vooral in teams met wat minder ervaren programmeurs kan dat een goed idee zijn. Maak je een high-scalable reverse proxy server, dan is async/await een zegen. Ik heb nog het "oude" IAsyncResult gebeuren moeten gebruiken in schaalbare toepassingen en dat was pas echt een hel.

[PolarBear]

Huh? C#9 is september 2020 uitgekomen, C#8 in sept 2019, C# 7.3 in mei 2018.

[ManIkWeet]

Ja, maar dat was niet echt 'nieuw', meer een verfijning

[BugBoy]

Wellicht dat @ManIkWeet doelt op echt grote zaken, zoals generics, LINQ, async/await, ... Dat zijn uitbreidingen die je nu niet meer veel ziet. Het is toch veel syntactical sugar om het allemaal wat compacter op te schrijven. De echt grote zaken uit de laatste versies zijn eigenlijk ValueTask, readonly structs (Span<T>) en allemaal gebaseerd op performance. Voor de doorsnee C# programmeur niet altijd even relevant.

[MeMoRy]

Wat zou je willen? Je kan altijd dingen voorstellen.
Blijkbaar zijn er de laatste tijd geen grote vragen geweest vanuit de community voor nieuwe dingen.

Note dat het echter niet stilstaat. C# is meer dan alleen een taal. Het is ook de leider van .NET (VB is zo veranderd dat je C# naar VB en vice versa simpel om kan zetten). En op .NET gebied gebeuren zoveel dingen. Kijk bijvoorbeeld naar recent Blazor en de verbeteringen aan Entity Framework Core. Kijk naar de support van ARM64, linux, mac, etc.