Toepassing .NET in Longhorn beperkt

Nadat Microsoft eerder deze week de eerste beta's van de WinFX-API beschikbaar maakte, doet nu het gerucht de ronde dat daarmee meteen het leeuwendeel van de in Longhorn toe te passen .NET-code is bestreken. De bijzonder zware systeemeisen van Longhorn, die deels veroorzaakt zouden worden door een nog te traag en te instabiel managed code-model, zouden Microsoft namelijk genoopt hebben een flink deel van Longhorn nu toch maar met 'proven technology' te herbouwen. Het zou geen haalbare kaart zijn om alle functionaliteit in de .NET-omgeving te coden en toch voor eind 2006 een fatsoenlijk snelle en stabiele versie op de markt te krijgen. Nadat vorig jaar al het filesysteem WinFS werd geschrapt, lijkt dit de tweede grote tegenvaller voor het nieuwe besturingssysteem.

Versie 2.0 van het .NET-framework zal wel worden meegeleverd, en Longhorn-onderdelen als het grafische subsysteem Avalon en het communicatieplatform Indigo zullen daar wel gebruik van maken. Een anonieme developer laat weten dat hij de schijnbare stap terug geen slechte zaak vindt: 'Een groot voordeel is dat ontwikkelaars niet naar .NET hoeven over te stappen als ze de nieuwe Longhorn-features willen gebruiken'. Het bijbehorende nadeel is dat er op deze manier voorlopig nog geen einde komt aan de beruchte 'Win32 dll hell', het verschijnsel dat applicaties die van verschillende versies van dezelfde library gebruik maken elkaar in de wielen rijden. Een volledig op WinFX-technologie gebouwd OS had daar een eind aan kunnen maken. Een reactie van Microsoft blijft vooralsnog uit, maar de softwaregigant heeft nooit eerder hard toegezegd dat Longhorn wél volledig op .NET gebaseerd zou worden.

Reacties (57)

[Yoeri]

Jammer. WinFX was eigenlijk de nieuwe programmeerinterface (API zeg maar) die volledig in managed C#-code geschreven zou worden. Dit werd blijkbaar te belastend voor de systemen die tegen de lanceringstijd van Longhorn beschikbaar zouden zijn. Gelukkig zijn de twee belangrijkste, en meteen ook de nieuwe, api's wel in managed code geschreven, zijnde Avalon en Indigo.

Het was eigenlijk misschien ook wel een beetje onrealistisch om in één klap de volledige Windows-API overboord te gooien en in .NET-code te herschrijven. Toch zet MS met Avalon en Indigo alvast een stap in de goeie richting hiervoor. Dat .NET-applicaties trager zijn klopt overigens niet helemaal volgens mij. Bij een eerste keer opstarten zijn ze trager, wat dat betreft zijn ze imho vergelijkbaar met java: een eerste keer opstarten is trager, maar alle volgende runs gaan net lekker snel.
Dat het gebruik van managed code invloed heeft op de prestaties kan ik me weer wel inbeelden.

-- EDIT --

Ik vraag me echter af in hoeverre die nieuwe .NET-gebaseerde grafische de zaak gaat vertragen (Kun je die niet uitzetten???).

Er zijn verschillende grafische 'runlevels' die je kunt instellen afhankelijk van de mogelijkheden van je hardware. Bovendien is het volgens mij niet het weergeven van de grafische dingen die in managed code gebeurt, maar wel de volledige API om de grafische functies aan te roepen en dergelijke. Het lijkt mij niet zo te zijn dat ze zullen proberen een 3d-omgeving in C# te schrijven

[Boudewijn]

vind je dat zo erg?

Ik merk als programmeur (MFC, .NET en linux based spul) dat veel .NET progjes echt heel erg traag zijn.

Dit is ook te zien bij Java omdat beide platformen interpreted zijn, waardoor alles wat je draait een extra stap moet maken (de interpreter)....

En dat is dus niet zo snel; je merkt het niet bij zoiets als een rekenmachine-progsel maar bij een OS wel.

Ik vraag me echter af in hoeverre die nieuwe .NET-gebaseerde grafische de zaak gaat vertragen (Kun je die niet uitzetten???).

[sid3windr]

Sun's JIT compiling komt anders mooi in de buurt van native code; kan me niet voorstellen dat die van MS zo slecht is?

[DLGandalf]

ten eerste, de JVM zal altijd op moeten blijven starten..
ten 2e ik heb nog nooit een java programma gebruikt dat even snel was als een native gecode programma. met de JIT compiler is alles al wat beter geworden.. maarja daartegenover moet je wel wat(soms aanzienlijk) geheugen inleveren

[seweso]

Ja maar als je alles in het OS bakt dan is het al opgestart, daarnaast heb je theoretisch maar één garbage collector nodig en kun je al het geheugen gebruiken. Maar ja, dat is natuurlijk ook de reden waarom java op servers veel beter werkt, op een desktop word java klein gehouden.

[packman]

@All here over snelheid van Java/.NET

Ik ben vrij intensief bezig geweest met Java, het optimaliseren ervan, en bytecode in het algemeen (heb eigen interpreter en bytecode compiler geschreven).

Bytecode op zich is niet "traag", en een JIT kan en zal inderdaad de performance drastisch verbeteren, MAAR - er is een grote maar. Zowel java als C# (en veel .NET talen) hun manier om met strings te werken is niet echt voordelig voor de performance, en het is niet het enige wat de performance naar beneden haalt. Er zijn een hoop trade-offs voor flexibiliteit en veiligheid gemaakt waarbij er aan performance is ingeboet. Dit zit op zeer laag niveau, wat wil zeggen dat dit zelfs als dit door een JIT gedraaid wordt er een hoop overhead is tijdens runtime. Er zijn gewoon zowel in .NET algemeen als in Java een hoop concepten die niet goed samengaan met "high performance", hoewel daar hard aan gewerkt wordt (zie de nio interfaces in java).

Theoretisch zijn de concepten van .NET en Java prachtig, ze verschillen onderling niet zo heel veel (buiten dat .NET multilanguage bytecode is, wat heel mooi is) maar praktisch zijn ze nog steeds niet altijd haalbaar. Sun was extreem veel te vroeg met Java, op het ogenblik dat dit uitkwam was de kracht van de PC's veel te laag, en wogen de voordelen niet op tegen de nadelen (traagheid). Nu begint dit echter doenbaar te worden desktop applicaties te gaan schrijven in Java of .NET (zie Netbeans/Azareus/Paint.net/...). Integratie in de core van een OS van .NET lijkt mij echter niet haalbaar. Het is - zoals het artikel ook zegt - niet volwassen genoeg. Zelfs Java zou er nog problemen mee hebben vrees ik, hoewel nu de 1.5 een hoop enorme verbeteringen under the hood, maar dit was dan vooral onder druk van .NET. Java is al een pak volwassener, en mijn stelling die vele mensen niet geloofden - dat .NET niet volwassen is, wordt hierbij eigenlijk bevestigd.

[Verwijderd]

@DLGandalf
Het opstarten van een JVM is natuurlijk totaal irrelevant voor de performance. Die vertraging heb je namelijk slechts éénmalig ook als je een programma 8 uur per dag gebruikt......

En dat je geen ervaring hebt met snelle java programma's zegt meer over jou dan over java. JIT compilers bestaan namelijk al zo ongeveer sinds java beschikbaar is. Dat java programma's meer geheugen gebruiken? Vast wel, een JVM neemt nu eenmaal ruimte in, maar je hebt stukken minder last van memory leaks. Het op hol slaan van je geheugenbeheer zul je bij java programma's dan ook veel minder tegenkomen dan bij bijvoorbeeld C++

[Titusvh]

Als ontwikkelaar zou je ook weten dat het niet geïnterpreteerd wordt, maar JIT gecompileerd.

Dus de eerste keer inderdaad langzamer, maar daarna zelf mogelijk sneller omdat de resulterende machinecode precies op jouw OS en hardware kan worden afgestemd!

Er zijn overigens trucs om de gecompileerde code te gebruiken i.p.v. steeds de IL te compilen...


Voor de niet ontwikkelaars:

JIT compileren= Just In Time, code wordt pas gecompileerd als het nodig is.

IL = Intermediate Language: Dotnet compileert code tot IL. Deze IL is nog platformonafhankelijk en wordt verder JIT gecompileerd.

[florizla]

Java heeft natuurlijk ook een platformonafhankelijke 'IL', alleen is die wat ongelukkig 'Java bytecode' genoemd... Dus code tot IL compileren is niet enkel iets van .NET.

[Olaf van der Spek]

Jammer. WinFX was eigenlijk de nieuwe programmeerinterface (API zeg maar) die volledig in managed C#-code geschreven zou worden.

Dat een .net-style API beschikbaar zou zijn betekent toch niet dat de achterliggende code ook direct .net moet zijn?

[Verwijderd]

Dat een .net-style API beschikbaar zou zijn betekent toch niet dat de achterliggende code ook direct .net moet zijn?

Dat is ook wat ik in de eerste instantie dacht. Vergeet echter niet dat je iha niet razendsnel kunt switchen tussen native en vm code. Stel dat de hele .net api slechts een dunne wrapper om een native api was, dan -zou- het kunnen zijn dat door al die context switches (context in dit geval VM <-> native) de overhead toch nog behoorlijk groot is tov fully dynamic translated IL code.

Dit is slechts een aanname hoor, ik ben al een tijdje weg uit de MS wereld (wel veel gedaan met MFC en win32 altijd), maar gevoelsmatig zeg ik dat dit wel eens mee zou kunnen spelen.

[Verwijderd]

In .NET is de VM geen interpreter nee. IL Code wordt -altijd- gecompiled. Het blijft echter -wel- een VM, anders was het hele .NET concept niet meer dan een volledig automatisch make/build process.

Types kunnen bijvoorbeeld niet willekeurig zijn binnen de VM, maar moeten bepaalde high-level kenmerken hebben. Daarom konden C++ templates niet zonder meer naar IL code gecompileerd worden en van daar naar native.

Ik weet niet precies hoe het in .Net zit. Ik weet iniedergeval wel dat de Java VM ook haar code compileerd, en dat daar native calls wel altijd duur zijn.

[Olaf van der Spek]

context switches (context in dit geval VM <-> native)

De VM is toch geen interpreter? Volgens mij zijn dat soort 'context switches' helemaal niet zo duur.

[Xenan]

Volgens mij zijn dat soort 'context switches' helemaal niet zo duur

Toch wel. Typen moeten ge-unboxed en geboxed worden, telkens als je over de CLR boundary gaat.

[Verwijderd]

Conclusie : hetgeen al veel mensen veel langer zeggen, Longhorn gaat niet meer dan een beefed-up XP zijn met belachelijke hoge systeemeisen en wat je ervoor terugkrijgt is minimaal beter dan XP nu.

De mogelijke grafische gadgets niet meegerekend...

[Superstoned]

...en die gadgets vallen ook in het niet bij mac OS X en (in mindere mate) linux.

[Verwijderd]

Knap dat je conclusies kunt trekken van iets wat nog niet bestaat.

Als je zo telepatisch en helderziend bent mag je me wel vertellen wat de komende 5 jaar gaat gebeuren op alle gebieden.

[Verwijderd]

Ik baseer me gewoon op de grote beloftes die Microsoft deed toen de eerste meldingen van Longhorn bevestigt werden door hen, en hetgeen er ondertussen officieel van overschiet.

Het verschil is inmens en helemaal niet positief voor Microsoft.

En ik kan niet voorspellen wat er over 5 jaar allemaal gaat gebeuren... ik eigen mezelf die pretentie niet toe om te denken dat ik dat kan.

Dit in tegenstelling tot meneer Gates... 640K ought to be enough for everyone.... remember ?

[Gepetto]

Dit in tegenstelling tot meneer Gates... 640K ought to be enough for everyone.... remember ?

(zucht)

Iedereen die wat vaker op Tweakers rondhangt weet inmiddels dat Bill Gates deze uitspraak nooit heeft gedaan.

(nl.wikipedia.org/wiki/Hoax)

[Verwijderd]

Wordt dan maar een magere koe dan.
Zo'n beetje alles wordt eruit gehaald omdat het niet haalbaar blijkt te zijn en microsoft heeft een nieuwe OS beloofd.
Nou ja nieuw OS. Nieuwe eyecandy en ouwe wijn in nieuwe zakken.
Hoeveel duizenden programmeurs hebben ze ook al weer?

[Verwijderd]

Het bijbehorende nadeel is dat er voorlopig nog geen einde komt aan de beruchte 'Win32 dll hell', het verschijnsel dat applicaties die van verschillende versies van dezelfde library gebruik maken elkaar in de wielen rijden.

Juiste DLL naast je EXE zetten -> opgelost! Het nut van DLL's is dan wel weg maar ja wie geeft er nog om een halve megabyte meer vandaag?

Nog beter is natuurlijk om van in het begin een DLL te gebruiken die een of ander versiesysteem gebruikt, goeie oude COM bijvoorbeeld.

'k Wil maar zeggen: 'DLL hell' is reëel maar er zijn voldoende manier om het te voorkomen, mits een beetje bewustzijn van het probleem. Hopelijk zorgt Microsoft er dan ook voor dat het probleem gereduceerd blijft in Longhorn. Alles overschakelen naar .NET zou het probleem vervangen met iets dat vaak erger is; een sloom besturingssysteem. En dat gaat niet weg met een simpele DLL patch...

[Verwijderd]

Juiste DLL naast je EXE zetten -> opgelost! Het nut van DLL's is dan wel weg maar ja wie geeft er nog om een halve megabyte meer vandaag?

Maar het is toch belachelijk dat je het hele nut van DLL's moet omzeilen om het veilig te kunnen gebruiken in die situaties? Bovendien zijn er ook systeem DLL's die verplicht uit de win directory worden gelezen en niet uit de programmamap.

Wel grappig dat we nu kunnen zeggen dat longhorn "unmanaged code" bevat. De belachelijke term die MS graag uit over code die zich nog niet naar hun opeens verzonnen nieuwe systeem geschikt heeft. De truuk van die term die alle niet .NET code opeens slecht laat klinken, bijt hun nu zelf terug!

[Verwijderd]

Maar het is toch belachelijk dat je het hele nut van DLL's moet omzeilen om het veilig te kunnen gebruiken in die situaties?

Ja, ik wou enkel een paar voorbeelden geven van mogelijke oplossingen van de 'hell'. Liever een "belachelijke" oplossing dan dat.

Bovendien zijn er ook systeem DLL's die verplicht uit de win directory worden gelezen en niet uit de programmamap.[/quote]

Voor zover ik weet is elke DLL in de system32 map beveiligd tegen veranderingen. Windows houdt een kopie bij van de vorige versie, die meteen wordt teruggeplaatst. Probeer maar eens bijvoorbeeld d3d9.dll naar je desktop te verslepen. Enkel installatieprogrammas krijgen toegang tot die bestanden, plus andere beperkingen, wat het probleem al sterk reduceert.

Wel grappig dat we nu kunnen zeggen dat longhorn "unmanaged code" bevat. De belachelijke term die MS graag uit over code die zich nog niet naar hun opeens verzonnen nieuwe systeem geschikt heeft. De truuk van die term die alle niet .NET code opeens slecht laat klinken, bijt hun nu zelf terug!

Bij mij had 'managed code' al een slechte bijklank. Ik wil niet dat mijn code 'beheert' wordt door iets anders, ik wil elke instructie rechtstreeks op de processor uitvoeren. Voor webapplicaties is .NET super, maar voor applicaties die klassiek in C/C++ worden geschreven is .NET geen optie...

De conclusie: Gebruik de dingen enkel waarvoor ze hun nut bewijzen (gaat veel verder dan .NET). Gelukkig is ook Microsoft daar nu achter gekomen. Maar ja, marketing en de technische afdelingen komen zowiezo niet altijd overeen.

[Olaf van der Spek]

Ik kan me eerlijk gezegd niet herinneren ooit last te hebben gehad van 'DLL hell'.

[Dreamvoid]

Jij als eindgebruiker misschien niet, maar als developer is het wel degelijk een groot probleem. Op Linux en consorten kom je er als eindgebruiker misschien wat eerder mee in aanraking ("dependency hell") omdat het veel modulairder is, maar dat wil niet zeggen dat het in Windows niet bestaat. In Longhorn was het idee om met een compleet managed code model in een keer van die hele ellende af te zijn. Probleem is dat niemand ooit zo'n complex geheel als de complete Windows API als managed code framework heeft ontwikkeld, en MS komt er blijkbaar nu achter dat het misschien een veel te ambitieus plan is. Dan hebben ze 2 opties: ofwel Longhorn traag en half af op de markt brengen zodat iedereen in elk geval alvast mee kan werken, en dan in stappen optimaliseren (zoals Apple met OS X deed), of wachten tot ze het helemaal af hebben en in de tussentijd op "proven code" doorbouwen. Allebei de opties zijn niet ideaal...

[Verwijderd]

Als professional zou je .NET helemaal niet moeten vergelijken met PHP. Dat is appels en peren vergelijken.

Of kun jij voor PHP al Windows applicaties ontwikkelen?

[cavey]

nou.. ze zijn toevallig bezig met een gtkphp projectje...

http://gtk.php.net/

en je kan genoeg command line programma's maken met php analoog aan allerlei perl scripts, bash scripts etc...... php is niet puur en alleen voor webpagina's. Veelgemaakte denkfout

dus "windows programma's" mbv. php zit er aan te komen. Zie ik het ASP framework nog niet zo snel doen .... (of vergis ik me daar, door ook niet verder dan m'n HTTP neus lang is te kijken?)

[prototype]

@cavey:
Je hebt .NET in twee varianten, namelijk ASP.NET en 'gewoon' .NET respectievelijk voor webapplicaties en voor 'windows' applicaties.
Het is niet een andere 'taal' of wat dan ook, slechts andere toepassingen, vergelijkbaar met java en jsp. Ze maken dan ook veelal gebruik van dezelfde libs, en dat heeft samen met taalonafhankelijkheid voordelen. Zo kun je dus logics van je 'windows' applicaties ook integreren in je webapplicaties, en daarbij maakt het niet uit of de classen nou in VB.net geschreven zijn of in C# danwel J#, aangezien er sprake is van een common language interface.

[EfBe]

er is 1 .NET, geen 2. ASP.NET en winforms en andere zaken gebruiken dezelfde .NET assemblies. Dus wat jij zegt klopt van geen kant.

[Xenan]

Dat is idd appels met peren vergelijken, maar misschien bedoelt Harde Willy (ASP).NET ten opzichte van LAMP (Linux, Apache, MySQL, PHP) en dan gaat de vergelijking wel aardig op.

[prototype]

PHP kun je gebruiken om GTK applicaties te ontwikkelen waarvoor nog een runtime environment voor nodig is, net als dat bij .NET applicaties het geval is.

[MikeyMan]

Ben ik de enige die dit niet jammer vind? Een groot gedeelte .net toepassingen die ik tot nu toe tegen ben gekomen draaien echt bagger traag, en zo slecht ben ik nu ook weer niet bedeeld hier.

[tser]

Dat is dus gewoon onkundig gebruik van de ontwikkel tooling, wat je niet moet vergeten, is dat de afgelopen paar jaar, een aantal "omschoolde mensen" een poging heeft gedaan om te programeren. Oneerbiedig gesproken, er zijn een stelletje PRUTERS nog altijd in de omloop, bij elk (al dan niet inhuur) bedrijf. Waar je tranen van in je ogen krijgt als je de code onderogen ziet.

Wie begrijpt waar hij mee bezig is, fatsoenlijk codeert, en ook nog even netjes een stress test met een paar honderd, paar duizend, of nog veel meer, clients op zijn applicatie los laat, Krijgt .Net applicaties, waarvan je beseft, hoe dankbaar je ben voor .net

Het probleem van .net is dus eigenlijk dat de drempel om er wat mee te maken, te laag is

Want wie thuis iets aan de gang krijgt met .net, is het nog niet waard om verantwoordelijk zijn voor bedrijfs critische applicaties.

[ReLexEd]

Want wie thuis iets aan de gang krijgt met .net, is het nog niet waard om verantwoordelijk zijn voor bedrijfs critische applicaties.

Dat geldt toch zeker voor elke programmeer- taal/omgeving?

Net zoals dat niet iedereen die ooit eens met Word een webpagina heeft gefabriceerd een webdesigner is?

Waarom denk je dat softwarehuizen die zichzelf serieus nemen een zogenaamde style-guide opzetten?
Daarin kunnen ze vastleggen hoe applicaties van hun hand opzetten, hoe (en ook belangrijk waarom) er bepaalde code-structuren zijn aangelegd...

Zelf heb ik een aantal jaren geleden bij een bedrijf gewerkt dat zo'n guide aan het opzetten was, en daar werden de programmeurs er gewoon allemaal bij betrokken, en wisten ze uiteindelijke een guide te creeren waarin beschreven stond hoe de programmeurs daar te werk gingen.
Dat zorgde er op zijn beurt voor dat de programmeurs makkelijker elkaars code konden overnemen omdat er min of meer gestandaardiseerd werdt geprogrammeerd...

[ocdaan]

Wat dat betreft heb je helemaal gelijk maar toch vind ik .net wel ok, ik gebruik het nog niet professioneel maar heb er al wel mee gespeeld. Met name voor het maken van webapplicaties vind ik de volwassen programmeertaal toch beter als het beperkte asp waarmee ik nu werk.

Groet, D.

[Verwijderd]

JIT compilatie in een OS...
Lijkt MIJ een nekslag voor je performance.

[Verwijderd]

De Crusoe processor werkte ook zo. Daar werd het complete OS ge-jit. (OS zelf dacht dat het op een x86 draaide). De snelheid was best behoorlijk, maar idd geen racemonster.

[exyll]

En daarom kun je dus ook pre-jitten zodat er niet gecompileerd hoeft te worden.

[Verwijderd]

Als .NET programmeur als professional, wil ik toch benadrukken dat dit niet de slechtste zaak van MS de voorbije jaren. ik zou zelfs het tegendeel durven beweren. misschien heb je voor .NET iets meer verstand en kennis nodig dan dat een doorsnee PHP programmeur heeft van zijn code.
begin nu geen flame-war van PHP is beter dan .NET of andersom, want ieder heeft daar zijn eigen visie over. ik kan alleen maar zeggen wat ik zelf dagelijks zie en te horen krijg. ik denk niet dat bedrijven als Siemens, Alcatel, Sidmar, NMBS, enz hun eigen zo hard vergissen als ze voor .NET kiezen. Er zijn natuurlijk een tal ander bedrijven die dan weer de PHP kant opgaan. As I Said, ieder het zijne.
Betreft Longhorn vind ik het weer zeer spijtig, ze hebben ons zoveel beloofd en uiteindelijk schiet er weer maar een peulschil van over. Blijft MS ons nu bedriegen Alhoewel ze Whidbey dat dan weer net niet doen.
Het verstandigste zal zijn om gewoon niet in te gaan op al deze berichten en gewoon de tijd af te wachten totdat ie er is. En dan zullen we nog eens babbelen.
Per slot van rekening zal iedereen het toch weer een slecht OS vinden en er een jaar later vlot mee werken

[Verwijderd]

De keuze van grote bedrijven is de laatste jaren heel vaak alles behalve logisch te noemen.

Logisch in de zin dat ze slaafs Microsoft volgen, niet logisch als je naar de technische kant van de zaken kijkt.

En nee dit is niet als flame bedoelt, maar er zijn nog altijd bedrijven die Windows als OS nemen voor mission critical server systemen... Dat zegt toch allemaal genoeg ? Idem dus voor hun company keuze van programmeertaal.

[arjankoole]

maar er zijn nog altijd bedrijven die Windows als OS nemen voor mission critical server systemen... Dat zegt toch allemaal genoeg

Windows kun je best mission critical laten doen, mits je alles goed inregelt, opbouwt en ontwerpt. Fact of the matter is alleen, dat het je gigantische klauwen met geld kost aan hardware en licenties, wat het dan wel onrendabel maakt, dan wel een toekomstig doelwit voor bezuinigingen, wat mogelijkerwijs afbreuk doet aan de integriteit van het platform. (platform is hier specifiek design voor een specifieke applicatie dan wel organisatie).

daarnaast heb je nog de gedachtengang bij managers e.d. dat mission critical alleen door gecertificeerde besturingsystemen gedaan kunnen worden, zoals Windows, Solaris, HP-UX, AIX. Ik als (voornamelijk opensource) unix beheerder moet nog regelmatig proberen mensen te overtuigen dat FreeBSD en Linux wel degelijk hele goede alternatieven zijn. (en daar heb ik behoorlijk wat bewijs voor inmiddels).

[Verwijderd]

Ik kan de keuze voor .NET wel begrijpen. Je bespaart echt heel veel ontwikkeltijd en je kunt veel gemakkelijker overzichtelijk werken.

Blijkbaar is het vertrouwen in de ontwikkelingen van hardware van de beslissers in de ICT wereld groot.

[lzandman]

Ik snap niet dat je als zelfbenoemde ".NET professional" begint over .NET vs. PHP. Da's toch appels met peren vergelijken? .NET is een compleet framework met zeer geavanceerde mogelijkheden. PHP is alleen maar een (web)scripting-taaltje. Je zou nog enigszins de vergelijking tussen ASP.NET en PHP kunnen trekken, maar ook dat is weer een wereld van verschil.

Ik weet wel dat je met PHP ook in beperkte mate desktop software zou kunnen maken (command-line progjes enz.), maar dat doet volgens mij helemaal niemand.

Dat .NET-framework is in mijn ogen juist een van de beste dingen die Microsoft de laatste jaren geproduceerd heeft. Een heel compleet ontwikkelframework en in combinatie met bijv. Visual Studio ook nog eens een ontzettende handige omgeving voor het in zeer korte tijd ontwikkelen van geavanceerde applicaties.

Overigens ben ik niet anti-PHP (gebruik het nog regelmatig voor diverse websites). Maar ik wordt zo moe van al die mensen die .NET met PHP gaan vergelijken, want dat slaat helemaal nergens op.

[digifun]

Ik blijf het toch erg raar vinden dat een nieuw besturingssysteem net zoveel computerkracht nodig heeft als waar we een paar jaar geleden kernexplosies mee simuleerden.

[EfBe]

De bijzonder zware systeemeisen van Longhorn, die deels veroorzaakt zouden worden door een nog te traag en te instabiel managed code-model, zouden Microsoft namelijk genoopt hebben een flink deel van Longhorn nu toch maar met 'proven technology' te herbouwen.

Kolder.

Indigo anyone? er zit erg veel managed code in longhorn, om 1 enkele reden: security.

Verder is .NET niet 'instabiel' en in veel gevallen ook echt niet traag. Of gebruikt de schrijver van het nieuwsitem een andere .NET dan de rest van de wereld?

Versie 2.0 van het .NET-framework zal wel worden meegeleverd, en Longhorn-onderdelen als het grafische subsysteem Avalon en het communicatieplatform Indigo zullen daar wel gebruik van maken.

Nee, longhorn krijgt .NET 3.0 is de bedoeling (in ieder geval een versie hoger dan .NET 2.0)

FB, C# MVP