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

61–70 of 119 posts

Re: My preferred .NET console stack

#61

Post by lkxijlewlf »

ripley12 wrote: post #33
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.

> 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…

> FWIW, this is sort of a legacy of .NET's "enterprisey" history.

So is this type of boilerplate.

Re: My preferred .NET console stack

#62

Post by oblio »

ripley12 wrote: post #33
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.

> 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.

Re: My preferred .NET console stack

#63

Post by WarChortle »

erikbye wrote: post #18
romanovcode wrote: post #12

Earlier quoted context omitted.

>it should be about making things easy, small, and FAST for the user. If that would be true people would be using IRC, not Slack or Teams. Users don't care and your statement is completely false.

I am not sure most users would agree with your assessment that IRC is easy. To many it is arcane. If you created two Telegram alternatives, that was identical except for performance, would users not choose to use the most performant one? Statistics like these (I just found at random, but there are many like it available) demonstrates that your average user do in fact care a lot about performance: https://www.marketin…

In a perfect world yes they would, but how many times has the better tech died in our history. Its too many to count.

If I wrote the perfect chat app tomorrow, I'm talking universally loved by anyone who uses it. I'm not guaranteed to succeed. If someones whole family is on iMessage and they are happy they aren't going to be able to get them to switch. So they couldn't use my app if they wanted too.

Thus they stay with the "inferior" product. Average people aren't interested in the latest greatest. They just want it to work and as long as it does, they don't care about shortcomings that don't affect them. IE app size, speed(as long as its good enough)

Re: My preferred .NET console stack

#64

Post by oblio »

malkia wrote: post #60

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for one reason or another).

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.

Re: My preferred .NET console stack

#65

Post by disgrunt »

janto wrote: post #44
disgrunt wrote: post #42

Earlier quoted context omitted.

Click is great and a feature-rich option. But recommend checking out Typer, which is even simpler if you're already using type annotations. [0] [0]: https://github.com/tiangolo/typer

"Typer stands on the shoulders of a giant. Its only internal dependency is Click."

Didn't say it was a replacement for Click. I said it was simpler if you're already using type annotations.

Re: My preferred .NET console stack

#66

Post by disease »

Not trying to be incendiary, but is there a real need for tables and graphs and all of those colors in a console application?

Usually if you want structured information from some process then you just build a web application that does its work on a schedule or when it receives an API request. Console applications are great for "fire and forget" or even being called by something else and then passing pack simple data back to the caller if necessary.

I had a co-worker that built an extremely complex table display system using ncurses. I wondered what the point was - who is going to see all of these fancy tables? The person who SSH into the system and quickly validates its correctness and then closes the connection? Or people that use VNC/Remote Desktop just to see the status of what's going on?

Edit: referring to the functionality of Spectre.Console.

Re: My preferred .NET console stack

#67

Post by kertoip_1 »

nend wrote: post #30
bob1029 wrote: post #5

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…

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

The biggest issue with it is a really large binaries that have to be downloaded on page start. So it isn't necessarily suitable for use cases where speed matters. But at the same time, it's perfect for dashboards, I really like to work with it.

Re: My preferred .NET console stack

#68

Post by guhidalg »

disease wrote: post #66

Not trying to be incendiary, but is there a real need for tables and graphs and all of those colors in a console application? Usually if you want structured information from some process then you just build a web application that does its work on a schedule or when it receives an API request. Console applications are great for "fire and forget" or even being called by something else and then passing pack simple data…

No of course not, unstructured text is the pinnacle of CLI UX and anything else is a waste of oxygen. /s

I frequently SSH into systems that are not running desktop environments and being able to run htop, iftop, tmux, or any "graphical" CLI application makes my time there much more pleasant.

Yes there is a need to have structured, interactive, non-text based interfaces in a CLI.

Re: My preferred .NET console stack

#69

Post by wtetzner »

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.

The .NET framework is usually expected to be installed at the system level.

And to what extreme do you take that line of thought? Should the kernel size be included?

Re: My preferred .NET console stack

#70

Post by bob1029 »

kertoip_1 wrote: post #67
nend wrote: post #30

Earlier quoted context omitted.

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

The biggest issue with it is a really large binaries that have to be downloaded on page start. So it isn't necessarily suitable for use cases where speed matters. But at the same time, it's perfect for dashboards, I really like to work with it.

We use server-side Blazor for all of our interfaces. These load incredibly quickly. I personally don't like the concept of WASM and client-side Blazor. Especially, for the use cases where <100 people are going to be using the system at the same time.
Post reply on HN