5 ms·
I’d say anything except long running processes or scripts that take 5+ second to complete. Cli scripts/apps should simply be responsive, just like websites and
by jbverschoor 1y ago
I’d say anything except long running processes or scripts that take 5+ second to complete.
Cli scripts/apps should simply be responsive, just like websites and apps shouldn’t be slow to open.
Slower scripts result in distraction, which ultimately leads to hackernews being in front of your nose again.
A few of my examples:
Resizing/positioning windows using shortcut keys. Unbearable if it’s not instantaneous.
Open a terminal based on some criteria. Annoying if I have to wait.
- motorest 1y ago> I’d say anything except long running processes or scripts that take 5+ second to complete. I don't think you're presenting a valid scenario. I mean, the dotnet run file.cs workflow is suited for one-off runs, but even if you're somehow assuming that these hypothetical cold start times are impossible to optimize (big, unrealistic if) then it seems you're missing the fact that this feature also allows you to build the app and generate a stand-alone binary. So exactly what's the problem?
- jbverschoor 1y agoBut it doesn’t. It still seems to run in JIT mode, instead of AOT. That’s exactly why I made swift-scc (interpret vs compile, but essentially the same problem)
- motorest 1y ago> But it doesn’t. I recommend you read the article. They explicitly address the usecases of "When your file-based app grows in complexity, or you simply want the extra capabilities afforded in project-based apps".
- jbverschoor 1y agoComplexity is not the problem. It a simple hello world example. Imagine cat, ls, cd, grep, mkdir, etc. would all take 500ms. It’s the same as the electron shit. It’s simply not necessary
- const_cast 1y ago> Imagine cat, ls, cd, grep, mkdir, etc. would all take 500ms. Those are all compiled C programs. If you were to run a C compiler before you ran them, they would take 500 milliseconds. But you don't, you compile them ahead of time and store the binaries on disk. The equivalent is compiling a C# program, which you can, of course, do.
- linkage 1y agoThese cold start times are not hypothetical, as shown by multiple commenters in this thread. They also have been demonstrably impossible to optimize for years. Cold start times for .NET lambda functions are still an order of magnitude greater than that of Go (which also has a runtime). AOT compilation reduces the gap somewhat but even then the difference is noticeable enough on your monthly bill. This dismissive “startup time doesn’t matter” outlook is why software written in C# and Java feels awful to use. PowerShell ISE was a laughingstock until Microsoft devoted thousands of man-hours over many years to make the experience less awful.
- jodrellblank 1y ago> hypothetical cold start times Long standing complaint about .NET / .NET Core 2017 Github issue: https://github.com/dotnet/core/issues/1060 https://github.com/dotnet/core/issues/1060 2018 Github issue: https://github.com/dotnet/core/issues/1968 https://github.com/dotnet/core/issues/1968 Regular people complaining, asking, and writing about it for years: https://duckduckgo.com/?t=ffab&q=cold+start+NET.&ia=web https://duckduckgo.com/?t=ffab&q=cold+start+NET.&ia=web Right up to this thread, today. Why are you denying that this exists?
- GoblinSlayer 1y agoYep, little can be done about it, even grep suffers from cold start.
- jodrellblank 1y agogrep suffers from half second cold starts? citation needed.