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

Back-end languages are coming to the front-end

github.com

Post reply on HN
Print view View original

151–160 of 328 posts

Re: Back-end languages are coming to the front-end

#151

Post by eyelidlessness »

KwisaksHaderach wrote: post #134
samhw wrote: post #128

Earlier quoted context omitted.

> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…

It's fantastic for I/O-heavy 'server'-type code I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.

If your workload is actually CPU-heavy, Node’s solutions for this are several:

- worker threads - child processes/IPC - native bindings (n-api/gyp/etc) - WASM/WASI

Maybe so many as to cause choice/research paralysis. If you’re primarily interested in writing JS/TS, worker threads are a great option. And for most use cases you don’t need to worry about shared memory/atomics, postMessage has surprisingly good performance characteristics.

Re: Back-end languages are coming to the front-end

#152

Post by samhw »

KwisaksHaderach wrote: post #134
samhw wrote: post #128

Earlier quoted context omitted.

> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…

It's fantastic for I/O-heavy 'server'-type code I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.

Interesting! I'm not a Node expert specifically, just a general systems programmer, but I might be able to give you some pointers.

Is your application I/O-bound, or CPU-bound? i.e. what's the bottleneck, which you would have to increase in order to speed it up? Your comment is a bit ambivalent given your remark about adding "more and more CPU processing".

If you're I/O-bound, then you're free to do more CPU processing. If/once you're CPU-bound, there are a few questions:

- Are you using all your cores? Node is single-core, so you may need to run one Node process per core. This obviously depends on how parallelisable your program is. Edit: u/eyelidlessness has given some more Node-specific suggestions that may allow true shared-memory concurrency, or even shared-memory parallelism across several cores.

- Are you able to increase your CPU's clock speed? (This obviously assumes a cloud environment or something similar, where you can easily swap out CPUs. I'm not talking about overclocking.)

- Have you profiled exactly what is using so much CPU? Is there some wasteful computation you can remove? Try `node --cpu-prof` to generate a profile. If you're unfamiliar with analysing profiles, Brendan Gregg's blog is the place to go. This article from the guy who wrote Sled is also a very good longread: https://sled.rs/perf.html

I'm surprised if you're really using so much CPU in a Node application, at least if it's a typical CRUD one. I'd strongly suppose that you're doing some wasteful computation, either in an algorithm in your business logic, or else in inefficient JSON parsing. Let me know if you can give any more info :)

Edit: It looks like u/eyelidlessness has given some more Node-specific tips for improving CPU saturation. I'd definitely check out the pointers that he/she gave.

Re: Back-end languages are coming to the front-end

#154

Post by BoorishBears »

ihateolives wrote: post #65
ivanmontillam wrote: post #47

I've been looking for this for a long while. I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript). What doesn't make sense to me is that JavaScript has genuinel…

I'm really sad that Dart didn't make it as Javascript replacement. It's much better designed language, but didn't get traction.

Dart is not fhat much better.

In a period where most languages are experiencing a "rebirth" as a well thought out modern language, Dart feels like the "before" waiting for an "after".

I'd be deeply disappointed if we had progressed from Js to Dart, and it's why I'm not a fan of Flutter

(Java => Kotlin, Obj C => Swift, Js => Ts, Erlang => Elixr, etc.)

Re: Back-end languages are coming to the front-end

#155

Post by jvanderbot »

samhw wrote: post #128
jvanderbot wrote: post #127

Earlier quoted context omitted.

That is impressive, and not unexpected given the (likely) billions of dollars of investment in things like nodejs. I did not mean to disparage it in itself just because it was developed for a particular domain. However, if "An embedded system uses the internet to communicate" has become synonymous with "It runs linux and uses web services and nodejs" then that would be a perfect example of contorting the application…

> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…

My CS advisor in undergrad stirred a love of safety in me with Ada. I've always wanted to get back into it. Recent headlines have made me think that Rust will move in that domain. In 10 years, probably a lot of safety-critical systems will use a lot of Rust. Ada was (to my knowledge) never particularly well accepted by "the masses", whereas Rust is. It was just too early.

Re: Back-end languages are coming to the front-end

#156

Post by KwisaksHaderach »

eyelidlessness wrote: post #151
KwisaksHaderach wrote: post #134

Earlier quoted context omitted.

It's fantastic for I/O-heavy 'server'-type code I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.

If your workload is actually CPU-heavy, Node’s solutions for this are several: - worker threads - child processes/IPC - native bindings (n-api/gyp/etc) - WASM/WASI Maybe so many as to cause choice/research paralysis. If you’re primarily interested in writing JS/TS, worker threads are a great option. And for most use cases you don’t need to worry about shared memory/atomics, postMessage has surprisingly good performan…

Workers threads spawn a new JS VM( which implies a new GC) for each worker! We tried it and the gains from parallelism stopped when there were half as many workers as CPUs.

Re: Back-end languages are coming to the front-end

#157

Post by jatone »

throwaway984393 wrote: post #7

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy,…

laugh

1. software is a VERY new discipline. its also one of the most malleable. I doubt we'll ever stop seeing churn in this space.

2. we don't reinvent the how we build houses each year. you can safely ignore all this new fangled web things if you want.

3. churn is also domain specific. we've more or less stopped inventing drastically new APIs at the OS/system level.

4. software for UIs have never been great. we are still learning how to build them. most of the major players in UI software still exist, windows, java, macosx (cocoa?), QT, GTK, Enlightment, and HTML/CSS/javascript.

finally software will continue to evolve as base layers add the ability for higher layers to do things differently. for example as CPU get more and more vector operations that can dramatically change how we write code.

this churn is a positive not a negative on the industry.

Re: Back-end languages are coming to the front-end

#158

Post by samhw »

patrec wrote: post #145
samhw wrote: post #120

Earlier quoted context omitted.

> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just ha…

> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.

Sorry, I should have been clearer: I meant that it's had the most manpower dedicated to optimising it, not that it's necessarily the most optimal. It's hard to make apples-to-apples comparisons in that respect, given the significant differences between different language specifications. (For instance, it's hard for anyone to write a reference-compliant interpreter for Python which is as fast as the interpreter they could write for, say, Ada or Haskell.)

Re: Back-end languages are coming to the front-end

#160

Post by samhw »

VWWHFSfQ wrote: post #147
samhw wrote: post #120

Earlier quoted context omitted.

> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just ha…

It's my understanding that LuaJIT still beats V8 Javascript by a considerable margin. And I would say that Lua and Javascript are roughly comparable languages so it's an apples-to-apples comparison. > V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner) I don't think this is true. It's very popular but LuaJIT is still more performant.

Sorry, you're the second person to say this, so clearly I didn't phrase my comment very well. I meant that it's the interpreter which has undergone the most optimisation, or alternatively which has had the most brainpower dedicated to optimising it.

I don't mean that the resulting interpreter is the most performant interpreter in some given benchmark. Like I said in my other reply, I don't think that can possibly be a meaningful benchmark, given different languages have different grammars and semantics which have a huge effect on the possibility of writing a performant interpreter (see: Python).

I can see that you preempt this point in your comment, but, I mean, what on earth does "roughly comparable languages" mean? Comparable how? Even superficially similar languages can have semantic differences which have a deep impact on optimisability. (For instance Python's C ABI, invisible to most end users, which notoriously limits interpreter implementations. Or its bytecode dispatch. Or its attribute dynamism, precluding memoisation of lookups. The possibility of `eval` is an enormous one too, which also applies to JS.)

Post reply on HN