C# op Linux

[Faloude]

3 jaar geleden wilde ik een website in elkaar zetten met C#, maar wel hosten op Linux. Destijds was "Mono" de IDE die je daarvoor kon gebruiken. Er waren wel wat haken en ogen.

C# vind ik een hele nette en snelle (precompiled) taal tov PHP.

Ik ben op zoek naar meningen en ervaringen hierin. Heb jij een C# of andere .NET project op Linux gehost? Zijn er alternatieven voor Mono? Is de ondersteuning verbeterd afgelopen jaren?

@Mods: kan dit omgezet worden naar een discussietopic?

[ Voor 6% gewijzigd door Faloude op 20-11-2019 15:50 ]

[Cyphax]

Microsoft heeft het roer een tijd geleden een beetje omgegooid en een nieuwe versie van .Net gemaakt die cross-platform is: https://docs.microsoft.co...requisites?tabs=netcore30
Je kunt op die manier je ASP.Net-project omzetten naar ASP.Net Core en hosten in bijvoorbeeld Apache: https://docs.microsoft.co...pache?view=aspnetcore-3.0
Het ontbreekt alleen nog een beetje aan een Visual Studio voor *Nix, maar VS Code is wel weer cross platform (al is dat natuurlijk een veel simpeler ding).

[3ddie]

Een beetje eigen research is wel handig. Tegenwoordig is er het .NET Core framework, dat draait op zowel Windows als Linux en MacOS.
Zie hier:
https://devblogs.microsof.../announcing-net-core-3-0/

[HaerdenCliff]

C# op Linux is behoorlijk volwassen geworden mede door de bijdragen van Microsoft aan het gehele project en zelfs de Linux kernel.

Mono is nog steeds the way to go.
Dit is de compiler: https://www.mono-project....ut-mono/languages/csharp/

Microsoft voorziet zelf een .net Core die je gratis kan downloaden als programeeromgeving.
https://dotnet.microsoft.com/download

Het geheel werkt best stabiel ondertussen, mijn ervaring zelf is dat integratie van AD soms lastig loopt en dat het vooral wel eens mis loopt in communicatie op wat lagere levels.

[Sandor_Clegane]

Faloude schreef op woensdag 20 november 2019 @ 15:49:
3 jaar geleden wilde ik een website in elkaar zetten met C#, maar wel hosten op Linux. Destijds was "Mono" de IDE die je daarvoor kon gebruiken. Er waren wel wat haken en ogen.

C# vind ik een hele nette en snelle (precompiled) taal tov PHP.

Ik ben op zoek naar meningen en ervaringen hierin. Heb jij een C# of andere .NET project op Linux gehost? Zijn er alternatieven voor Mono? Is de ondersteuning verbeterd afgelopen jaren?

@Mods: kan dit omgezet worden naar een discussietopic?

Werkt prima, heb er meerdere in productie. Dit met Giraffe op .Net Core in Docker op Ubuntu. Met C# zal het ook wel loslopen, ASP.net Core werkt mooi vlot als je gebruik maakt van Kestrel.

Ik zou er wel een Nginx reverse proxy voor zetten.

[BugBoy]

In het verleden al MONO gebruikt op Linux platformen en dat werkte prima, maar heeft een aantal nadelen. Het is wat trager dan C/C++, maar het grootste nadeel is dat je een runtime moet hebben en dat is lastig m.b.t. deployment. Vooral als er meerdere applicaties gebruik maken, dan krijg je meerdere versies van de runtime en die kunnen eventueel ook elkaar in de weg zitten.

.NET core maakt het al wat fijner, want daarmee kun je ook self-contained applicaties maken. Het is ook mogelijk om ze te packagen als één bestand, maar technisch gezien is dit een beetje een half/half oplossing. Een ander nadeel is dat de applicaties erg groot worden.

.NET core is interessant als je ontwikkelaars allemaal C# kunnen en het niet handig is om aparte talen te ondersteunen. Is dat niet zo nodig, dan kun je bijvoorbeeld ook eens kijken naar Go. Ook een krachtige taal en geeft wat compactere binaries.

[RobIII]

HaerdenCliff schreef op woensdag 20 november 2019 @ 15:54:
Mono is nog steeds the way to go.

Voor nieuwe projecten zou ik écht niet meer met MONO gaan lopen klooien. Gewoon .Net core 3.0 gebruiken.

BugBoy schreef op woensdag 20 november 2019 @ 16:36:
In het verleden al MONO gebruikt op Linux platformen en dat werkte prima, maar heeft een aantal nadelen. Het is wat trager dan C/C++, maar het grootste nadeel is dat je een runtime moet hebben en dat is lastig m.b.t. deployment. Vooral als er meerdere applicaties gebruik maken, dan krijg je meerdere versies van de runtime en die kunnen eventueel ook elkaar in de weg zitten.

.NET core maakt het al wat fijner, want daarmee kun je ook self-contained applicaties maken. Het is ook mogelijk om ze te packagen als één bestand, maar technisch gezien is dit een beetje een half/half oplossing. Een ander nadeel is dat de applicaties erg groot worden.

.Net core heeft nog steeds de runtime nodig. Sowieso een raar vergelijk dat je maakt.

BugBoy schreef op woensdag 20 november 2019 @ 16:36:
.NET core is interessant als je ontwikkelaars allemaal C# kunnen en het niet handig is om aparte talen te ondersteunen. Is dat niet zo nodig, dan kun je bijvoorbeeld ook eens kijken naar Go. Ook een krachtige taal en geeft wat compactere binaries.

TS vraagt toch specifiek om C#? Wat hebben C/C++ en Go hier dan allemaal mee te maken

[ Voor 71% gewijzigd door RobIII op 20-11-2019 16:56 ]

[Faloude]

Hele interessante toevoegingen in dit topic.

Wat een timing van mij om dit te vragen.
Release .NET core 3.0: 2 maanden geleden
Release .NET core 3.0.1: Gisteren

[whoami]

Je kan een ASP.NET Core website maken, en die 'gewoon' in een linux container op Azure draaien bv (Web Apps for containers).

[L01]

Faloude schreef op woensdag 20 november 2019 @ 16:56:
Release .NET core 3.0.1: Gisteren

Let op, dit is niet .NET Core 3.1 (LTS). 3.1 is nog in preview:

[Faloude]

whoami schreef op woensdag 20 november 2019 @ 17:00:
Je kan een ASP.NET Core website maken, en die 'gewoon' in een linux container op Azure draaien bv (Web Apps for containers).

Dat zou echt mijn hele idee verpesten van een razendsnelle webframework op een veilige, betrouwbare open source server OS.

[whoami]

Faloude schreef op woensdag 20 november 2019 @ 17:02:
[...]

Dat zou echt mijn hele idee verpesten van een razendsnelle webframework op een veilige, betrouwbare open source server OS.

Hoezo ? De Azure App Service resources kunnen gewoon linux draaien

[ Voor 21% gewijzigd door whoami op 20-11-2019 17:20 ]

[Hydra]

Faloude schreef op woensdag 20 november 2019 @ 17:02:
[...]

Dat zou echt mijn hele idee verpesten van een razendsnelle webframework op een veilige, betrouwbare open source server OS.

Euh, het draait gewoon in Linux. Niet heel Azure is Windows...

https://azure.microsoft.c...s/virtual-machines/linux/

[johnkeates]

Hoewel C# een (relatief) moderne taal is (klassiek paradigma, moderne tools, taal en runtime) is het niet je enige optie en kan je als je wil experimenteren of van een scripting taal als PHP ook wat proefjes doen met andere talen.

Behalve de taal is het net zo belangrijk om rekening te houden met de omgeving, tooling en het doel (wil je het wiel opnieuw uitvinden of gewoon een generiek CMS met een huis-tuin-keuken blogje hosten, of iets daar tussen in).

Zo kan je bijv. prima uit de voeten met Wordpress, PHP en MariaDB op een FPM, nginx, Linux stack met Cloudflare er voor. Context is dus heel belangrijk.

Als je (als ik het zo lees) op zoek bent naar 'iets beters dan PHP', dan wil je waarschijnlijk naar een compiled of intermediate compiled (met VM) taal toe, maar ben je waarschijnlijk wel bekend met de rijkere ecosystemen, tools en frameworks. Dan is het goed om meerdere simpele projecten na te bouwen om kennis op te doen, bijv. het klassieke gastenboek voorbeeld, of de MVC of MVVM versie van een To-Do lijst zonder JavaScript. Als je aan een taal, tools en framework getest hebt met simpele request-response lusjes, persistence en sessies heb je meestal wel een gevoel bij wat je prettig vindt werken.

Er is geen gouden standaard m.b.t. 1 tool, 1 taal, 1 vendor, en alles heeft een leercurve. Dat betekent dat je misschien wel na een paar dagen sleutelen helemaal voor Erlang gaat, of Scala, in plaats van wat je gedacht had.

Kijk bijvoorbeeld naar een paar standaard stacks:

- Go met de standaard HTTP library en een router naar keuze (chi bijv, erg actief)
- Swift met Vapour
- Spring Boot (bijv. ook via JHipster)
- C# met .NET Core
- Python met Django (of als je kleinere spullen maakt met bijv. Flask of zelfs Twisted)
- Erlang via Elixir
- Scala met Play
- JavaScript met NodeJS en express

Geen van de talen, frameworks of templates zijn de ultieme winnaar, iedereen die een favoriet heeft denkt vaak van wel, maar dat is met alles zo (automerken, kleur sokken, tandpasta smaak) en eigenlijk nooit correct.

Stel dat je niet zelf host (wat ik ook niet meer zou aanraden anno 2019 -- kleine kans dat je het beter/goedkoper kan dan bijv. een droplet van 5 dollar per maand of een EC2 micro van 0$ voor de eerste 12 maanden) dan kan je het stukje infrastructuur beperken tot de server software en en ingress delen (bijv. Cloudflare en een reverse proxy op je host die ook meteen static assets meepakt). En je kan het nog kleiner maken door bijv. alleen een container aan te bieden, bijv. ECS van AWS of Google/Azure's equivalent. En als je nog meer op je code wil richten kan je ook compleet Serverless gaan (wat betekent dat je gewoon op een server in een container draait, maar de server, container en randzaken compleet uitbesteed), daar zitten wat beperkingen aan:

- geen lange draaiende processen
- geheugen beperkingen
- processortijd beperkingen

Dat is niet verkeerd, want het dwingt je beter over je architectuur na te denken, en kan onder aan de streep veel goedkoper zijn. Maar dat is eigenlijk al weer ver buiten scope voor je originele vraag.

[ Voor 20% gewijzigd door johnkeates op 20-11-2019 17:24 ]

[BugBoy]

RobIII schreef op woensdag 20 november 2019 @ 16:54:
.Net core heeft nog steeds de runtime nodig. Sowieso een raar vergelijk dat je maakt.

TS vraagt toch specifiek om C#? Wat hebben C/C++ en Go hier dan allemaal mee te maken

.NET core kan je self contained bouwen, waardoor (een deel van) de runtime in de uiteindelijke build artifacts komt. Dan ben je niet afhankelijk van een apart te installeren runtime afhankelijk. Kan erg fijn zijn voor deployment.

C# is een optie, maar lang niet altijd een goede optie. Vandaar de alternatieven. Ik merk dat veel .NET ontwikkelaars vast zitten in de .NET bubble. Van een beetje verbreding word je een betere programmeur en kan je betere keuzes maken.

[RobIII]

BugBoy schreef op woensdag 20 november 2019 @ 21:38:Dan ben je niet afhankelijk van een apart te installeren runtime afhankelijk.

Dat is al jaren geen probleem meer (ook niet de verschillende runtimes 'naast elkaar' waar je in je vorige post over praat). Ik denk dat je er moeilijker over denkt/doet dan dat 't is. Maar goed, ik merk dat non-.NETters vast zitten in de non-.NET bubble Van een beetje verdieping word je een betere programmeur en kan je betere keuzes maken.

Nog steeds staat dat de vraag specifiek over C# ging. Als je dan toch alternatieven wil voorstellen, onderbouw dan op z'n minst waarom (binnen de context van TS) die keuze beter is. Anders kun je TS net zo goed verwijzen naar deze pagina en een dartpijl geven

Als je enige argument de runtime is (en "compactere binaries" - wat anno 2019 (tenzij op Google/Facebook/Amazon-scale) amper een argument is als je het hebt over een binary van 200mb t.o.v. 400mb (*als je die grootte al ooit aantikt...*)) dan vind ik dat een behoorlijk lam argument. Sorry. En don't get me wrong; in de juiste context kunnen beide een prima argument tegen .Net zijn hoor - maar in de context van dit topic en in een doorsnee omgeving met een doorsnee project zijn beide zelden tot nooit een fatsoenlijk argument.

[ Voor 53% gewijzigd door RobIII op 20-11-2019 21:53 ]

[BugBoy]

RobIII schreef op woensdag 20 november 2019 @ 21:42:
Dat is al jaren geen probleem meer (ook niet de verschillende runtimes 'naast elkaar' waar je in je vorige post over praat). Ik denk dat je er moeilijker over denkt/doet dan dat 't is. Maar goed, ik merk dat non-.NETters vast zitten in de non-.NET bubble Van een beetje verdieping word je een betere programmeur en kan je betere keuzes maken.

Nog steeds staat dat de vraag specifiek over C# ging. Als je dan toch alternatieven wil voorstellen, onderbouw dan op z'n minst waarom (binnen de context van TS) die keuze beter is. Anders kun je TS net zo goed verwijzen naar deze pagina en een dartpijl geven

Als je enige argument de runtime is (en "compactere binaries" - wat anno 2019 (tenzij op Google/Facebook/Amazon-scale) amper een argument is als je het hebt over een binary van 200mb t.o.v. 400mb (*als je die grootte al ooit aantikt...*)) dan vind ik dat een behoorlijk lam argument. Sorry. En don't get me wrong; in de juiste context kunnen beide een prima argument tegen .Net zijn hoor - maar in de context van dit topic en in een doorsnee omgeving met een doorsnee project zijn beide zelden tot nooit een fatsoenlijk argument.

Ik zit al vanaf .NET Framework v1.1 t/m de huidige .NET core 3.0 zo'n 40 uur per week die .NET bubble, dus ik zou aardig moeten weten waar ik het over heb. Ik ben dan ook zeker niet anti .NET, maar voor side-projects maak ik juist graag gebruik van andere talen om mijn kennis te verbreden. Pas als je andere talen ziet, dan zie je ook wat er minder goed is aan C# of juist wel goed is.

Het "grote nadeel" van .NET Framework is dat er niet eenvoudig meerdere versies naast elkaar kunnen staan. Een v4.7.2 versie draait niet naast v4.5, maar zal echt een in-place upgrade zijn. Vrijwel altijd is dat probleemloos, maar soms zijn er toch echt compatibility issues. Onze vorige corporate website ging down toen er een .NET upgrade naar v4.7 op de webserver kwam (Sitefinity kon de licentie niet meer activeren). Enige optie was de website naar een andere server verhuizen die op .NET v4.5 draaide. Ook is de minimale ondersteunde Windows versie soms een issue bij nieuwere .NET frameworks, maar dat is de laatste jaren wat minder een issue.

Ook heb je elevated rechten nodig voor de installatie van het .NET Framework en dat is niet altijd even handig. Een aantal applicaties die we maken gebruiken Squirrel voor installatie, waardoor je ook als non-admin die applicatie kunt gebruiken en automatisch laat updaten. We kunnen alleen geen upgrade doen vanaf .NET framework v4.5, omdat veel van onze gebruikers geen admin-rechten hebben. Het hebben van een runtime is dus wel degelijk onhandig in veel gevallen.

Bij .NET core is dat probleem minder. Daar kan je wel meerdere runtimes naast elkaar plaatsen. Maar dat kost wel serieus ruimte en ook je deployment is weer lastiger. Als je onderliggende hardware het aankan, raad ik aan .NET core in Docker te draaien (op Linux tenminste). Dan is je deployment handiger en kun je ook delen van je image delen (i.i.g. het base image als je applicaties dezelfde .NET core runtime gebruiken). Ook self-contained applicaties hebben de runtime ingebouwd en dan hoef je ook geen losse runtime te installeren. Kost alleen wel minimaal 50MB aan disk-space en die komt bij elke applicatie terug.

Wij ontwikkelen veel op lichte Linux hardware, waarbij Docker geen optie is en je flash beperkt is tot 256MB. Dan tikken self-contained .NET core applicaties met zo'n 60MB aan minimum footprint best aan. De trimming functies in v3.0 zijn nog niet echt van een niveau dat het veel zoden aan de dijk zet. De basis van .NET (dus ook .NET core) is gewoon niet gemaakt om heel kleinschalig te zijn. Door zaken als reflection wordt assembly trimming tijdens je build erg lastig om dat betrouwbaar te doen.

Ik vind C# een fijne taal en met .NET core is het eindelijk ook goed bruikbaar op Linux. Mono voelde toch altijd een beetje als net-niet en was relatief traag. Desondanks vind ik .NET core ook nog steeds te groot en te log voor veel doeleinden. Heb je een zware Intel-server dan valt het allemaal wel mee, maar ga je naar low-end ARM devices, dan voel je die overhead (met name disk-space) ten opzichte van andere talen best wel.

Voordat ik C# programmeerde deed ik vrijwel alles in C/C++ en die taal is niet voor niets nog altijd zeer populair op Linux. Het is de enige manier om zeer compacte applicaties te maken met hoge performance. Ook op Windows zie je nog veel C/C++ programmatuur, maar een website of web-api zou ik er niet gauw mee maken. Qua onderhoudbaarheid en safety heb je wat meer uitdaging met deze talen, maar ze hebben zeker hun doel. Hetzelfde geldt voor Golang dat wat mij betreft een beetje tussen C/C++ en C# in zit. Het programmeert wat fijner en moderner dan C/C++, maar is toch wat compacter dan C#. Als er één programmeertaal perfect was geweest, dan was die wel dominant geweest, maar je ziet niet voor niets dat er van alles naast elkaar bestaat.

De reden dat ik andere talen aanhaal is juist om aan te geven dat C# niet altijd de beste keuze is. Voor moderne website ontwikkeling zou ik eerder gaan naar Angular/React/Vue met een REST back-end (kan C# zijn, maar ook NodeJS, Go of iets anders dat je past). De echte MS adept zou wellicht voor Blazor kiezen, zodat je full-stack C# kunt ontwikkelen. Er zijn zoveel smaken en op basis van de informatie die TS geeft kun je eigenlijk niet echt een zinvol advies geven.

Desondanks zou ik altijd voor .NET core kiezen boven Mono, tenzij je op platformen terecht komt waarvoor .NET core nog niet beschikbaar is. Mono is toch nog wat meer portabel dan .NET core, dus soms is dat toch nog altijd de betere optie.

[Gomez12]

BugBoy schreef op woensdag 20 november 2019 @ 23:30:
[...]
Het "grote nadeel" van .NET Framework is dat er niet eenvoudig meerdere versies naast elkaar kunnen staan.

Je noemt hier een "groot nadeel" van iets wat niemand hier in dit topic aanraad...
Iedereen heeft het over .Net Core

Bij .NET core is dat probleem minder. Daar kan je wel meerdere runtimes naast elkaar plaatsen. Maar dat kost wel serieus ruimte en ook je deployment is weer lastiger.
...
Ook self-contained applicaties hebben de runtime ingebouwd en dan hoef je ook geen losse runtime te installeren. Kost alleen wel minimaal 50MB aan disk-space en die komt bij elke applicatie terug.

Elke geinterpreteerde taal heeft gewoon een runtime nodig die "serieus" ruimte kost.
Het is alleen zo dat php / go etc vaker zijn meegeinstalleerd met linux of delen, waardoor die kosten voor jou schijnbaar onzichtbaar worden weggewerkt in de kosten van hoe groot een OS is.

Het enige echte grote verschil (qua schijfruimte) is dat je met .Net Core enterprise library's erbij krijgt, terwijl je met de meeste andere scripttalen je enkel basic library's erbij krijgt.
Ga je in php / go / weet ik veel wat dan ook een serieuze applicatie maken dan krijg je ook weer te maken met enterprise library's en die zijn dan ook weer groot.

Voor een hello world applicatie zit er een grootte verschil in .Net core en andere talen.
Voor een echte applicatie is er praktisch geen grootte verschil meer omdat je dan opeens al die extra dingen die standaard in .Net Core zitten erbij bent gaan halen.

Wij ontwikkelen veel op lichte Linux hardware, waarbij Docker geen optie is en je flash beperkt is tot 256MB. Dan tikken self-contained .NET core applicaties met zo'n 60MB aan minimum footprint best aan.

Waarom? Je applicatie gebruikt een kwart van je schijfruimte, wat is daar veel aan?
Hoe groot is je OS-install, want ik vermoed dat die veel groter is als 60MB en veel meer onzin bevat.

Desondanks zou ik altijd voor .NET core kiezen boven Mono, tenzij je op platformen terecht komt waarvoor .NET core nog niet beschikbaar is. Mono is toch nog wat meer portabel dan .NET core, dus soms is dat toch nog altijd de betere optie.

Mono is imho momenteel geen serieuze optie meer, MS heeft wel in de planning staan om Framework, Core en Mono gelijker te trekken. Alleen Mono is voorlopig nog het achtergelaten kindje in dat stuk. Pas als ze die grondig bij hebben gewerkt wordt het wmb pas weer een optie.

[Lethalis]

Faloude schreef op woensdag 20 november 2019 @ 16:56:
Hele interessante toevoegingen in dit topic.

Wat een timing van mij om dit te vragen.
Release .NET core 3.0: 2 maanden geleden
Release .NET core 3.0.1: Gisteren

Release .NET Core 2.1 LTS: 2018-05-30

Sinds .NET Core 2.1 LTS vind ik het namelijk volwassen genoeg om volop te gebruiken voor web (api) development en gebruik ik het dus ook al anderhalf jaar voor allerlei projecten op mijn werk

Het draait prima op moderne Linux distributies en je kunt ook VS Code gebruiken om ervoor te ontwikkelen.

Voor de overgang naar .NET Core 3 wacht ik nog even op de LTS (3.1).

[MrMonkE]

Heh.. wat een mooie antwoorden. 👍 👍 👍
Weinig op af te dingen.

Zelf zou ik ook docker aanraden al is dat misschien wat teveel gedoe als het allemaal nieuw is voor je.
Anders in een VM. Ik heb jaren een VM met IIS op linux gedraaid

[BugBoy]

[b]Gomez12 schreef op dinsdag 3 december 2019 @ 09:48:
[...]

Als eerste moet mij even van het hart dat je nogal een harde toon aanslaat in dit topic. Je schrijft alsof je de wijsheid in pacht hebt en dat andere meningen onzin zijn of er niet toe doen.

Elke geinterpreteerde taal heeft gewoon een runtime nodig die "serieus" ruimte kost.

Zowel C# als Go zijn geen geïnterpreteerde talen, maar talen die gecompileerd moeten worden. In het geval van C# gaat dat eerst naar een byte-code (MSIL) die vervolgens door de run-time meestal wordt omgezet naar uitvoerbare assembly instructies. Het is overigens mogelijk om een ready-to-run assembly te maken die al voor een specifike CPU-familie is gecompileerd, maar dit is niet standaard. De run-time van .NET core doet dus een extra compilatie (JIT) tijdens het uitvoeren van het .NET programma.

Een Go executable wordt tijdens build-time al omgezet naar assembly en hoeft daarom ook niet door een run-time te worden omgezet naar assembly. Ook wordt een Go applicatie volledig statisch gelinkt en zal het slechts één file opleveren in tegenstelling tot .NET programma's die uit meerdere assemblies bestaan.

Doordat Go statisch kan linken (net als een C/C++ programma) kan de linker veel beter onderzoeken wat er wel en niet meegenomen hoeft te worden. Door de aard van .NET (bijv. reflectie) is dit veel lastiger te doen en zal er minder weg geoptimaliseerd kunnen worden. Er is bij Mono wel een initiatief om dit voor elkaar te krijgen, maar dit vereist veel extra configuratie om de linker van de nodige informatie te voorzien.

Doordat .NET een JIT aan boord moet hebben en meestal minder goed kan optimaliseren zijn .NET programma's in de praktijk vaak groter dan een vergelijkbare applicatie die in Go is gecompileerd.

Het is alleen zo dat php / go etc vaker zijn meegeinstalleerd met linux of delen, waardoor die kosten voor jou schijnbaar onzichtbaar worden weggewerkt in de kosten van hoe groot een OS is.

PHP en Go zijn volstrekt onvergelijkbaar in deze. Geen enkele embedded Linux distributie zal standaard de Go ontwikkelomgeving meegeïnstalleerd hebben. Een aparte Go runtime bestaat niet, omdat die altijd is ingebakken in de uiteindelijke executable. Voor PHP is dit anders en zal je altijd interpreteren. Voor een embedded platform zou ik hier niet gauw voor kiezen, tenzij je ruimte genoeg hebt of de performance eisen erg laag zijn.

Het enige echte grote verschil (qua schijfruimte) is dat je met .Net Core enterprise library's erbij krijgt, terwijl je met de meeste andere scripttalen je enkel basic library's erbij krijgt.

Het grote verschil is dat je bij Go tijdens het bouwen de ongebruikte libraries al weglaat. Bij .NET core is dat dus vaak veel lastiger.

Waarom? Je applicatie gebruikt een kwart van je schijfruimte, wat is daar veel aan? Hoe groot is je OS-install, want ik vermoed dat die veel groter is als 60MB en veel meer onzin bevat.

Als je 256MB flash geheugen hebt op een embedded device, dan houd je in de praktijk veel minder over, omdat je ook te maken hebt met wear en firmware upgrades. Je zal je flash dan bijvoorbeeld als volgt indelen:

• 1MB boot
• 64MB partition A
• 64MB partition B
• 64MB persistent data

De beide partities gebruik je om veilig firmware upgrades mogelijk te maken en een rollback mogelijk te maken als de firmware upgrade mislukt of niet door zijn checks komt. De ongebruikte data is nuttig omdat je wear in je flash wilt kunnen opvangen. Onze base Linux firmware is wel degelijk gestript en bevat niet echt veel "onzin".

Mono heeft nog steeds wel een plek in de .NET omgeving. Op sommige systemen (bijv. iOS) is het niet mogelijk om intermediate code (MSIL) te gebruiken en moet je dus terugvallen op Mono om een echte executable te kunnen maken.

[R4gnax]

@BugBoy

Tegenwoordig zet je met .NET Core 3 een paar flags in je project file om een single-file executable te bouwen die tree trimming toepast en enkel de gebruikte classes overneemt:

XML:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishReadyToRun>true</PublishReadyToRun>
    <PublishSingleFile>true</PublishSingleFile>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

Dit creeërt een getrimde single-file executable die zover mogelijk ahead-of-time gecompileerd is voor win-x64. Toegegeven; het is vziw niet 100% native maar het komt een flink eind. (En het pakt wss. een goede balans tussen de lusten en de lasten.)

Heb je meer doel-platformen? Dan gebruik je het <RuntimeIdentifiers> element en multi-target je het geheel met een semi-colon gescheiden lijst van runtime identifiers.


Reflection wordt trouwens ook ondersteund. Dat gebeurt middels een gedeelte statische analyze van de codebase, aangevuld met handmatige instructies - ook in het project bestand.

Zie o.a.
https://www.hanselman.com...inedSingleExecutable.aspx

[ Voor 54% gewijzigd door R4gnax op 03-12-2019 20:51 ]

[BugBoy]

R4gnax schreef op dinsdag 3 december 2019 @ 20:43:
Tegenwoordig zet je met .NET Core 3 een paar flags in je project file om een single-file executable te bouwen die tree trimming toepast en enkel de gebruikte classes overneemt.

Dat is inderdaad het ready-to-run gedeelte dat ik in een eerdere post aangaf. Dat werkt op zich best aardig, maar je assemblies worden wel wat groter.

De single-executable is in de praktijk minder handig op een embedded systeem. Bij de eerste run pakt die zichzelf uit, waardoor je toch extra ruimte nodig hebt. Voor deployment van applicaties kan het makkelijk zijn, maar aangezien wij altijd complete firmware images pushen heeft het voor ons geen meerwaarde.

De implementatie van tree-trimming is nog matig. Het komt op dit moment niet veel verder dan ongebruikte assemblies uit je build te halen en zelfs daar slaagt het in de praktijk niet echt goed in. Het .NET core team heeft uitgesproken dat dit verbeterd zal worden in .NET core 5.

[RobIII]

BugBoy schreef op dinsdag 3 december 2019 @ 21:09:
[...]
De single-executable is in de praktijk minder handig op een embedded systeem. Bij de eerste run pakt die zichzelf uit, waardoor je toch extra ruimte nodig hebt. Voor deployment van applicaties kan het makkelijk zijn, maar aangezien wij altijd complete firmware images pushen heeft het voor ons geen meerwaarde.

Je betrekt het steeds op jezelf/jullie en embedded systemen maar ik heb TS niet één keer embedded horen noemen en volgens mij is er meer in de wereld dan embedded

[BugBoy]

RobIII schreef op dinsdag 3 december 2019 @ 21:31:
Je betrekt het steeds op jezelf/jullie en embedded systemen maar ik heb TS niet één keer embedded horen noemen en volgens mij is er meer in de wereld dan embedded

Ik krijg commentaar op mijn posts (geen probleem, daarom zit ik op een forum) en probeer uit te leggen waarom ik die mening heb. Het begon dat ik een runtime soms problemen vind geven vanwege versieverschillen. Daar werd vrij makkelijk weggewuifd door een aantal. Niet alleen bij embedded toepassingen (slechts 10% van mijn werk), maar ook bij shared hosting is dat soms een issue, omdat je niet altijd kunt bepalen welke runtimes gebruikt kunnen worden.

Daarna ontstond de discussie over de voor- en nadelen van runtimes, intermediate languages, application sizes, ... Veel .NET programmeurs (vooral hobbymatig) bekijken het alleen van hun situatie. Ik probeer juist in mijn posts uit te leggen dat er meer is dan een desktop PC met vele gigabytes storage en RAM. Het verhaal van single-file executables klinkt ook veel beter dan het is. Onder water is het eigenlijk niet veel meer dan een self-extracting ZIP-file, maar dat lees je vrijwel nergens. Vandaar dat ik het goed vind om af en toe wat nuance aan te brengen.

Het zou voor veel programmeurs goed zijn om eens te gaan programmeren op een device met beperkte resources en zich te verdiepen wat er onder de motorkap allemaal gaande is.

[ Voor 12% gewijzigd door BugBoy op 04-12-2019 10:18 ]

[boe2]

Ofwel werk je met gedeelde libraries, ofwel embed je ze mee in de applicatie. Daar kan je toch moeilijk omheen, ongeacht de taal?

[Lethalis]

boe2 schreef op woensdag 4 december 2019 @ 10:53:
Ofwel werk je met gedeelde libraries, ofwel embed je ze mee in de applicatie. Daar kan je toch moeilijk omheen, ongeacht de taal?

Het grote verschil is dat je bij de ene taal alleen krijgt wat je nodig hebt, terwijl je bij de andere niet alleen wat plantjes en bloempotten krijgt, maar ook meteen het hele bos.

.Net Core is wat dat betreft niet zo efficiënt en daar wordt door Microsoft nog aan gewerkt. De IL linker is echter nog niet volwassen, daarnaast zijn er situaties te bedenken waarin de linker simpelweg niet kan beoordelen of hij iets nodig heeft of niet, omdat je in .Net ook dynamische dingen kunt doen.

Omdat een taal als C of Golang beperkter is qua mogelijkheden, kan de linker daar op een veiligere manier beslissingen nemen.

En zal de uiteindelijke executable dus efficiënter zijn.

Maar dat betekent dus ook dat je jezelf moet beperken tot bepaalde functionaliteit als ontwikkelaar.

.Net Core werkt super voor mijn toepassingen, op VM's die draaien op servers met genoeg processing power (meestal 2 of meer Xeon's) en geheugen (vaak 32GB of meer).

En dan vind ik het gemak dat ik ervan heb (Visual Studio IDE, API's die voor 80% lijken op wat ik ken van het .Net Framework, C#) veel belangrijker dan hoe efficiënt het is.

Om diezelfde reden gebruik ik de laatste tijd ook het Entity Framework. Het draait misschien wat trager dan mijn custom ADO.NET code, maar het gemak dat ik ervan heb, is enorm.

Je flanst echt in no time een volledige API in elkaar.

Mijn ervaring met Golang is dat de Hello World nog super is, maar dat je gaandeweg wel serieus doorkrijgt dat je met een meer low level taal te maken hebt, zodra je allerlei drivers nodig hebt om bijvoorbeeld met SQL Server te praten, of zelf je mime messages moet maken als je een HTML mailtje wil sturen. Het is C on steroids.

Het is ook leerzaam, en ik heb niks tegen Golang.

Maar als ik voor mijn werk (als backend web developer) iets moet bouwen, zal ik eerder voor .Net Core kiezen.

In een embedded scenario zou ik wellicht back to basics gaan met C. Simpelweg omdat ook Golang een garbage collector heeft en dat is altijd inefficiënter dan zelf het geheugen reserveren / vrijgeven... en bovendien misschien niet op het moment dat jij het wil.

[Faloude]

Dit is een heel interessante topic geworden. Oorspronkelijk vroeg ik dit, omdat ik geinteresseerd ben om Umbraco te draaien op Linux. Umbraco is een CMS gebouwd op .NET.

[Cyphax]

Faloude schreef op dinsdag 26 mei 2020 @ 09:36:
Dit is een heel interessante topic geworden. Oorspronkelijk vroeg ik dit, omdat ik geinteresseerd ben om Umbraco te draaien op Linux. Umbraco is een CMS gebouwd op .NET.

Ik zou er niet teveel op inzetten, want geen ASP.NET Core. Ik wil je wel Orchard aanraden. niet in de laatste plaats vanwege het verschil in kwaliteit... ik ben van Umbraco niet zo gecharmeerd, was wel een oude versie, maar 'k ben weleens door de sources gegaan op zoek naar de oplossing voor ronduit bizarre problemen, en wat ik daar tegenkwam was... jammer. Dat het niet op .NET Core draait verbaast me weinig.

[ Voor 11% gewijzigd door Cyphax op 26-05-2020 10:01 ]

[Faloude]

Even deze oude topic reanimeren.

PHP = interpreted = niet optimaal snel
C# = compiled language = snel

C# op Linux = compiled language MAAR met een CLI onder als vertaler.
CLI is een interpreter dus maakt dat C# op Linux in essentie een hybrid van compiled EN interpreted?
Veroorzaakt dit een terugval in performance ten opzichte van C# op Windows?

[Faloude]

Cyphax schreef op dinsdag 26 mei 2020 @ 09:45:
[...]

Ik zou er niet teveel op inzetten, want geen ASP.NET Core.

Overigens grappig hoe mijn hele uitgangspunt als een kaarthuis in elkaar stortte hiermee.

[RobIII]

Faloude schreef op donderdag 24 december 2020 @ 18:30:
Even deze oude topic reanimeren.

PHP = interpreted = niet optimaal snel
C# = compiled language = snel

C# op Linux = compiled language MAAR met een CLI onder als vertaler.
CLI is een interpreter dus maakt dat C# op Linux in essentie een hybrid van compiled EN interpreted?
Veroorzaakt dit een terugval in performance ten opzichte van C# op Windows?

Uh, ik denk dat je wat dingen door elkaar haalt. C# compiled (tenzij je "out of your way" gaat) meestal naar CIL / MSIL, be it Windows, be it Linux. En die CIL / MSIL wordt door een runtime uitgevoerd.

CLI is geen interpreter maar een specificatie. C# wordt wel gecompileerd naar CIL en door de runtime (met JIT) naar native code gecompileerd en, in dat opzicht, zou je het als 'interpreted' kunnen beschouwen. Echter, het is een behoorlijk genuanceerd verhaal: omdat code JIT'ted wordt heeft de runtime het voordeel dat 'ie voor die specifieke CPU / omgeving kan optimaliseren (en het resultaat kan cachen) en soms dus veel beter performed dan code die 'AoT' gecompileerd is naar een 'grootste gemene deler want het moet op alle X86 CPU's sinds de 386 draaien'. Daarmee zeg ik ook weer niet dat 't altijd beter / sneller is. Zoals ik zei is 't een véél genuanceerder verhaal en behoorlijk afhankelijk van het scenario.

En dan kun je "tegenwoordig" C# ook nog compileren naar 'native binaries' wat het verhaal nog allemaal veel complexer maakt. Maar, tenzij je die laatste paar druppels performance écht nog ergens uit wil knijpen: why do you care? Vertel eens?

Sinds je TS zijn we inmiddels bij .Net 5 aangekomen en is, in essentie, .Net Core en het .Net Framework samengevoegd in een enkel platform: .Net 5.

[ Voor 6% gewijzigd door RobIII op 24-12-2020 20:56 ]

[Faloude]

why do you care?

@RobIII ASP.NET websites (in C#) waren razendsnel in vergelijking met PHP websites toen ik het vergeleek. Dit is het geval omdat websites in C# geschreven, precompiled zijn. Wat ik wil weten is of je diezelfde snelheid behoudt als je ASP.NET website bouwt op Apache+Linux stack. En zo niet, waarom niet.

[ Voor 3% gewijzigd door Faloude op 24-12-2020 20:47 ]

[RobIII]

Faloude schreef op donderdag 24 december 2020 @ 20:46:
[...]

@RobIII ASP.NET websites (in C#) waren razendsnel in vergelijking met PHP websites toen ik het vergeleek. Dit is het geval omdat websites in C# geschreven, precompiled zijn. Wat ik wil weten is of je diezelfde snelheid behoudt als je ASP.NET website bouwt op Apache+Linux stack. En zo niet, waarom niet.

Daar is geen "one size fits all" antwoord op te geven; ik denk dat dat inmiddels wel uit je topic duidelijk is geworden. In sommige gevallen wel, in andere niet. Meten = weten.

Overigens ken ik zat trage ASP.Net websites en retesnelle PHP websites. Ook hier denk ik dat je probeert appels en peren te vergelijken. Een website is niet, of hóéft niet, "snel" te zijn "omdat" het in .Net / PHP / whatever geschreven is, maar kan ook gewoon "snel" zijn omdat het goed in elkaar zit. Of gewoon weinig doet. Een "Hello world" zal, doorgaans, "sneller" zijn dan een bedrijfsspecifieke applicatie waar al 10 jaar aan getimmerd wordt door 14 verschillende consultancy bureaus met elk hun eigen manier van coden en jaren legacy meezeult en ...

[ Voor 31% gewijzigd door RobIII op 24-12-2020 20:54 ]

[DataGhost]

Faloude schreef op donderdag 24 december 2020 @ 20:46:
[...]

@RobIII ASP.NET websites (in C#) waren razendsnel in vergelijking met PHP websites toen ik het vergeleek. Dit is het geval omdat websites in C# geschreven, precompiled zijn. Wat ik wil weten is of je diezelfde snelheid behoudt als je ASP.NET website bouwt op Apache+Linux stack. En zo niet, waarom niet.

Dat vergelijk kan je alleen maar maken als de websites identiek zijn en op dezelfde hardware en verbindingen draaien, en op dezelfde webserver-software. Voor zover ik weet is het meeste van Tweakers (incl het forum) in PHP geschreven en dit is nu niet echt een trage site dacht ik zo. PHP wordt ook naar een bytecode (soort van CIL dus) "gecompileerd" voordat/tijdens deze wordt uitgevoerd en er zijn allerlei manieren om deze compilatiestap van tevoren uit te voeren en/of te cachen in memory en/of op disk zodat C# in dat opzicht geen meerwaarde biedt. Sinds PHP8 is daar zelfs JIT bij gekomen.

Zoals RobIII hierboven al zegt kunnen er tig redenen zijn waarom een site traag is en dat is tegenwoordig eigenlijk exclusief terug te voeren op kutcode. Dat kan met C# net zo goed gebeuren, en dat ligt dus voor meer dan 99% aan de developers.

[ Voor 12% gewijzigd door DataGhost op 24-12-2020 22:07 ]

[Faloude]

Ik snap er geen moer van. Ik dacht dat mijn vraag heel eenvoudig was. Nevermind

[RobIII]

Faloude schreef op donderdag 24 december 2020 @ 22:42:
Ik snap er geen moer van. Ik dacht dat mijn vraag heel eenvoudig was. Nevermind

Je snapt 't niet of hoort niet wat je graag wil horen?
Simpel: Er is geen zwart/wit antwoord "Is C# sneller/langzamer op Linux/Windows". Er zijn talloze factoren die meespelen. Makkelijker dan dat kan ik 't niet voor je maken.

[TweakerNummer]

Faloude schreef op donderdag 24 december 2020 @ 22:42:
Ik snap er geen moer van. Ik dacht dat mijn vraag heel eenvoudig was. Nevermind

Het is vrij simpel. Zowel C# als PHP hebben grof versimplificeerd dezelfde stappen om van broncode naar output te komen:
C#: Broncode --- Compiler ---> CIL / MSIL --- Executor ---> Output
PHP: Broncode --- Compiler ---> OPCode --- Executor ---> Output

Waar ze in verschillen is in wat de Executor doet. De C# Executor compileert stukken CIL / MSIL naar Machine Code en voert deze uit. De PHP Executor voert OPCode direct uit.

Inmiddels is er ook PHP8-JIT en die Executor werkt net als C#. Tests met PHP8-JIT vs PHP8 laten zien dat er weinig verschil is qua performance met normale websites. Bij synthetische testresultaten is PHP8-JIT echter vele malen sneller.

En om je vraag te beantwoorden... De Executor van C# heet CLR (en niet CLI). De Linux CLR werkt net als de Windows CLR.

[ Voor 21% gewijzigd door TweakerNummer op 25-12-2020 03:14 ]

[Faloude]

@TweakerNummer Dankjewel! Dit is precies de informatie die ik probeerde te vergaren. En het gaat mij inderdaad precies om synthetische testresultaten. Voordat ik geinteresseerd ben in real-life scenario's (website A vs website B ) ben ik vooral geinteresseerd in welke fundamenteel sneller is in techniek .

[DataGhost]

Dat mag, maar je moet je zeker niet blindstaren op synthetische benchmarks als er in real-world geen of nauwelijks verschil is. Ik neem aan dat wat je wilt maken ook onder "real-life scenario's" valt, dus dan heb je aan synthetische resultaten niet zoveel. Wat wil je precies gaan maken dan? Als je een website hebt met grote synthetische loads (lijkt me heel stug) zou ik die delen uitbesteden aan een losse applicatie/service waarmee je communiceert. Voor het website-gedeelte zou ik de taal/omgeving pakken waarmee je de meeste ervaring hebt of waar collega's/personeel het meeste over weten.

[Gomez12]

Faloude schreef op vrijdag 25 december 2020 @ 10:23:
@TweakerNummer Dankjewel! Dit is precies de informatie die ik probeerde te vergaren. En het gaat mij inderdaad precies om synthetische testresultaten. Voordat ik geinteresseerd ben in real-life scenario's (website A vs website B ) ben ik vooral geinteresseerd in welke fundamenteel sneller is in techniek .

Het probleem is dat jij een heel complexe vraag stelt die tweakernummer slechts maar gedeeltelijk beantwoord.

In wezen zou je moeten beginnen met de vraag : Wat is voor jou een website?

Want bij wat ik in de praktijk een website noem, daar is de programmeertaal slechts voor iets van max 1% verantwoordelijk voor de snelheid, 99% van de tijd zit in andere zaken als de backend-programmeertaal.

Als je het puur hebt over enkel het vanuit de backend genereren van een complete respons (dus je laat nog even zitten dat die bij de client gerenderd/getoond moet worden) dan zit imho 99% van de tijd in externe calls en I/O, oftewel je database calls en je file I/O etc.

Simplistisch gezegd moet elke backend taal gewoon in 1 ms een hello world kunnen produceren, daar gaat een php niet significant sneller/trager in zijn dan een c#.

In de praktijk is de snelheid van programmeertalen simpelweg niet echt boeiend meer, of je moet echt complexe berekeningen doen in die taal. Als je er een extern component bij gaat betrekken (dat kan een database zijn, maar ook een library), dan ga je daar veel meer tegenaan lopen dan je eigen code.

[RobIII]

Faloude schreef op vrijdag 25 december 2020 @ 10:23:
[Voordat ik geinteresseerd ben in real-life scenario's (website A vs website B ) ben ik vooral geinteresseerd in welke fundamenteel sneller is in techniek .

@TweakerNummer zegt dus precies wat je wil horen maar geeft je een (behoorlijk) oneven beeld. Wat wij je steeds zeggen is dat PHP/C# niet "fundamenteel" sneller is dan de ander. Voor elke synthetische test waarin X sneller is dan Y zal er een synthetische test zijn waarin Y sneller is dan X. Websites zijn véél eerder I/O bound dan CPU bound en dus is de taal amper relevant (of verwaarloosbaar). Je staat bij een autodealer te staren naar welke auto de mooiste sleutel heeft ipv te kijken naar welke auto de functionaliteit biedt die je zoekt. Als je op vakantie wil met een caravan en veel zooi wil je een auto met trekhaak en dakrails en kofferruimte en als je er het circuit mee op wil zoek je grote remmen, licht gewicht, gestroomlijnde body en een snelle motor.
Maar goed, je hebt straks wel de mooiste sleutel! Je hebt na lang wikken en wegen de taal gekozen waarmee je Pi kunt berekenen tot op de 700 miljoenste decimaal die 0,01 seconde eerder klaar is dan de ander (die dat voor jou in een fractie van die tijd wellicht niet berekend maar uit een file gehaald had - wat de ander ook had gekund overigens). Management zal je dankbaar zijn. Je mededevelopers zullen je vervloeken tot in het einde der dagen omdat je je keus gebaseerd hebt op wat het mooiste glimde.

[ Voor 16% gewijzigd door RobIII op 25-12-2020 12:58 ]

[Faloude]

DataGhost schreef op vrijdag 25 december 2020 @ 11:54:
Dat mag, maar je moet je zeker niet blindstaren op synthetische benchmarks als er in real-world geen of nauwelijks verschil is. Ik neem aan dat wat je wilt maken ook onder "real-life scenario's" valt ...

Ik ben het helemaal met je eens hoor, maar ik stel de vraag met de intentie om de onderliggende techniek beter te begrijpen. Ondanks dat ik mijn vraag later herformuleerde in iets praktischer "welke website is sneller" was het mijn bedoeling om uit het antwoord meer te begrijpen over de techniek onder de motorkap.

Gomez12 schreef op vrijdag 25 december 2020 @ 12:21:
[...]
Want bij wat ik in de praktijk een website noem, daar is de programmeertaal slechts voor iets van max 1% verantwoordelijk voor de snelheid, 99% van de tijd zit in andere zaken als de backend-programmeertaal.

Is de verhouding 99 tot 1 echt realistisch als je 2 identieke websites (in andere talen geprogrammeerd) naast elkaar zou zetten?

RobIII schreef op vrijdag 25 december 2020 @ 12:49:
[...]
Je staat bij een autodealer te staren naar welke auto de mooiste sleutel heeft ipv te kijken naar welke auto de functionaliteit biedt die je zoekt.

Nee, ik probeer onder de motorkap te kijken voordat ik de rest ga beoordelen. (en één van de verkopers lijkt erg geïrriteerd te zijn hierover ). Chill Roblll. Ik zit nog echt helemaal aan het begin van mijn onderzoek en de keuze is nog lang niet gemaakt hiermee.

[Mr. HTTP]

Faloude schreef op vrijdag 25 december 2020 @ 10:23:
En het gaat mij inderdaad precies om synthetische testresultaten. Voordat ik geinteresseerd ben in real-life scenario's (website A vs website B ) ben ik vooral geinteresseerd in welke fundamenteel sneller is in techniek .

[Faloude]

LOL!

[CodeCaster]

Faloude schreef op vrijdag 25 december 2020 @ 13:10:
[...]

Ik ben het helemaal met je eens hoor, maar ik stel de vraag met de intentie om de onderliggende techniek beter te begrijpen. Ondanks dat ik mijn vraag later herformuleerde in iets praktischer "welke website is sneller" was het mijn bedoeling om uit het antwoord meer te begrijpen over de techniek onder de motorkap.


[...]

Is de verhouding 99 tot 1 echt realistisch als je 2 identieke websites (in andere talen geprogrammeerd) naast elkaar zou zetten?


[...]

Nee, ik probeer onder de motorkap te kijken voordat ik de rest ga beoordelen. (en één van de verkopers lijkt erg geïrriteerd te zijn hierover ). Chill Roblll. Ik zit nog echt helemaal aan het begin van mijn onderzoek en de keuze is nog lang niet gemaakt hiermee.

Het punt dat iedereen hierboven probeert te maken, is dat "snelheid van de programmeertaal/runtime" een ontzettend zinloze metric is, zéker in de context van webapplicaties.

Wat Gomez zegt, is een grove generalisatie, maar bij het afhandelen van een webrequest is de server inderdaad 99% van de tijd niet bezig met het uitvoeren van jouw code, maar aan het wachten op antwoord van een opslagmedium of netwerkverzoek. De taal maakt hier echt geen fluit uit. Waar jij je druk om lijkt te maken, is hoe snel een bepaalde taal at runtime wordt vertaald naar CPU-instructies, en dat is gewoon heel vaak niet relevant met moderne talen en CPU's.

Anders gezegd: ontwikkeltijd is duur, servertijd goedkoop, en nogmaals, het verschil ga je niet merken. Er zijn zat synthetische benchmark beschikbaar waarbij blijkt dat taal X zoveel duizend per requests kan afhandelen en taal Y X+Z duizend, maar dat maakt in the end, als jij niet zoveel requests verwacht, geen fluit uit.

De keren dat jij merkt dat een bepaalde site trager is dan een ander, kan dit aan zoveel meer liggen dan de gebruikte taal. Als je de interface buiten beschouwing laat (veel trage sites zijn inherent traag doordat er zeven miljard JavaScript-libraries van bij elkaar 20 MB worden ingeladen, geparsed en uitgevoerd voor elke muisbeweging en toetsaanslag, ik kijk naar jou, Discourse), en zelfs al zouden ze identieke taken uitvoeren, dan kan de responsetijd liggen aan de internetpijp vanaf die server, de CPU/RAM/schijfsnelheid in die server, de achterliggende databaseserver, het gebruik van caches en zó veel meer waarbij de beperkende factor níet is hoeveel vertaalslagen er in code worden gemaakt op dat moment.

En als sites heel verschillende taken uitvoeren, kan de developer van een PHP-site zomaar wél weten hoe 'ie efficiënte databasequeries schrijft, terwijl de dotnetter lekker bij ieder request al z'n joins naar al z'n tabellen uitvoert vanuit comma-separated tekstvelden, gewoon, omdat hij niet beter weet. Als bezoeker heb je er dan geen hol aan dat .NET een bepaald for-loopje maar liefst 10% sneller uitvoert dan PHP, want de laatste staat tien keer sneller op je scherm.

[Faloude]

@CodeCaster Dankjewel. De uitleg die je neer hebt gezet is begrijpbaar en overtuigend genoeg voor mij om niet meer naar runtime snelheid te kijken.

[Lethalis]

Faloude schreef op donderdag 24 december 2020 @ 20:46:
[...]

@RobIII ASP.NET websites (in C#) waren razendsnel in vergelijking met PHP websites toen ik het vergeleek. Dit is het geval omdat websites in C# geschreven, precompiled zijn. Wat ik wil weten is of je diezelfde snelheid behoudt als je ASP.NET website bouwt op Apache+Linux stack. En zo niet, waarom niet.

Ik heb anders hele snelle PHP sites gezien, en ontzettend trage ASP.NET sites... precies om hier reeds genoemde redenen (database query performance, storage performance, etc).

Op mijn werk moet ik weleens vaker performance issues oplossen. 99% van de tijd ben ik dan bezig SQL queries en / of indexes te optimaliseren. Tot en met het uitzoeken of de gekozen clustered key (volgorde waarop records zijn opgeslagen in SQL Server) wel handig is.

Er zijn bijvoorbeeld .NET programmeurs die geilen op GUID's als primary key. En die hebben totaal niet door wat voor een verschrikkelijke index fragmentatie dat oplevert.

Tsja... dan krijg je de meest trage rommel.

Of ze gebruiken een ORM met eager loading, waardoor er een shitload aan data wordt geladen dat ze helemaal niet nodig hebben. Of de where clausules leiden tot een table scan, omdat ze gewoon stupid zijn geformuleerd.

I can go on like this forever.

De shit die ik in mijn leven gezien heb, waarvan het meeste in mijn 17 jaar werkervaring als .NET developer... my eyes still hurt. Ik heb applicaties letterlijk 100 keer sneller laten lopen. Simpelweg door query execution plans te analyseren.

Tsja. De taal is inderdaad ondergeschikt.

PS
Ook heel grappig als mensen gaan roepen dat ze snellere servers nodig hebben met meer cores en RAM en als ik dan met een beetje prutsen ervoor zorg dat het snel draait op de oude server

[ Voor 5% gewijzigd door Lethalis op 26-12-2020 00:35 ]

[armageddon_2k1]

Lethalis schreef op zaterdag 26 december 2020 @ 00:26:
[...]

Er zijn bijvoorbeeld .NET programmeurs die geilen op GUID's als primary key. En die hebben totaal niet door wat voor een verschrikkelijke index fragmentatie dat oplevert.

Hey, ik geil op GUID's Ze bieden ontzettend veel voordelen voor ons in de domain-code, maar ik kan me voorstellen dat integer indices wel beter zijn. Daarnaast wordt onze data niet weggeschreven in een relationele DB. Wij serializen gewoon hele projectbestanden en slaan die op, en laden die weer in-memory waar nodig. Onze specifieke use-case maakt dit mogelijk.

Echter, er zijn wel use-cases te bedenken natuurlijk waar dit wel het geval is. Waar je sowieso de voordelen van UUIDs wil hebben maar ook de relationele DB voordelen en je hebt gewoon te maken met miljoenen records.

Wat is dan de oplossing als je GUID's wel als primary key wilt/moet gebruiken, maar toch nog een beetje performance wilt? Ik begrijp dat het vooral het probleem is dat je de GUID PK ook als Clustering Key gebruikt, de standaard instelling in SQL Server.

[RobIII]

armageddon_2k1 schreef op zaterdag 26 december 2020 @ 11:37:

Wat is dan de oplossing als je GUID's wel als primary key wilt/moet gebruiken, maar toch nog een beetje performance wilt? Ik begrijp dat het vooral het probleem is dat je de GUID PK ook als Clustering Key gebruikt, de standaard instelling in SQL Server.

Ook hier is weer geen "one size fits all" antwoord op te geven, maar: er zijn verschillende 'soorten' (versies) (G/U)UIDs en de ene is beter geschikt dan de ander. Een V4 is redelijk funest voor een (vooral clustered) index. Er zijn alternatieven zoals een aangepast (G/U)UID of een ULID die dit specifieke probleem proberen op te lossen. Maar buiten dat is een (G/U)UID ook vaak onnodig groot (16 bytes) wat vergelijken bijv. extra duur maakt. Je kunt dan ook kijken naar dingen als een 64 bits ID zoals een "Snowflake ID" zoals Twitter dat gebruikt(e?) (disclaimer: auteur van deze specifieke implementatie) wat, voor all intents and purposes, vaak net zo goed werkt als een GUID maar dus wel gewoon (zo goed als) oplopend is en de helft compacter. En dan zijn er vast nog 50 andere methodes te verzinnen; het hangt er een beetje af van je specifieke use-case (heb je bijv. een enkele verantwoordelijke voor het genereren van ID's of wil je dat distributed doen bijvoorbeeld).

[CodeCaster]

Lethalis schreef op zaterdag 26 december 2020 @ 00:26:
[...]

Of ze gebruiken een ORM met eager loading, waardoor er een shitload aan data wordt geladen dat ze helemaal niet nodig hebben. Of de where clausules leiden tot een table scan, omdat ze gewoon stupid zijn geformuleerd.

I can go on like this forever.

De shit die ik in mijn leven gezien heb, waarvan het meeste in mijn 17 jaar werkervaring als .NET developer... my eyes still hurt. Ik heb applicaties letterlijk 100 keer sneller laten lopen. Simpelweg door query execution plans te analyseren.

Yup, dat komt uit de "Rapid Application Development" school of thought. Iemand die een UI in elkaar kan slepen, is blijkbaar ook geschikt om een database te ontwerpen én aan te spreken.

Ik had er net nog een op Stack Overflow die "use this its works" antwoordde en daarna code toonde die een volledige tabel leegtrok met een SELECT *, om dat via een SqlDataAdapter naar een DataSet te voeren om dáár vervolgens een .Rows.Count op te doen, om de vraag te beantwoorden: "hoe tel ik hoeveel records in m'n tabel zitten?". Je verzint het toch niet.

Ik heb op m'n vorige klus, waar véél ETL-jobs draaiden, juist een ORM ingevoerd. Want fuck PetaPoco. "Ja maar dat is zo lekker klein". Ja, en ondertussen zit je weer SQL in strings te tikken, en één join kan nog net, maar bij twee kun je het "micro-ORM" de deur uit doen, want dat kan het gewoon niet.

Een ORM is handig als je weet wat er in de onderliggende laag gebeurt. Als je niets van databases weet, en gewoon een .IncludeAllTheThings() schrijft, of lazy loading aanzet, dan begrijp je niets van databases en moet je daar eerst meer over leren voordat je daaraan mag zitten.

Helaas wordt de gemiddelde schoolverlater of self-taught rockstar aan het begin op zulke projecten gezet, waarna ze binnen een paar jaar uit hun voegen gebarsten zijn en ik ze weer vlot mag komen trekken. Ik vind het helemaal prima hoor, maar dit ligt niet aan de taal of aan het gebruik van een ORM, maar gewoon aan een gebrek aan kennis.

Net als Nancy trouwens, van een eigenwijze gast die ten tijde dat ASP.NET MVC opkwam lekker z'n kont tegen de krib wilde gooien en alles beter wist. Wat nou controllers, routes maak je toch gewoon met een supersexy Fluent Syntax? En nee, Razor is veel te stom, ik maak mijn eigen dialect dat nét niet compatibel is! En dat voor elke eerste pageview een temp-DLL compileert en die niet opruimt. En een application startup time van 20 (!) minuten, die na het omzetten naar MVC 5 gewoon 2 seconden werd. Of een URL die eindigt op .json, dan gooit 'ie .json weg en voegt de request header Accept: application/json toe, want dat wil toch iedereen? Kom op zeg.

Of mensen die tokens en cookies maar lastig vinden, dus de core van de authenticatie van Stack Overflow plukken en de comments weghalen en de lifetime op een jaar zetten. Dat is dan nog tot daar aan toe, maar zullen we dan alsjealsjeblieft wel het applicationSecret per klant instellen, zodat de admin van site A zijn cookie niet kan kopiëren naar site B van een andere klant en daar ineens ook admin is?

Hobbybobs heb je overal. Komt niet door de taal. Het jammere van .NET is dat het door de ogenschijnlijke eenvoud steeds aantrekkelijker wordt om in te stappen zonder enige kennis van zaken.

Ik had ook ooit een collega die een SQL-naar-Excel-conversie voor een bepaalde rapportage in één klasse had gekwakt, en met partial classes (dus dezelfde klasse uitgesplits naar verschillende files) ging gaan werken omdat de duizenden regels vrijwel identieke code een beetje onleesbaar werden. Hij vond daar niets mis mee, en een paar cursusjes later werkte 'ie ineens voor een heel grote detacheerder.

[ Voor 7% gewijzigd door CodeCaster op 26-12-2020 14:04 ]

[Ankona]

Vroeger had je visual basic. De taal die een handige systeembeheerder zich wel eigen kon maken en daarmee zich als it koning binnen het bedrijf verder kon ontpoppen. Niets mis met de taal zelf, alleen zag je wel een duidelijk correlatie tussen code kwaliteit en het gebruik van VB, C# of java. (C(++) is een ander verhaal. )


ps ik lees een paar posts door en reageer als code opa met verhalen uit de oude doos. Blijft leuk, maar heeft weinig met de titel van dit topic te maken

[ Voor 19% gewijzigd door Ankona op 04-01-2021 19:41 ]