Thanks for setting the record straight. The author misspoke on true multithreading.
C# is even better it uses Tasks which always use the least busy CPU. It's not just another thread on a single process, it's an asynchronous call directly to the least busy CPU, which spins up, and queues up Task continuations. Only after the work is done are the results captured using an await. Similar to Javascript promise but many times speedier.
I have heard however that node too can spin up CPU agnostic instances. However this author omitted that discussion.
Node's async first architecture was a brilliant move and covers a lot of territory. However single node instances are nowhere the Speed of Java or C# using Tasks or other well defined threading techniques. The only problem is that browsers only speak Javascript.
Project loom aims to leapfrog C# by removing the need to denote tasks. It will make the JVM itself smart enough to use just the right amount of native threads seamlessly. It's currently in technology preview stage and hopefully will ship with Java 18 or 19.
Well I'm not an Java expert but every enterprise app using java like SAP products just feels slow and I instantly feel like I'm back in the 90's. Also he is saying that node is faster in this specific field which it is.
Statement means nothing really as we're not talking about any legacy product. We're talking about what can be done today. For true parallelism today, except on mainframes, the dotnet task construct is a true co-routine design which uses all CPUs in an agnostic way. There's nothing close to it today
If it is an server running an API, there are several programming languages with their respective frameworks that would work. C# could work using .NET Core or Entity Framework just like NodeJS with Express.js
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for setting the record straight. The author misspoke on true multithreading.
C# is even better it uses Tasks which always use the least busy CPU. It's not just another thread on a single process, it's an asynchronous call directly to the least busy CPU, which spins up, and queues up Task continuations. Only after the work is done are the results captured using an await. Similar to Javascript promise but many times speedier.
I have heard however that node too can spin up CPU agnostic instances. However this author omitted that discussion.
Node's async first architecture was a brilliant move and covers a lot of territory. However single node instances are nowhere the Speed of Java or C# using Tasks or other well defined threading techniques. The only problem is that browsers only speak Javascript.
Project loom aims to leapfrog C# by removing the need to denote tasks. It will make the JVM itself smart enough to use just the right amount of native threads seamlessly. It's currently in technology preview stage and hopefully will ship with Java 18 or 19.
Totally cool, I never liked the Task hoops to jump through but use it long enough and it's a second language.
Well I'm not an Java expert but every enterprise app using java like SAP products just feels slow and I instantly feel like I'm back in the 90's. Also he is saying that node is faster in this specific field which it is.
Statement means nothing really as we're not talking about any legacy product. We're talking about what can be done today. For true parallelism today, except on mainframes, the dotnet task construct is a true co-routine design which uses all CPUs in an agnostic way. There's nothing close to it today
If it is an server running an API, there are several programming languages with their respective frameworks that would work. C# could work using .NET Core or Entity Framework just like NodeJS with Express.js