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

51–60 of 119 posts

Re: My preferred .NET console stack

#51

Post by lol768 »

erikbye wrote: post #40
lol768 wrote: post #29

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB What are you talking about? It's 1.4MB. This is the easiest thing in the world to verify: $ dotnet publish -c Release Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... All projects are up-to-date for restore. ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/Conso…

> And no, I don't want to hear about any figures for self-contained builds. Then what is your point? When talking about the size required for a program to run, you have to weigh all of its dependencies. For anyone interested, such a binary ends up at least 50MB, if we include the dependencies mentioned in the article in question.

> For anyone interested, such a binary ends up at least 50MB

.. if you don't make any use of assembly optimisation/trimming, sure.

    $ dotnet publish -c Release
    Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
    Copyright (C) Microsoft Corporation. All rights reserved.

      Determining projects to restore...
      Restored /tmp/ConsoleApp/ConsoleApp.csproj (in 18.97 sec).
      ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/ConsoleApp.dll
      Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
      ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/publish/
    $ cd /tmp/ConsoleApp/bin/Release/net5.0/linux-x64/publish/
    $ ls
    total 29M
> When talking about the size required for a program to run, you have to weigh all of its dependencies.

Except the dependencies might not even be relevant depending on which OS you're targeting - and in the context of this article, why is this even interesting? You can make all of the same criticisms of the JVM, or .NET web apps or anything else - do you statically link libc?

Re: My preferred .NET console stack

#52

Post by prime31 »

erikbye wrote: post #7

Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.

Ahhh, the good old days when people wrote quality software. I remember them fondly.

Re: My preferred .NET console stack

#54

Post by oblio »

switch007 wrote: post #34
watermelon0 wrote: post #28

Earlier quoted context omitted.

Yes it has, but argparse is not even comparable to [1] Click, or similar libraries. [1] https://click.palletsprojects.com/en/7.x/

Yes but I was responding to the “have to” in: “...a command line option parser which you'd have to pull into a python project...”

There you go: https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/...

argparse - or close to it :-)

Re: My preferred .NET console stack

#55

Post by oblio »

prime31 wrote: post #52
erikbye wrote: post #7

Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.

Ahhh, the good old days when people wrote quality software. I remember them fondly.

When were those days and how do I get back to them?

I'm being sarcastic :-)

Re: My preferred .NET console stack

#56

Post by WarChortle »

AnIdiotOnTheNet wrote: post #25
nick_ wrote: post #11

Earlier quoted context omitted.

That is demonstrably untrue. Very few users care at all about the size of an app, and even fewer devs care to put in all the extra effort to use some unfamiliar tech stack just to save their ambivalent users' machines from using up some extra, but (usually) imperceptible CPU and RAM resources. EDIT: That said, I do wish that the trimming/tree-shaking systems could do more to get the size and speed of easy-to-code sol…

They do care, they've just gotten used to bloated software and therefore don't have high expectations. I submit that this is indicative of our failings as an industry.

Not a single non tech person I know has ever complained about the size of an app on download. Not one. They don't even look at the size its not relevant to them. They want to do something that some app enables. Besides how well it lets them do it no one cares about the size until they are out of space, which is usually because they have so many videos and photos stored.

You're kidding yourself if you think the average person looks at the size of an app.

Re: My preferred .NET console stack

#57

Post by oblio »

majkinetor wrote: post #17
moksly wrote: post #10

Earlier quoted context omitted.

Beyond that, the fact that you have to do any of this is silly. The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment. I know I’m grossly exaggerating, but the fast movement and the lack of ease of use has been one of the primary reasons to see us slowly move toward python and powershell after nearly two decades of…

> The .Net tooling used to be easy Net tooling used to be horror. Now its good. Speaking as someone who does CI/CD work on it for a long time. You seem to speak as someone who doesn't have .net muscle memory. Programming is complex, unless you finish with hello world (even hello world is complex in enterprise environments).

He's probably looking at it from a different angle.

As someone who has had to set up MSBuild & other BS for a CI server, I definitely agree with you.

For a dev used to double click Visual Studio, the current setups are more complex.

Re: My preferred .NET console stack

#58

Post by SideburnsOfDoom »

erikbye wrote: post #21
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.

Kind of my line of thinking as well. I would never pull in a library with a 100 features when my software only needs 2 of those features. I write those 2 features myself.

a) Which of those libraries do they use only 2% of the features from? One the template is filled out, won't it be higher.

b) There are certain things that look simple, but you _do not_ want to waste your time coding the corner cases yourself when this is a solved problem.

e.g. You might think that commandline args is simple, but it is very much not. if you '-file foo.txt' working, how will you handle '-file "C:\Program Files (x86)\bar\foo bar.txt" ' ?

If you get `-message hello` ? working, will your code handle `-message "hello, "friend""` ?

Having this prebuilt is useful.

Re: My preferred .NET console stack

#59

Post by loic-sharma »

erikbye wrote: post #40
lol768 wrote: post #29

Earlier quoted context omitted.

> And you end up with a console app that is 20-100MB What are you talking about? It's 1.4MB. This is the easiest thing in the world to verify: $ dotnet publish -c Release Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... All projects are up-to-date for restore. ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/Conso…

> And no, I don't want to hear about any figures for self-contained builds. Then what is your point? When talking about the size required for a program to run, you have to weigh all of its dependencies. For anyone interested, such a binary ends up at least 50MB, if we include the dependencies mentioned in the article in question.

Just to be clear, a self-contained build includes the .NET runtime and all its libraries in your build output.

Most people just install .NET on their machines. If so, that 1.4mb executable will run just fine.

Post reply on HN