Earlier quoted context omitted.
With Core they are even used for new projects running on Linux.
But exactly, that's my point. You no longer even need to be on Windows to use C#.
Inside the Windows Console
121–130 of 259 posts
Re: Inside the Windows Console
#122The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.
I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.
Re: Inside the Windows Console
#123Earlier quoted context omitted.
I regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?
The terminals you use in Linux must either be painfully slow or you must be very insensitive to latency issues because the latency on Windows console is really high. When I type something I expect it to appear immediately ( A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.
Re: Inside the Windows Console
#124But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.
Re: Inside the Windows Console
#125Re: Inside the Windows Console
#126https://github.com/mikemaccana/powershell-profile/blob/maste...
Re: Inside the Windows Console
#127Re: Inside the Windows Console
#128I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.
Powershell 5 is slow. Powershell 6 preview is much faster (not as fast as bash but does more)
Re: Inside the Windows Console
#129Technical errors regarding how UTF encodings work: * UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before…
This is what Unicode 11.0, §2.4 says:
Noncharacter code points are reserved for internal use, such as for sentinel values. They have well-formed representations in Unicode encoding forms and survive conversions between encoding forms. This allows sentinel values to be preserved internally across Unicode encoding forms, even though they are not designed to be used in open interchange.
It would wrong for a general-purpose parser to reject these codepoints.
Re: Inside the Windows Console
#130Earlier quoted context omitted.
With Core they are even used for new projects running on Linux.
But exactly, that's my point. You no longer even need to be on Windows to use C#.
Not to mention that in the enterprise world Java and .net have an overwhelming market share.
[0] https://insights.stackoverflow.com/survey/2018/#development-...