21–30 of 119 posts
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.
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…
> Very few users care at all about the size of an app That depends on the target audience. IME the target audience of console/CLI programs are more likely to care about size. CLI apps tend to cater more to power users. And many users do definitely care about resource usage, and smaller size apps do in fact tend to use less resources. All users definitely care about performance. A fast app feels nicer. Smaller-sized s…
I think what made me defensive was the implication that these CLI libraries can be easily replaced with some small hand-coded solution. This particular library adds color coding, a structured help message based on the configuration, and some building blocks for DI, etc. Getting that stuff right in a hand-coded solution that isn't thousands of lines would take most developers a lot more time and effort.
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.
Seems a bit presumptive to decide the requirements for every console app ever made. Shouldn't it be determined on a case-by-case basis whether a 20mb difference in app size matters?
Also, why exactly does a 20mb app size mean an app is too slow? I'm not really following that line of logic.
The title of the post is "My preferred .NET console stack", not "this is how every console app should be written."
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.
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.
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…
Earlier quoted context omitted.
> Very few users care at all about the size of an app That depends on the target audience. IME the target audience of console/CLI programs are more likely to care about size. CLI apps tend to cater more to power users. And many users do definitely care about resource usage, and smaller size apps do in fact tend to use less resources. All users definitely care about performance. A fast app feels nicer. Smaller-sized s…
I agree. Your points about size and speed are valid. I think what made me defensive was the implication that these CLI libraries can be easily replaced with some small hand-coded solution. This particular library adds color coding, a structured help message based on the configuration, and some building blocks for DI, etc. Getting that stuff right in a hand-coded solution that isn't thousands of lines would take most…
If that was your takeaway from what I wrote that was definitely not my intention. I do not think that.
I am sure several of these libraries are well-crafted, the developer(s) behind them might be excellent and have cared a great deal about performance and did their best to optimize every function. My point was more: people tend to pull in a lot more functionality/features than they need, and the few things you do need, it is often better to write yourself (you may disagree again).
This will often give you the most optimized solution, and the one with the smallest binary.
In another HN thread, someone mentioned Unity and the size of the binary required just to display a pixel, a square, or whatever their example was--although their example was not an apple-for-apple comparison and not quite fair, the point still stands, that Unity is a general solution, and if your only requirement is drawing a pixel, of course Unity is not the correct solution.
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.
I think you’re vastly optimistic about the ratio of ESR-“real-hacker” to “I just work here” developers, as well as the amount an end user cares if the executable is a 100kb vs 100 megs.
Earlier quoted context omitted.
Who said you have to? In fact you don't at all. He's only pulling in 5 dependencies. One is a command line option parser which you'd have to pull into a python project as well. The second is a bridge for that parser to integrate with the dependency injection - which you arguably may or may not need. Third & Fourth are for logging. The last one is completely unnecessary and can be ignored. Again it's just his way of d…
https://docs.python.org/3/howto/argparse.html Python has an argument parser in the standard library
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.
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/ConsoleApp.dll
ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/publish/
$ cd /tmp/ConsoleApp/bin/Release/net5.0/publish/
$ du -h
1.4M .
Spectre.Console looks like a really neat library. I am going to have to check this one out for some of my CLI utilities. With the advent of Blazor, you could also look at building rich UX on top of the very same business services used in the console variant. I have found that Blazor is productive enough to consider using universally for management/configuration/admin dashboards for whatever business process. You coul…