Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Eating the World

dev.to

Post reply on HN
Print view View original

241–250 of 323 posts

Re: JavaScript is Eating the World

#241

Post by always_good »

eropple wrote: post #226
always_good wrote: post #225

Earlier quoted context omitted.

>Single-threaded isn't a benefit Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you don't deal with the certain pitfalls of multi-threadedness.

If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie.

We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.

Re: JavaScript is Eating the World

#242

Post by eropple »

always_good wrote: post #241
eropple wrote: post #226

Earlier quoted context omitted.

If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.

The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner.

Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not.

(Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?)

I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)

Re: JavaScript is Eating the World

#243

Post by specialist »

eropple wrote: post #161
specialist wrote: post #134

Earlier quoted context omitted.

My day gig is nodejs. I was interested in the problem space, didn't think too much about the stack. How bad could it be, right? Oops. The worst aspect of nodejs is code construction (craftsmanship). Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quit…

> Frankly, I'd rather just write 'C' again. If I have to care about the fiddly bits, I'd rather the language not fight back. Instead, you'd rather the language be written with conscious land mines in it? Like, I have a history of dunking on JavaScript. (Though, to be fair: ES6+ is better! It's a lot better. I kinda like it.) But C is unsafe as hell . The list of people who should be writing C is super short. If you'r…

What are the ideal use cases for nodejs?

We have a handful of stupid simple http servers. We use express, redis, aws-sdk, pino, misc. Responses are mostly JSON.

The http-request module has given us the most fits. I question that any one has ever used it for more than toy problems.

The redis module is also an engineering marvel. I gave up trying to add a rate throttling shim. The goal is to limit the number of concurrent requests. Because when our app is under load, we're not processing redis responses fast enough, so redis server's outbound client buffers grow and will eventually OOM ABEND the server. So I wrote our own stupid simple redis thing using async.queue as a poor mans thread (task) pool. Trivial. Eg my REPL parser is 1/3rd the size of node-redis-parser. Works great. I keep thinking I must be missing something.

From my reading, hapi (successor to express) does an inbound backpressure thing. I'll be trying that out asap.

Much as I hate Spring, AOP, jedis, annotations, jaxrs, log4j... I've never had these kinds of nuts & bolts problems. Now I kinda miss the elephant gun approach.

PS- I can only assume the on drain event strategy was someone's idea of a practical joke. Maybe its a uvlib thing.

Re: JavaScript is Eating the World

#244

Post by specialist »

amorphid wrote: post #152
dboreham wrote: post #136

Earlier quoted context omitted.

My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..

I used to love to idea of a global interpretator and/or a single thread (coding without concurrency). It was great until it wasn't. Learning Elixir helped me get over that.

Ya, my next green field project will definitely use something actor or CSP flavored. Maybe clojure based, more likely Elixir or equiv.

Re: JavaScript is Eating the World

#245

Post by coldtea »

fundabulousrIII wrote: post #137
coldtea wrote: post #120

Earlier quoted context omitted.

Notice how this doesn't even mean anything.

Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.

>Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.

Well, file systems nobody writes in JS, so that's irrelevant.

As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.

Re: JavaScript is Eating the World

#247

Post by pier25 »

thehardsphere wrote: post #230
ralusek wrote: post #196

Earlier quoted context omitted.

For the millionth time: It is not accurate to refer to it as single threaded. The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation. Non-blocking: [aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee] Blocking-threaded: [aa]------------------------[/aa][ff]-----…

It is accurate to refer to it as single threaded, because it executes with a single thread. "Non-blocking" is an orthogonal concept to the number of threads being used. You can have "non-blocking" and multiple threads at the same time.

Isn't it actually 2 threads at the minimum?

The V8/JS thread and the C++ thread?

Doesn't the C++ part create threads in some cases when needed?

Re: JavaScript is Eating the World

#248

Post by tchaffee »

rootlocus wrote: post #110
tchaffee wrote: post #81

Earlier quoted context omitted.

> whatever would motivate people to use js for anything more than is strictly necessary. If that's the primary language you are good at, from coding frontend apps, then it's pretty nice to be able to switch to writing backend code without having to do a language context switch. Muscle memory along with your memory about library methods all just continue to flow. > It can't be that hard using a different language. If…

> If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow? If you're better with screwdrivers, why struggle with a hammer? JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite lang…

> If you're better with screwdrivers, why struggle with a hammer?

Not a great analogy. A more accurate analogy is switching from one very big toolbox to another very big toolbox. If you are used to one and know where all the tools are, and they have been used so much that the wood perfectly fits your hand, then it's just going to take some time to get used to the new toolbox. I'm not saying it's a hard rule and you should never consider another language. I just answered the question of why someone would want to use javascript on the backend. It's not the only factor, but it's a factor.

Re: JavaScript is Eating the World

#249

Post by pier25 »

thehardsphere wrote: post #237
coldtea wrote: post #123

Earlier quoted context omitted.

> If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. > JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of ta…

> It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. Uhh, what? You don't consider "programatically manipulate the DOM in the browser" to be a niche?

Accessing the DOM is not really part of the language specification, but the browser API, no?

Re: JavaScript is Eating the World

#250

Post by [deleted] »

woah wrote: post #124
fundabulousrIII wrote: post #71

What they don't say in this panegyric to node is that.. 1. The language (js) is absolutely horrific. 2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics. 3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug. 4. It is designed to the lowest possible specification for devel…

There are languages that I like better than JS. However, JS servers power trillions of dollars of business. People who grasp for reasons to hate on JS are a little like people who get into flame wars about video game franchise rivalries. It's symptomatic of deep unmet emotional needs in that person's life.

[deleted]
Post reply on HN