T O P
  • By - fsou1

BeowulfShaeffer

I mean, I actually kind of like nodejs but it’s clearly not sometime i would choose for cpu-intensive workloads.


fsou1

Yes, and that's why you shouldn't use the same tool for every task/project.


MountainAlps582

I see several problems First is the title. I lost brain cells reading it However the second is when I jumped to the end and saw him use async and saw all the times being 1ms when it used to be 1K. Is he measuring how long it takes to start an async job? Because it doesn't seem like he's collecting any results If thats true then this is really fucking stupid and nothing was actually fixed


crabmusket

Around the 4min mark he appears to be offloading the heavy work to a WebWorker, so real gains in processing the fast requests would make sense.


powdertaker

You besides it being Javascript?


douglasg14b

I'm not really on the "JS hate train", but lets be honest, JS workloads run slow. Painfully slow. Using JS for CPU-intensive operations isn't a great choice to begin with.


Prod_Is_For_Testing

I’ve learned too many quirks not to be on the JS hate train. I don’t know how anyone can take it seriously. Like they added arrow functions which should be interchangeable for normal functions except they’re not because “this” behaves differently. Who thought that was a funny idea?


deadron

In this particular case its because the "this" reference in the original functions are impossible to reason about because "this" can refer to entirely different things based on how its invoked. Its a source of a number of bugs and the reason why you often see workarounds like `var $this = this` in code using them. The arrow functions enclose the "this" reference they are declared in which makes them much easier to use in many situations.


BobHogan

> In this particular case its because the "this" reference in the original functions are impossible to reason about because "this" can refer to entirely different things based on how its invoked. Yet another example of why JS is one of the stupidest languages ever designed. Its a miracle it became so widely used


deadron

Well, libraries like jQuery prove that it actually can be quite useful to have a dynamically bound "this" reference. It is just not useful in all contexts. In the style of object oriented programming you likely would have no issues. It's only when you adopt a more imperitive or functional style that issues emerge. When JavaScript released everyone was gaga over OO and that style may have influenced this decision.


GrandOpener

I actually like JavaScript, but the way it handles “this” (and relatedly “new”) was just a mistake, plain and simple. It’s bad in OOP also. JQuery itself was a hack to work around bad DOM APIs, and would be completely dead now if it weren’t being propped up by hundreds (thousands?) of functional Wordpress plugins and themes that will never be updated. There’s a reason the only languages that have copied this decision are ones that specifically have JavaScript interoperability as a primary goal.


deadron

jQuery was useful so long as we needed to support IE10 and below. With the death of that era it becomes much easier to drop jQuery. jQuery UI is still a really nice themeable lightweight drop in for many sites though.


godlikeplayer2

>. I don’t know how anyone can take it seriously. probably because it's the only language you can do proper full-stack development with. I rather remember some of its quirks instead of learning a completely new language and all its quirks...


Aeverous

Why would you create new syntax that's basically as verbose for no reason? The fact that `this` is treated differently in them is the entire point. It's so much nicer as well, unless you somehow love writing `.bind(this)` when passing functions around?


godlikeplayer2

nodejs can do some decent number cunching since they added worker threads: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html


douglasg14b

Yes, but JavaScript execution is still slow. Throwing more threads at it doesn't make it faster. It just means that it can now do what other languages have been able to do for decades, except slower.


flora_best_maid

Javascript benchmarks at 4.04s for the mandelbrot set problem, which is pure calculation of a limit for complex numbers: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html Now, you may say this is shit because the C++ implementation completes at under a second. Fair enough. The C++ implementation uses SIMD instructions, which I'd rather never deal with. Notably, F# and Java are at around 4s, which I don't consider poorly performing languages at all. Have you looked at V8 and SM optimisations recently, or do you get all your performance talking points from YouTube and reddit?


godlikeplayer2

>Yes, but JavaScript execution is still slow. the benchmark shows something else with multi-threaded node not that far away from modern multi-threaded java. I would assume the difference is much smaller in a single-threaded context.


IshKebab

JavaScript is one of the fastest scripting languages there is. It may have some pretty huge warts but lack of speed isn't really one of them. Obviously not as fast as "proper" languages like Go, Java, Rust, C++. But it's plenty fast enough for most things. The biggest issue is multithreading kind of sucks. Anyway it could be worse. Could be Python.


[deleted]

[удалено]


GrandOpener

I want to like Lua, but they made so many design decisions that could have been reasonable in a vacuum but just seem arbitrarily different to me. Arrays start at 1, not 0? Zero is truthy? The not-equals operator? Dash-dash-bracket-bracket for comments? These all make sense in some context if you’re only doing Lua, but it just drives me bonkers trying to context switch between that and almost any other language. As a result I just can’t use Lua effectively and avoid it.


ANALSPELUNKER9000

HUR HUR JaVaScRiPt BaD! Literally what I picture every time I see this moronic statement made.


[deleted]

[удалено]


ANALSPELUNKER9000

I can tell, I've obviously upset the basement trolls with that statement.


[deleted]

Let me guess, someone discovered that it uses one core and has GC ?


[deleted]

[удалено]


fsou1

Nope, developing in NodeJS and know it's pros and cons


UpsetMeal1942

Guys if we wrap the fibonnaci in a promise then would it still be blocking?


fsou1

Yes, because Promise itself does make any magic if there is still a sync call at the end. However, if you offload the computation to a separate server (core) and await for a HTTP response (result), then it would unblock your execution thread.


EntroperZero

The promise immediately begins execution, and there's nothing in the fibonacci function that returns control, so yeah, it's still blocking. It doesn't even go to the event queue, it executes directly from the constructor of the promise.


brucebrowde

You can do Promise.any or Promise.race as a workaround though.


[deleted]

[удалено]


xentropian

Nice bot copying comments