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

271–280 of 323 posts

Re: JavaScript is Eating the World

#271

Post by coldtea »

rootlocus wrote: post #253
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…

> I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of tasks, and it totally obliterates Python, PHP, Ruby, and co in speed. Any proof for this? EDIT: According to "The Computer Language Benchmarks Game" JavaScript fares pretty well against Python [1] or Ruby [2] but not really that great against C [3] or Java [4] in the CPU intensive benchmarks. 1 http://benchmarksgame.alioth.debian.org…

>JavaScript fares pretty well against Python [1] or Ruby [2] but not really that great against C [3] or Java [4] in the CPU intensive benchmarks.

Considering is a non-static, totally dynamic language, with all kinds of dynamicity in it, it does totally fine. 10x to 30x faster than Python, Ruby etc, and 3x to 5x slower than C/Java is totally fast.

Re: JavaScript is Eating the World

#272

Post by Larrikin »

falcolas wrote: post #43
lunchables wrote: post #14

Earlier quoted context omitted.

I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.

It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.

Kotlin is slowly becoming s language that can do all of that. It's production ready for anything that uses java, js support is coming along great, and their slowly moving towards native.

Re: JavaScript is Eating the World

#273

Post by vardump »

jononor wrote: post #58
jcelerier wrote: post #27

Earlier quoted context omitted.

> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the…

> I/O is not going to be any faster by having more threads.

That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters.

Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.

Re: JavaScript is Eating the World

#274

Post by mmirate »

quacker wrote: post #211
mmirate wrote: post #104

Earlier quoted context omitted.

Python is still dynamically typed, though at least it is less weakly-typed than JS. While the benefits of moving any distance away from JS's weak-typing are certainly obvious, why stop at Python rather than a language which is both strongly and statically typed?

They didn't mention anything about typing as reason for switching. They said "It's a really frustrating ecosystem to work in, all the deps, toolchains, build process is extremely fragile." They switched to python for the ecosystem and tooling.

> fragile

... was the keyword, or at least that was how I read it.

Re: JavaScript is Eating the World

#275

Post by eropple »

defined wrote: post #260
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.

Seriously, use Erlang or Elixir and have both concurrency and ease of programming and debugging relative to Node.js. Spoken as someone who has created multiple Erlang projects with close to zero unintended downtime for months or years in production.

I like what I've seen of Elixir. (As a Rubyist by habit, I should.) But it doesn't do what Node does:

Use JavaScript.

We can say 'til we're blue in the face that that doesn't matter (and I do, as a Ruby/Grape guy for APIs), that matters. Lowered impedance mismatch is a thing. I use Ruby because I'm still more productive there--but that's a library problem (RDBMSes), not a language problem.

Node really is good-enough. I'd go for either a JVM or a BEAM-based solution if I was building things where there were significant and meaningful losses on the table if I fucked up, but for most things? Nah. Just...not important enough.

Re: JavaScript is Eating the World

#276

Post by thehardsphere »

pier25 wrote: post #247
thehardsphere wrote: post #230

Earlier quoted context omitted.

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?

I doubt that is accurate, but if it is, it is irrelevant; those "C++ threads" are not available to you to use in your program the way you see fit.

Re: JavaScript is Eating the World

#277

Post by thehardsphere »

softawre wrote: post #231
thehardsphere wrote: post #219

Earlier quoted context omitted.

Compile-time bloat and runtime bloat are not equivalent. Runtime bloat inflicts pain upon users and therefore is usually worse.

Yes.. Don't you think that's why he bothered mentioning the words "runtime" and "compile-time"?

Well, the way I read what he wrote was that he was suggesting that bloat is bloat wherever it happens so that it's all a wash.

Re: JavaScript is Eating the World

#278

Post by jononor »

vardump wrote: post #273
jononor wrote: post #58

Earlier quoted context omitted.

I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the…

> I/O is not going to be any faster by having more threads. That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters. Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.

As far as I can tell, Node.JS actually does use multiple threads for I/O, both for for networking and filesystem operations. But this implementation detail is not something programmers using it needs to think about.

Re: JavaScript is Eating the World

#279

Post by wolco »

coldtea wrote: post #123
rootlocus wrote: post #110

Earlier quoted context omitted.

> 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? 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…

Maybe against php 4. PHP 7 is much faster
Post reply on HN