Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My preferred .NET console stack

devlead.se

Post reply on HN
Print view View original

101–110 of 119 posts

Re: My preferred .NET console stack

#101

Post by manigandham »

oblio wrote: post #62
ripley12 wrote: post #33

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB. FWIW, this is sort of a legacy of .NET's "enterprisey" history. Code size and trimming wasn't really a priority when most .NET code ran server-side or inside enterprises, now it is. There's been a lot of work happening recently to trim .NET executables and publish them as single files, and it looks like .NET binary sizes will eventually be in the same ballpark as…

Don't hold your breath. I've been keeping an eye on CoreRT and it actually slowed down and even regressed compared to Dotnet Core's rate of development while I was watching it. I think maybe in 2016? 2018? they were committing a lot to it, probably hoping to make it production ready. Then priorities shifted and they barely advanced and now they moved it into "runtimelab" which doesn't bode well to me.

CoreRT was an experiment and it's concluded. The learnings and components like RyuJIT have now been moved to the new project called NativeAOT which has high priority.

https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

Re: My preferred .NET console stack

#102

Post by manigandham »

malkia wrote: post #91
oblio wrote: post #64

Earlier quoted context omitted.

It's just a fancy self-extracting archive... it's not a statically linked binary with tree shaking of everything which is not actually used.

ugh - I was expecting something better, then again while probably .NET bytecode maybe more mergeable (Without knowing much about it, assuming "java" like essence), there is still the issue of "pdb" merging (but that should be doable...). Obviously native is problematic. Back at Google, I really like how this was solved. Bazel (blaze) internally when doing java or python tool - would actually compile the java runner t…

You should read the docs because it's already available: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...

Re: My preferred .NET console stack

#103

Post by mattmanser »

crispyambulance wrote: post #81
hacker_9 wrote: post #16

As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.

> hefty amount of boilerplate to achieve practically nothing It depends on what you mean by "practically nothing". If you're going to deliver a non-trivial commandline application to do something useful for other people, it needs to have robust input validation, proper auto-complete and help that's sensitive to what command subcommand/option you're trying to invoke. Would also be nice to also get an --update option m…

I really do disagree with you. Most of the example code that comes out of ms is just downright terrible, and encourages terrible code. They're always writing as if you're working for Reddit or Facebook scale, not the code 99.99% of their customers should be writing. I downloaded a random git project to load test a signalr app yesterday because for whatever silly compile reason I couldn't get the one inside aspnetcore to compile (which is a whole massive problem with "modern" .net in itself, how are we back to DLL hell?).

It was hundreds of lines long, didn't work properly, and once I'd culled the crap, pointless, boilerplate was a whole 20 lines.

C# really is great, you can write a lot with some really clear, obvious, terse code. But the awful, over-engineered, useless code that seemingly 75% of C# developers write is not, it's unreadable crap that adds nothing to performance, massively hinders readability and tarnishes the language.

Re: My preferred .NET console stack

#104

Post by malkia »

manigandham wrote: post #102
malkia wrote: post #91

Earlier quoted context omitted.

ugh - I was expecting something better, then again while probably .NET bytecode maybe more mergeable (Without knowing much about it, assuming "java" like essence), there is still the issue of "pdb" merging (but that should be doable...). Obviously native is problematic. Back at Google, I really like how this was solved. Bazel (blaze) internally when doing java or python tool - would actually compile the java runner t…

You should read the docs because it's already available: https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...

Thanks!! - Awesome to hear about this - ".NET 5.0 improves this experience by directly running the code without the need to extract the files from the app." - phew - feel relieved, I can convince now folks to upgrade to 5.0

Re: My preferred .NET console stack

#106

Post by crispyambulance »

gnud wrote: post #97
crispyambulance wrote: post #81

Earlier quoted context omitted.

> hefty amount of boilerplate to achieve practically nothing It depends on what you mean by "practically nothing". If you're going to deliver a non-trivial commandline application to do something useful for other people, it needs to have robust input validation, proper auto-complete and help that's sensitive to what command subcommand/option you're trying to invoke. Would also be nice to also get an --update option m…

Robust input validation and help, sure. Never had a massive use for auto-complete. Maybe my console applications are just too small in scope. I write multiple programs rather than one program with "sub-operations". I've always used the (rather dated) library NDesk.Options [0]. Even though it was written way back in the .net 2 days. For me, it seems to hit a very nice sweet spot between power and complexity. [0]: http…

> auto-complete

I think now folks have gotten used to auto-complete in powershell commands. It's really harsh to not give that to them when they're expecting it. :-)

Re: My preferred .NET console stack

#108

Post by IanDrake »

mattmanser wrote: post #103
crispyambulance wrote: post #81

Earlier quoted context omitted.

> hefty amount of boilerplate to achieve practically nothing It depends on what you mean by "practically nothing". If you're going to deliver a non-trivial commandline application to do something useful for other people, it needs to have robust input validation, proper auto-complete and help that's sensitive to what command subcommand/option you're trying to invoke. Would also be nice to also get an --update option m…

I really do disagree with you. Most of the example code that comes out of ms is just downright terrible, and encourages terrible code. They're always writing as if you're working for Reddit or Facebook scale, not the code 99.99% of their customers should be writing. I downloaded a random git project to load test a signalr app yesterday because for whatever silly compile reason I couldn't get the one inside aspnetcore…

I feel the same way about DI. Great in theory, but the supposed benefits are never realized.

While performance tuning a process for a client I showed them how one request was creating 420 objects (some very expensive) through DI and only using two of them.

Re: My preferred .NET console stack

#109

Post by merb »

oblio wrote: post #62
ripley12 wrote: post #33

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB. FWIW, this is sort of a legacy of .NET's "enterprisey" history. Code size and trimming wasn't really a priority when most .NET code ran server-side or inside enterprises, now it is. There's been a lot of work happening recently to trim .NET executables and publish them as single files, and it looks like .NET binary sizes will eventually be in the same ballpark as…

Don't hold your breath. I've been keeping an eye on CoreRT and it actually slowed down and even regressed compared to Dotnet Core's rate of development while I was watching it. I think maybe in 2016? 2018? they were committing a lot to it, probably hoping to make it production ready. Then priorities shifted and they barely advanced and now they moved it into "runtimelab" which doesn't bode well to me.

> Don't hold your breath. I've been keeping an eye on CoreRT and it actually slowed down and even regressed compared to Dotnet Core's rate of development while I was watching it.

you do not need CoreRT for trimming. but trimming is already there: https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/

it's still a long way to go, tough.

Post reply on HN