Ask Slashdot: Would You Consider a Low-Latency JavaScript Runtime For Your Workflow? (github.com) 70
Amazon's AWS Labs has created LLRT an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient serverless applications.
Slashdot reader BitterEpic wants to know what you think of it: Traditional JavaScript runtimes like Node.js rely on garbage collection, which can introduce unpredictable pauses and slow down performance, especially during cold starts in serverless environments like AWS Lambda. LLRT's manual memory management, courtesy of Rust, eliminates this issue, leading to smoother, more predictable performance. LLRT also has a runtime under 2MB, a huge reduction compared to the 100MB+ typically required by Node.js. This lightweight design means lower memory usage, better scalability, and reduced operational costs. Without the overhead of garbage collection, LLRT has faster cold start times and can initialize in milliseconds—perfect for latency-sensitive applications where every millisecond counts.
For JavaScript developers, LLRT offers the best of both worlds: rapid development with JavaScript's flexibility, combined with Rust's performance. This means faster, more scalable applications without the usual memory bloat and cold start issues. Still in beta, LLRT promises to be a major step forward for serverless JavaScript applications. By combining Rust's performance with JavaScript's flexibility, it opens new possibilities for building high-performance, low-latency applications. If it continues to evolve, LLRT could become a core offering in AWS Lambda, potentially changing how we approach serverless JavaScript development.
Would you consider Javascript as the core of your future workflow? Or maybe you would prefer to go lower level with quckjs?
Slashdot reader BitterEpic wants to know what you think of it: Traditional JavaScript runtimes like Node.js rely on garbage collection, which can introduce unpredictable pauses and slow down performance, especially during cold starts in serverless environments like AWS Lambda. LLRT's manual memory management, courtesy of Rust, eliminates this issue, leading to smoother, more predictable performance. LLRT also has a runtime under 2MB, a huge reduction compared to the 100MB+ typically required by Node.js. This lightweight design means lower memory usage, better scalability, and reduced operational costs. Without the overhead of garbage collection, LLRT has faster cold start times and can initialize in milliseconds—perfect for latency-sensitive applications where every millisecond counts.
For JavaScript developers, LLRT offers the best of both worlds: rapid development with JavaScript's flexibility, combined with Rust's performance. This means faster, more scalable applications without the usual memory bloat and cold start issues. Still in beta, LLRT promises to be a major step forward for serverless JavaScript applications. By combining Rust's performance with JavaScript's flexibility, it opens new possibilities for building high-performance, low-latency applications. If it continues to evolve, LLRT could become a core offering in AWS Lambda, potentially changing how we approach serverless JavaScript development.
Would you consider Javascript as the core of your future workflow? Or maybe you would prefer to go lower level with quckjs?
no. (Score:4, Insightful)
Instead of using JavaScript, I would use a tool that suits the job at hand.
Re: (Score:3)
Exactly. Where I work we do a lot of datascience. Mostly Python. Its battletested and has some great libraries for handling huge datasets. We'd use R or julia, but nobody knows it, and thats fine. For our IOT telemetry we use a combination of Go (*excellent for servers, and absolutely nothing else) and C++ (excellent for almost everything but an absolute bitch to debug when things go wrong, and they *will* go wrong). Web shit, combination of python and js depending on the team, for back end and some nasty v
No. Use something else (Score:3, Interesting)
I do not want to use JavaScript on the server-side or embedded for these reasons:
1. Language not designed for small environments
2. Language defects - white space sometimes ending statements and sometimes not, modularity as an afterthought, lack of enforced at compile-time type checking, lax language syntax (parameters without a type declared), everything can have dynamic properties
3. Single threaded by default
4. Reliance on HTTP for communications instead of a connection oriented, type checked protocol
5. Ov
Re: (Score:2)
1. Language not designed for small environments
It was, which it to say it wasn't but what was a big environment when it was designed is now a small environment. It dates from 1995, from Nutscrape version 2.0. According to the 'tubes it required what was a fairly lavish 8M of RAM.
Stripped down version of Java, C#, go or Rust with most of the advanced language features removed
Why are "advanced language features" bad? What would you remove from, say Java or Rust which would improve it for use on the server or
Re: (Score:1)
Javascript suits most jobs better than any other language, and Amazon just added an option that increases its suitableness. AWS Lambda's two most popular languages are NodeJS Javascript and Python.
Python is in general slower. And this update in theory gives JS an even more massive edge, since Python too is a language that uses garbage collection.
Re:no. (Score:4, Insightful)
Javascript is the wrong tool for any job, including the one it was developed for.
Total nihilism (Score:1)
As a nihilist, I decline to accept the consensual herd hallucination which projects the existence of absolute truths, values, and communications. However, I consider the above to be pure wisdom. JavaScript needs to join AppleScript and Visual Basic in the pits of some demonic underworld belonging to a religion from another planet.
Re:no. (Score:4, Informative)
Javascript suits most jobs better than any other language
It doesn't. JavaScript's main advantage was that it was the privileged scripting language in the browser. That advantage is disappearing now that runtime and toolchain support is increasing for WebAssembly.
WebAssembly enables higher performance and lets you use your choice of language.
Re: no. (Score:5, Insightful)
Re: (Score:2)
No (Score:4, Insightful)
Use WebAssembly instead. It's higher performance than JavaScript and it brings every language to the web. Write in your language of choice and compile to WebAssembly.
WebAssembly is the future for application development on the web. JavaScript should just stick to being a scripting language.
If you need to do some scripting, use JavaScript. If you're developing an application, compile to WebAssembly.
Re: (Score:3)
Or just use C++ and a good desktop UI toolkit like QT (you can even let the graphic designer play along with that QML goodness).
Oh yeah....... I know, nobody wants desktop apps anymore. Jesus wept...
Re: (Score:2)
Or use C# and a UI toolkit like Avalonia and compile to both desktop and WebAssembly: https://avaloniaui.net/ [avaloniaui.net]
Re: No (Score:3)
I'd go with C# or Java, compiling languages with strong typing.
I hate runtime errors that a compiler should have caught. Script languages are especially sensitive to code rot, especially if you have many files. Change one, find two that are impacted by the change. Then at runtime around new year you'll find the one you missed.
Re: (Score:1)
That is why one long ago invented "unit tests", and why you have "linters" ...
Brogrammer very much?
Re: (Score:2)
Why make unit tests for stuff a compiler can do?
Re: (Score:1)
Because you are working with a language that has not such a compiler?
Not sure about what you want nitpick.
In JavaScript, SmallTalk and whatever, -- ah Python comes to mind -- you can do stuff you can not do in a static typed language. So: your decision which way you go. And while both ways benefit from unit tests, one way NEEDs them, the other not so much.
Re: (Score:3)
Because you are working with a language that has not such a compiler? Not sure about what you want nitpick.
This thread is precisely talking about JavaScript versus compiled languages. An advantage of a compile language is that you can cut down on the unit tests you need to write. WebAssembly enables compiled languages to run on what has traditionally been JavaScript only territory such as in the browser.
you can do stuff you can not do in a static typed language.
You can do any and all stuff in a statically typed language. There are no limitations.
Re: (Score:1)
No, this threat is not talking about that.
YOU are talking about that.
This thread is about replacing a heavy weight node.js JavaScript runtime with a light weight faster runtime.
No one is going to port a million lines of code to a web assembly runtime. For what reason would anyone throw away decades of manpower production code to run on your favourite webassembly runtime?
You can do any and all stuff in a statically typed language. There are no limitations.
No you can't. Objects that do not have a common type
Re: (Score:3)
This thread is about replacing a heavy weight node.js JavaScript runtime with a light weight faster runtime.
Yes. That replacement is WebAssembly. WebAssembly enables those compiled languages to supplant JavaScript in its traditional use cases.
Re: (Score:2)
Unit tests never cover all the cases that a compiler can discover. They are a poor excuse for problems that can be solved at compile time.
Even linters have their shortcomings.
With a compiled code it won't execute until it's properly and consistently built. With a linter you can choose to ignore warnings, and a lot of people just says "It's just a warning, nothing serious" and delivers what they have and then at a later time something goes wrong.
Re: (Score:1)
Yes, and?
About what do you want to nitpick?
JavaScript, SmallTalk, Python: have no static types system. Hence: no compiler taking benefit from it. Hence: you write unit tests. Or don't. Up to you.
Re: (Score:2)
Hence: no compiler taking benefit from it. Hence: you write unit tests. Or don't. Up to you.
Yes. WebAssembly enables more options for compiled languages both in the browser and on the server with higher performance than offered by JavaScript and without the need to replicate compile time checks with unit tests.
real-world WASM much worse (Score:3)
For every one typo the compiler catches in my library adapter Go code (already more annoying than Python which has excellent exceptions, hints, & no compile step just edit and rerun vs scrolling the nearly unreadable WASM build failure log)... there are literally 10x runtime errors from data i
Re: (Score:1)
Re: (Score:1)
I do :D
But I use Dart/Flutter.
Less hazzle than C++/Qt to get cross platform.
Re: No (Score:3)
Re: (Score:1)
WebAssembly is for running code in a web browser, or similar.
That is not the use case for a faster JavaScript engine that is supposed to run on a backen, or be the runtime core of your desktop application.
However WebAssembly "runtimes" do exist. But if you use that for your backen or as "main()" for your desktop app: why not write in a decent language then?
Re: (Score:2)
WebAssembly runs wherever you want it to run: browser, desktop, or server. It's an ideal fit for serverless environments like AWS Lambda.
Amazon made the switch to WebAssembly for Prime Video. WebAssembly makes it go faster while also giving them the flexibility to roll out updates to 8,000 device types: https://www.amazon.science/blo... [www.amazon.science]
Re: (Score:1)
WebAssembly is a portable bytecode specification.
It runs _nowhere_.
If you want to say, you can have execution platforms for it everywhere, sure why not.
Then you only need a toolchain to compile all your JS to that execution platform. Which on the other hand: the light weight JS VM would do for you for free.
I guess people who have to make such decisions: are aware about that.
Re: (Score:2)
the light weight JS VM would do for you for free
The WebAssembly runtime is lighter weight than JavaScript's runtime. It's one of the reasons why WebAssembly achieve higher performance than JavaScript.
Re: (Score:1)
But it does not run JavaScript .... gosh.
To much nitpicking makes you daft.
I know what web assembly is.
Re: (Score:2)
But it does not run JavaScript .... gosh
And? What am I using JavaScript for when I can compile to WebAssembly?
Re: No (Score:2)
Re: (Score:2)
No, it's a compilation target.
no. (Score:1)
If "every millisecond" truly counts... (Score:3)
You're gonna be using a compiled language, not something like this.
Re: (Score:3)
For the backend, this is my preferred choice. I have had to deal with a large AWS app that was written EXACTLY how AWS tells you to do it. It is slow as hell because it is too much scripting language. For services that you pay by the millsecond, why would you not want speed?
Write the backend in Go or C# or Java. Your frontend can be all JS or Python.
Something is missing here (Score:1)
It's built in Rust, utilizing QuickJS as JavaScript engine, ensuring efficient memory usage and swift startup.
QuickJS is written in C, not Rust
It's slow to execute, but fast to start and low memory overhead.
So there's no unpredictable slowdowns, it's predictably slow.
It'll scale well, because it's low overhead and quick to start, but it'll need to scale more because it's a slow interpreted JavaScript engine.
No, I have far better tools (Score:2)
Using Javascript beyond webpages ... (Score:4, Insightful)
(1) The only programming language I know is Javascript.
(2) My idiot boss made me use Javascript, would you like a copy of my Resume?
Re: (Score:1)
Why so dismissive?
In lines of code written JS is most certainly one of the most prominent ones.
If you look for job requirements on Linkedin: nearly every job at least has JavaScript as nice to have.
If you are a hater: JavaScript from 1995 that had problems in every browser, is not ECMAScript 15 from 2024.
Never met a JS hater you could give a 10 sentence summary about the language. And then a 3 sentence summary what he hates.
(P.S. I do not use JS ... but I probably can write a decent runtime/compiler for it
Re: (Score:2)
I've also inherited a project where JavaScript was used for rendering graphics. Despite far better libraries being available. Improper use of JavaScript. Why was it used, original dev only knew JavaScript.
adding another point (Score:3, Interesting)
None of the major organizations are interested in replacing the technology what is the plumbing.
Browser makers - Nope - The want to keep going JavaScript with its defects, HTML with its defects (magic string matching of id values), and patches which keep perpetuating the bad parts (Typescript)
ECMA - Nope - Spent too long fighting to make incremental JavaScript standards changes without addressing the fundamental problems with JavaScript
W3C - Nope - Same with keep going with XML based web standards (HTML),
Re: (Score:2)
Where I disagree with its use is outside web development. Outside there are generally far better options.
Re: adding another point (Score:2)
Re: (Score:2)
Just like how the people who can write without memory bugs are to expensive so now we have rust.
Those people don't exist.
Re: adding another point (Score:2)
And the people who think they are those people are the worst.
Re: adding another point (Score:2)
Re: (Score:2)
There's no one smart enough in the world that can do it.
Yes. All of programming history proves that. That's why so much work is going into mitigating memory safety bugs in everything from engineering practices, to programming languages, to code analyzers, to compilers, to the runtime environment, and even to the hardware.
Here's a memory safety bug in Linux from last year: https://pwning.tech/nftables/ [pwning.tech]
There are more this year: https://cybersecuritynews.com/... [cybersecuritynews.com]
There will be more next year.
Re: adding another point (Score:2)
Re: (Score:2)
It does and it is.
No (Score:2)
The time of developers and infra admins cost way more than running the hardware.
The extra complexity that this introduces either directly by configuration or indirectly by incompatibilities or even worse security vulnerabilities is not worth it.
Once you get big enough that the HW cost become a significant factor, you should have enough capital to switch.
Yes (Score:1)
I don't see the point. (Score:2)
JS is one of the most prevalent PL in layer 7 these days. For good reasons, even if some of those are historic. ... and yes this _is_ an advantage!
- open standards (Web)
- cross platform (FOSS Web)
- lots of shiny clicky touchy stuff (Web)
- lives in a space that is based on documents and static data and only introduces Turing as an afterthought (Web)
- the strict typing thing needed for bigger stuff is also an afterthought done with a trivially simple FOSS superset of JS that you can pick up and use in 5 Minut
Re: I don't see the point. (Score:2)
No (Score:2)
They would just as soon kiss a Wookie (Score:2)
Javascript is _NOT_ rapid development (Score:2)
"rapid development with JavaScript's flexibility..."
I just built something major using Javascript for the UI and Java for the server. The server part went ten times faster - literally. Reason: every time I change something about the design, the Javascript side has all kinds of issues that only pop up when running the app, but the Java side's compiler finds every issue right away. I pulled my hair out over the Javascript side. Yes, writing fresh code is 10% faster for Javascript, but getting things work as c
How about resident apps (Score:2)
you know, with a UI consistent with the operating system youâ(TM)re already in, no constant twiddling on the backend without seeing an obvious update, things like that. Now, you kids get off my lawn.
No but is this some agent crap? (Score:2)
Personally no that would be brain-dead. But.. is this maybe assuming tons of people will be writing crappy agent code and it should all run asynchronously on AWZ? If so that would not be too far off from say Salesforce's Flows which are built in a GUI and can be scheduled, or their async batch jobs which are both super anemic and are written in Apex (like Java). In that case, yeah I could envision a world where AWZ provides that. It gives me the heeby-jeebies to think of billions of instances of crummy and
What if..? (Score:2)
What if..? And I'm just spitballing here... What if we had applications on the client that processed data stored on a server? A client/server application, if you will. A little similar to this, but using a language more native to the operating system that allowed for far greater flexibility and capability while also being several orders of magnitude faster and more memory efficient.
Would that be something you'd consider using in your future workflow?
Tangentially, I'm thinking about a new licensing model as
Serverless? (Score:2)
This model is begging for a Perl revival.
Why cold starts? (Score:2)
I'm curious. Why is GC versus manually managed memory an issue during startup? I wouldn't think allocating memory would be noticeably faster for either approach, the difference would be behavior when freeing. With GC, freeing is instantaneous until the GC runs. With managed memory, freeing takes some time. Depending on what's going on, it's not obvious to me which will launch a JS engine faster. Do lots of objects get freed when starting up a JS runtime?
This is ignoring the obvious question: if milliseconds
node.js for the win (Score:2)
Seeing a lot of Java developers here that bash on Node but apparently haven't actually worked with it. Node is super capable as a web server. It is inherently event driven with non-blocking I/O, and yes you can make Java do that but it is much more effort. JavaScript is relatively easy to learn and you can use the same language on both the client side and the server side - a huge win. If you are picky about strong typing you can just use TypeScript.
And notice this article is about serverless computing, whic
Ideally, I'd be doing something else... (Score:2)
If it were 100% up to me, I'd be using Rust for everything. I prefer SPARK or Ada, but that knowledge is limited, although it is nice to be able to prove all states an application can get in. Save Javascript for stuff that runs in the user's browser... the backend should be something that is compiled, just for performance reasons, as (IIRC), JavaScript is 10 to 100 times slower than C or C++.
It will be nice when LLMs are able to figure out context and do inline assembly -- one step past a good optimizing