[marcosdumay]

It's the result of the data isolation above anything else attitude of Javascript.

Or, in other words, it's the unavoidable result of insisting on using a language created for the frontend to write everything else.

You don't need to rewrite your code in Rust to get that saving. Any other language will do.

(Personally, I'm surprised all the gains are so small. Looks like it's a very well optimized code path.)

[smolder]

I rewrote the same web API in Javascript, Rust, C#, and Java as a "bench project" at work one time. The Rust version had smallest memory footprint by far as well as the best performance. So, no, "any other language" [than JS] is not all the same.

[jeroenhd]

C# and Java are closer but not really on the level of Rust when it comes to performance. A better comparison would be with C++ or a similarly low-level language.

In my experience, languages like Ruby and Python are slower than languages like Javascript, which are slower than languages like C#/Java, which are slower than languages like C++/Rust, which are slower than languages like C and Fortran. Assembly isn't always the fastest approach these days, but well-placed assembly can blow C out of the water too.

The ease of use and maintainability scale in reverse in my experience, though. I wouldn't want to maintain the equivalent of a quick and dirty RoR server reimplemented in C or assembly, especially after it's grown organically for a few years. Writing Rust can be very annoying when you can't take the normal programming shortcuts because of lifetimes or the borrow checker, in a way that JIT'ed languages allow.

Everything is a scale and faster does not necessarily mean better if the code becomes unreadable.

[kelnos]

> A better comparison would be with C++ or a similarly low-level language.

Right, but then I'd have to write C++. Shallow dismissal aside (I really do not enjoy writing C++), the bigger issue is safety: I am almost certain to write several exploitable bugs in a language like C++ were I to use it to build an internet-facing web app. The likelihood of that happening with Rust, Java, C#, or any other memory-safe language is much lower. Sure, logic errors can result in security issues too, and no language can save you from those, but that's in part the point: when it comes to the possibility of logic errors, we're in "all things being equal" territory. When it comes to memory safety, we very much are not.

So that pretty much leaves me with Rust, if I've decided that the memory footprint or performance of Java or C# isn't sufficient for my needs. (Or something like Go, but I personally do not enjoy writing Go, so I wouldn't choose it.)

> Everything is a scale and faster does not necessarily mean better if the code becomes unreadable.

True, but unreadable-over-time has not been my experience with Rust. You can write some very plain-vanilla, not-"cleverly"-optimized code in Rust, and still have great performance characteristics. If I ever have to drop into 'unsafe' in a Rust code base for something like a web app, most likely I'm doing it wrong.

[sunshowers]

Rust provides better tools to handle logic errors as well. Sum types/exhaustive pattern matching, affine typing, and mutability xor aliasing let you model many kinds of real-world logical constraints within the type system. (And not just theoretically -- the teams and projects I work on use them every day to ship software with fewer bugs than ever.)

[tialaramex]

I'd even argue that idiomatic Rust is less prone to those "logic errors" than C++ and the language design gives you fewer chances to trip over yourself.

Even the basics, nobody is calling Rust's [T]::sort_unstable without knowing it is an unstable sort. Even if you've no idea what "stability" means in this context you are cued to go find out. But in C++ that is just called "sort". Hope you don't mind that it's unstable...

[Edited because I can't remember the correct order of words apparently.]

[pdimitar]

> when it comes to the possibility of logic errors, we're in "all things being equal" territory. When it comes to memory safety, we very much are not.

Very well summed. I'll remember this exact quote. Thank you.

[smolder]

My goal with the project was to compare higher performance memory safe languages to Javascript in terms of memory footprint, throughput, latency, as well as the difficulty of implementation. Rust was, relatively speaking, slightly more difficult: because concurrently manipulated data needed to be explicitly wrapped in a mutex, and transforming arbitrary JSON structures (which was what one of the endpoints did) was slightly more complex than in the others. But, overall, even the endpoints that I thought might be tricky in Rust weren't really what I'd call difficult to implement, and it wasn't difficult to read either. It seemed worth the trade-off to me and I regret not having more opportunities to work with it professionally in the time since.

[jandrewrogers]

C and Fortran are not faster than C++, and haven't been for a long time. I've used all three languages in high-performance contexts. In practice, C++ currently produces the fastest code of high-level languages.

[tialaramex]

Because C++ doesn't restrict aliasing there are a bunch of cases where it's just unavoidably worse. The compiler is obliged to assume that if there are potentially aliasing objects of type T: T1 and T2 then mutating T1 might also mutate T2 (because it may be an alias), so therefore we must re-fetch T2.

[jandrewrogers]

That is more theory than reality in high-performance code, and was noted as such even back when I was in HPC. The compiler isn’t stupid and normal idiomatic high-performance code in C++ has codegen that is essentially indistinguishable from the FORTRAN in virtually all cases. It has been a couple decades and many compiler versions since anyone had to worry about this. One of the things that killed the use of FORTRAN in HPC is that it empirically did not produce code that was any faster than C++ in practice and was much more difficult to maintain. Advantage lost.

The extensive compile-time metaprogramming facilities in C++ give it unique performance advantages relative to other performance languages, and is the reason it tends to be faster in practice.

[consteval]

Generally, the reason C++ is so stupidly fast compared to even C is because a lot is pushed to compile-time via templates. You can avoid passing pointers, doing indirection, and you can even inline functions altogether. Flattening objects and methods to encode as much information as you can in the type at compile-time will almost always be much faster than doing dynamic redirection at runtime.

For example, compare the speed and implementation of std::sort and qsort (it's almost an order of magnitude difference in run time for big N!)

[tialaramex]

Sure, but note that unlike the aliasing overhead the C programmer can just specialise by hand to get the same results.

Also, sorting is something where algorithmic improvement makes a sizeable difference so you need to be sure you're either measuring apples vs apples or that you've decided up front what your criteria are (e.g. lazy people will use the stdlib so only test that; or nobody sorts non-integer types so I only test those)

For some inputs if you're willing to use a specialist sort the best option today is C. If you care enough to spend resources on specialising the sort for your purpose that's a real option. Or alternatively if you can't be bothered to do more than reach for the standard library of course Rust has significantly faster sort (stable and unstable) than any of the three C++ stdlibs. Or maybe you want a specialized vector sort that Intel came up with and they wrote it for C++. Hope portability wasn't an issue 'cos unsurprisingly Intel only care if it works on Intel CPUs.

[uecker]

I am skeptical about this. Optimizer can also specialize functions and programmers can do too. Excessive specialization you get with templates always look beautiful in microbenchmarks but may not be ideal on a larger scale. There was a recent report analyzing the performance of Rust drivers vs C drivers and code bloat caused by monomorphization was an issue with the Rust things, and in my experience (also I do not have a reference) it is the same in C++.

[Klonoar]

I have written and worked on more than my fair share of Rust web servers, and the code is more than readable. This typically isn't the kind of Rust where you're managing lifetimes and type annotations so heavily.

[pdimitar]

> A better comparison would be with C++ or a similarly low-level language.

You probably want the apples-to-apples comparison but this looks an artificially limiting comparison; people are shilling, ahem, sorry, advocating for their languages in most areas, especially web / API servers. If somebody is making grandiose claims about their pet language then it's very fair to slap them with C++ or Rust or anything else that's actually mega ultra fast.

So there's no "better" comparison here. It's a fair game to compare everything to everything if people use all languages for the same kinds of tasks. And they do.

[neonsunset]

C# and Java are languages with very different performance ceilings and techniques available for memory management.

[manquer]

They are not saying every language will have same level of improvement as Rust, they are saying you can most of the improvements is available in most languages.

perhaps you get 1300MB to 20 MB with C# or Java or go, and 13MB with rust . Rust’s design is not the reason for bulk of the reduction is the point

[acdha]

Sure, but until people actually have real data that’s just supposition. If a Java rewrite went from 1300MB to, say, 500MB they’d have a valid point and optimizing for RAM consumption is severely contrary to mainstream Java culture.

[materielle]

I’m curious how Go stacks up against C# and Java these days.

“Less languages features, but a better compiler” was originally the aspirational selling point of Go.

And even though there were some hiccups, at least 10 years ago, I remember that mainly being true for typical web servers. Go programs did tend to use less memory, have less GC pauses (in the context of a normal api web server), and faster startup time.

But I know Java has put a ton of work in to catch up to Go. So I wonder if that’s still true today?

[neonsunset]

Go compiler is by far the weakest among those three. GC pause time is a little lie that leaves the allocation throttling, pause frequency and write barrier cost out of the picture. Go works quite well within its intended happy path but regresses massively under heavier allocation traffic in a way that just doesn’t happen in .NET or OpenJDK GC implementations.

[jasdfywu]

You also have to think about your target audience.

Are you hiring developers that are 100% fully conscious of concurrency and starvation or people that are only concerned with rest and vest and TC?

For either case Go is better.

* For people that are aware of concurrency, they will select Go because they appreciate its out-of-the-box preemptive concurrency model with work stealing.

* For people that are not aware of concurrency, then you should definitely use Go because they are not qualified to safely use anything else.

[materielle]

That’s why I specifically qualified my comment “within the context of a typical crud api server”.

I remember this being true 10 years ago. Java web servers I maintained had a huge problem with tail latency. Maybe if you were working on a 1 qps service it didn’t matter. But for those of us working on high qps systems, this was a huge problem.

But like I said, I know the Java people have put a ton of work in to try to close the gap with Go. So maybe this isn’t true anymore.

[vips7L]

You can't compare 10 years ago Java to current Go. 10 years ago was Java 8, we are currently on Java 23. The performance difference is massive between these 2 runtimes especially between the available garbage collectors.

Hazelcast has a good blog [0] on their benchmarks between 8 and some of the more modern runtimes, here is one of their conclusions:

> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pause

[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...

[neonsunset]

Typical CRUD API server is going to do quite a few allocations, maybe use the "default" (underwhelming) gRPC implementation to call third-parties and query a DB (not to mention way worse state of ORMs in Go). It's an old topic.

Go tends to perform better at "leaner" microservices, but if you are judging this only by comparing it to the state of Java many years ago, ignoring numerous alternative stacks, it's going to be a completely unproductive way to look at the situation. Let's not move the goalposts.

[tacticus]

Depends if you're measuring .net as written by members of the core team with all the tricks and hacks or .net as written by everyone else

[randomdata]

> “Less languages features, but a better compiler” was originally the aspirational selling point of Go.

A faster compiler was the aspirational selling point. As legend has it, Go was conceived while waiting for a C++ program to compile.

Before what was called "Go 2" transitioned the project away from Google and into community direction there was some talk of adding no more features, instead focusing on improving the compiler... But since the community transition took place, the community has shown that they'd rather have new features.

The "Go 1" project is no longer with us (at least publicly; perhaps it lives on inside Google?)

[dartos]

One of the big draws of go is ease of deployment. A single self contained binary is easy to package and ship, especially with containers.

I don’t think Java has any edge when it comes to deployment.

[jerven]

Java AOT has come a long way, and is not so rare as it used to be. Native binaries with GraalVM AOT are becoming more a common way to ship CLI tools written in JVM languages.

[neonsunset]

Native image continues to be relegated to a “niche” scenario with very few accommodations from the wider Java ecosystem.

This contrasts significantly with effort and adoption of NativeAOT in .NET. Well, besides CLI, scenarios where it shines aren’t those which Go is capable of addressing properly in the first place like GUI applications.

[consteval]

It's hard to compare Rust or C++ to GC langs like C# and Java because their runtimes are greedy. The CLR will easily take 10x more memory than it's currently using such that future allocations are much, much faster. So measuring the memory consumption of a JVM/CLR application is not simple. You need to ask the GC how much memory you're actually using - you can't just check the task monitor.

Also you can do that same thing in Rust or C++ too. Very common in C++, speeds up programs quite a bit.

[neonsunset]

> The CLR will easily take 10x more memory

CoreCLR itself doesn't take much memory - GC might decide on a large heap size however. Do give .NET 9 a try with Server GC which has enabled DATAS by default. It prioritizes smaller memory footprint much more heavily and uses a much more advanced tuning algorithm to balance out memory consumption, allocation throughput and % of time spent in GC.

[btilly]

Your claim makes zero sense to me. Particularly when I've personally seen similar behavior out of other languages, like Java.

As I said in another comment, the most likely cause is that temporary garbage is not collected immediately in JavaScript, while garbage is collected immediately in Rust. See https://doc.rust-lang.org/nomicon/ownership.html for the key idea behind how Rust manages this.

If you truly believe that it is somehow due to data isolation, then I would appreciate a reference to where JavaScript's design causes it to behave differently.

[jvanderbot]

"Rust" really just means "Not javascript" as a recurring pattern in these articles.

[IshKebab]

Not exactly. It wouldn't help if you moved your JavaScript to Python or Ruby or PHP... and anyway it's not really feasible from an FFI perspective to move it to anything other than Rust or C/C++ or maybe Zig. There's no good reason to pick C/C++ over Rust in most of these cases...

So "Rust" means "Not JavaScript, and also a bunch of other constraints that mean that Rust is pretty much the only sensible choice."

[marcosdumay]

> It wouldn't help if you moved your JavaScript to Python or Ruby or PHP...

Hum, no. The point is exactly that it would help a great deal if you moved to Python or Ruby or PHP.

Of course, Rust will give you even better memory efficiency. But Javascript is a particularly bad option there, and almost anything else would be an improvement. ("Almost", because if you push it enough and move to something like MathLab, you'll get worse results.)

[jerf]

If moving from JS to CPython would help, it might help memory consumption, because JITs generally trade speed for increased memory. But then you'd get slower execution, because CPython is slower than the JS engines we tend to use. PyPy might generally track JS on performance (big, BIG "it depends" because the speed profile of JITs are crazy complicated, one of my least favorite things about them) but then you're back to trading memory for speed, so it's probably net-net a sideways move.

Also, I don't know what Node is doing exactly, but if you take a lot of these dynamic languages and just fork them into multiple processes, which they still largely need to do to effectively use all the CPUs, you will generally see high per-process memory consumption just like Node. Any memory page that has a reference counter in it that is used by your code ends up Copied-On-Write in practice by every process in the steady state because all you need to do to end up copying the page is looking at any one reference it happens to contain in such a language. At least in my experience memory sharing gains were always minimal to effectively zero in such cases.

[acdha]

> But then you'd get slower execution, because CPython is slower than the JS engines we tend to use

I have not found this to be generally true. It depends heavily on whether your code is limited by pure high level language code[1] and culture makes comparisons harder if you’re not just switching languages but also abstraction models and a big stack of optimizations. In theory Java beats Python but in practice I’ve seen multiple times where a Java program was replaced by Python seeing whole number multiple improvements in performance and reductions in memory consumption because what was really happening is that a bunch of super complicated, optimization-resistant Java framework code was being replaced with much simpler code which was easier to optimize. Node is closer to that side of Java culturally, I think in both cases because people reacted to the limited language functionality by building tons of abstractions which are still there even after the languages improved so even though it’s possible to do much better a lot of programmers are still pushing around a lot of code with 2000s-era workarounds buried in the middle.

1. I’m thinking of someone I saw spend months trying to beat Python in Go and eking out a 10% edge because the bulk of the work devolved to stdlib C code.

[jerf]

I cite CPython specifically as CPython both to indicate that I mean that specific interpreter, and that I mean Python code, not Python driving other languages.

While I fully believe that a Python program with a superior O()-complexity class can beat Java (or, indeed, any language), and that a simpler Python program can hypothetically beat a Java program that is just too complicated, it would also be the case that taking that faster Python program and then porting that into Java would then see order of magnitude+ speed increases. Python is slow. When comparing languages I generally add the caveat "with some non-zero and comparable amount of time dedicated to optimization" to try to build a reasonable comparison, because most programs that have had no effort done on optimization at all will have their performance dominated by something stupid that the programmer didn't even realize they wrote.

The speed increases aren't relevant if the old Java was "too slow" and the new Python is "fast enough". Every program I've ever written could be made faster... but they're all fast enough now.

Pure Python with some non-trivial optimization effort can not beat a Java program with some non-trivial optimization effort, and that's before the Java code starts using multiple CPUs, if the problem is amenable to that.

This is not cheerleading, dumping on Python, or promoting Java, as if anything my personal biases are in fact the other way (tbh I don't particularly like either at this point but I'd much rather be using Python). This is just engineering stuff that good engineers should know: https://jerf.org/iri/post/2024/not_about_python/

[kelnos]

It depends, of course, on what you're doing. Re-using the toy web API in the article, I expect Python would be significantly faster. The QR code library you'd end up using in Python is probably written in C, and the web-serving portion should have comparable performance characteristics as you'd get with nodejs.

My guess is that if you were to rewrite this same app in straight Python (no Rust at all), it would probably already give you "Tier 3" performance.

But sure, I bet there are a bunch of use cases where nodejs would be faster than Python.

[chrisldgk]

This seems a bit unfair to JavaScript. There’s a lot of optimizations made to the language and its runtimes that have made a more than viable choice for server side applications over the years. The JavaScript that started as a Webbrowser client side language is very different from the ECMAScript that we have today. Depending on its usage it can also be one of the fastest, only regularly eclipsed by rust[1]. So no, JavaScript really isn’t a bad option for server side applications at all.

[1] https://www.techempower.com/benchmarks/#hw=ph&test=composite...

[consteval]

Not sure about Python or Ruby, but PHP is definitely MUCH faster. It helps a lot when a ton of the code is in C modules (which I guess is maybe the case for Python too?)

[chipdart]

> There's no good reason to pick C/C++ over Rust in most of these cases...

What leads you to believe in that?

[IshKebab]

Because except in rare cases Rust can do everything C++ can do with basically the same performance profile, but it does it with modern tooling and without the security, reliability and productivity issues associated with C++'s pervasive Undefined Behaviour.

There are some cases where C++ makes sense:

* You have a large existing C++ codebase you need to talk to via a large API surface (C++/Rust FFI is not great)

* You have a C++ library that's core to your project and doesn't have a good Rust alternative (i.e. Qt)

* You don't like learning (and are therefore in completely the wrong industry!)

[acdha]

The constant stream of CVEs caused by even experts failing to use those languages correctly on the one side, and the much better developer experience on the other. C++ isn’t horrible but it’s harder to use, harder to find good developers, and there are relatively few cases where there’s something easier to do in C++ than Rust which would warrant picking it. In most cases, it’ll be both faster and safer if you use a modern language with good tooling instead and take advantage of the easy C bindings if there’s a particular library you need.

[chipdart]

> The constant stream of CVEs (...)

It's a function of popularity and widespread use. The only languages that do not feature CVEs are the ones that are not used.

Eve Rust started to feature in CVEs, including memory safety problems in it's standard library. Somehow that fact is omitted from these discussions.

> (...) even experts failing to use those languages correctly (...)

I couldn't help noticing you felt the need to resort to weasel words like "correctly" to add color to an unsubstantiated personal assertion.

What's the best example you can come up with to support your opinion?

> C++ isn’t horrible but it’s harder to use, harder to find good developers (...)

This personal assertion is comical, as recruiters are systematically targeting C++ developers for Rust positions, and Rust is notoriously bad for newbies to onboard onto.

I'd prefer these debates were kept at an objective and substantiated level, but it seems that's too much to ask. It seems it's easier to throw unsubstantiated claims around and wait to see if half the bullshit sticks.

[acdha]

> Somehow that fact is omitted from these discussions.

Oh, please. Nobody is saying that Rust is perfect, only that the defect rate in normal usage is considerably lower and tend to be concentrated in areas like “unsafe” blocks rather than spread randomly around the code base.

> I couldn't help noticing you felt the need to resort to weasel words like "correctly" to add color to an unsubstantiated personal assertion. … This personal assertion is comical, as recruiters are systematically targeting C++ developers for Rust positions, and Rust is notoriously bad for newbies to onboard onto.

“Correctly” isn’t a weasel word, especially not in the context of describing how a program functions. I was referring to the common excuse that has cropped up over decades where language proponents try to blame problems on the user rather than acknowledging that certain features are hard to use safely.

I’ve been hearing people say that C/C++ are fine and you just need better programmers since the 90s, which has not been an effective strategy in reducing the number of security vulnerabilities. My comment about easier to learn was written in the context of reaching the level needed to reliably write safe code, not just producing a compilable program which doesn’t immediately crash since even large, elite teams with enormous resources struggle with memory safety bugs in large C/C++ code bases.

For example, Android reports halving their code rollback rate and a significant reduction in the number of vulnerabilities by switching to memory-safe languages. Clearly relying on programmer vigilance and testing was not as effective as picking tools which made certain classes of error much harder.

https://security.googleblog.com/2024/09/eliminating-memory-s...

[jrpelkonen]

I’m not a big believer in absolutes like that, but unless a person is already proficient in C or C++, or there’s an existing C++ library, etc., I find it hard to justify using those over Rust. Rust has great tooling, good cross compilation support, good quality standard library and very good 3rd party ecosystem.

Also, it has so few footguns compared to C or C++ even modestly experienced developers can safely use it.

[crabmusket]

A host of a prominent C++ podcast expressed more or less this sentiment recently (on an ep within the last year). He was being a little bit "devil's advocate", and not suggesting stopping working with C++ altogether. But he could see most use cases of C++ being well satisfied by Rust, and with more ergonomic features like Cargo making the overall experience less of a chore.

[noirscape]

It's also frankly kinda like comparing apples and oranges as a language. JavaScript (and many of the "bad performance" high level languages minus Rails; Rails is bad and should be avoided for projects as much as possible unless you have lots of legacy cruft) are also heavily designed around rapid iteration. Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors.

Basically the best place where Rust can work is one where all variables, all requirements and all edgecases are known ahead of time or cases where manual memory safety is a necessity vis-a-vis accepting a minor performance hike from things like the garbage collector. This works well in some spaces (notably; systems programming, embedded and Browser Engines and I wouldn't consider the latter a valid target), but webserver development is probably one of the furthest places where you are looking for Rust.

[sophacles]

I found this to be untrue after I spent a little energy learning to think about problems in rust.

In a lot of languages you're working with a hammer and nail (metaphorically speaking) and when you move to a different language its just a slightly different hammer and nail. Rust is a screwdriver and screw though, and once I stopped trying to pound the screw in with the screwdriver, but rather use the one to turn the other, it was a lot easier. Greenfield projects with a lot of iteration are just as fast as doing it in python (although a bit more front-loaded rather than debugging), working new features into existing code - same thing.

[hathawsh]

I have often thought that programmers can actually just choose to make Rust easy by using a cyclic garbage collector such as Samsara. [1] If cyclic GC in Rust works as well as I think it can, it should be the best option for the majority of high level projects that need fast development with a trade-off of slightly lower efficiency. I suspect we'll see a "hockey stick" adoption curve once everyone figures this out.

[1] https://github.com/chc4/samsara

[0cf8612b2e1e]

I am still waiting for a scripting language to be bolted on top of Rust. Something that will silently Box all the values so the programmer does not have to think about the Rust specifics, but can still lean on all of the Rust machinery and libraries. If performance/correctness becomes a problem, the scripting layer could be replaced piecemeal with real Rust.

[hathawsh]

Perhaps you mean to say that you're waiting for a new scripting language to be created that's designed to be "almost Rust." That could be interesting! OTOH, the bindings for existing languages have matured significantly:

  - https://pyo3.rs/
  - https://github.com/neon-bindings/neon
  - https://github.com/mre/rust-language-bindings

[0cf8612b2e1e]

I definitely am thinking of something more Rust-forward. As Rusty as possible without having to worry about lifetimes, the borrow checker, whatever. Huge performance hit is acceptable, so long as it remains trivial to intermix the Rust+scripting code. Something that gives a smooth on-ramp to push the heavy bits into pure Rust if required. The Python+C strategy in a more integrated package.

[dartos]

And then we would’ve come full circle.

Beautiful

[jvanderbot]

The world is mad. After a decade of this, I give up. The cycles never end.

[worik]

This is what async/await rust programmers need

They are comfortable with runtimes

[echelon]

> Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors.

Misconception.

You will encounter the borrow checker almost never when writing backend web code in Rust. You only encounter it the first time when you're learning how to write backend code in Rust. Once you've gotten used to it, you will literally never hit it.

Sometimes when I write super advanced endpoints that mutate global state or leverage worker threads I'll encounter it. But I'm intentionally doing stuff I could never do in Python or Javascript. Stuff like tabulating running statistics on health check information, batching up information to send to analytics services, maintaining in-memory caches that talk to other workers, etc.

[materielle]

To put this another way: the Rust borrow checker attempts to tie memory lifetime to stack frames.

This tends to work well for most crud api servers, since you allocate “context, request, and response” data at the start of the handler function, and deallocate at the end. Most helper data can also be tied to the request lifecycle. And data is mainly isolated per-request. Meaning there isn’t much data sharing across multiple request.

This means that the borrow checker “just works”, and you probably won’t even need lifetime annotations or even any special instructions for the borrow checkers. It’s the idealized use case the borrow checker was designed for.

This is also the property which most GC languages like Java, Go, and C# exploit with generational garbage collectors. The reason it “works” in Java happens to be the same reason it works in Rust.

If your server does need some shared in-memory data, you can start by just handing out copies. If you truly need something more complicated, and we are talking about less than 10% of crud api servers here, then you need to know a thing or two about the borrow checker.

I’m not saying to rewrite web servers in Rust, or even advocating for it as a language. I’m just pointing out that a crud api server is the idealized use case for a borrow checker.

[echelon]

Incredibly well said. This is precisely what makes it work so well.

The language never set out to solve this problem. It wasn't an intentional design goal. The language design and problem space just happen to overlap more or less perfectly.

Complete serendipity.

[worik]

> the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors.

No

Once you learn to surrender to the borrow checker it becomes friend, not foe

You must submit

[jvanderbot]

You've described Rust's niche circumspectly: Systems, which have strict requirements and are fragile minefields.

The performance benefits of Rust were supposed to be a non-penalty: "Look, you can please please use this where you'd use C or C++ I promise it won't impact your performance!" Performance and GC overhead was the rejection de jure of every other C replacement.

But here we are: All friends are javascript front-enders-turned-backenders and are wondering if they should pick up Rust. It fits into a pattern of "new shiny" but it's good, don't get me wrong, if everyone experiences compiled languages and starts writing their headless code in sensible languages.

Repeating myself, but I'm just wondering why not Go? Why now?

[dralley]

>Rust is however very much not capable of rapid iteration, the borrow checker will fight you heavily every step of the way to the point where it demands constant refactors.

If you have sufficient experience, that's not really the case. Certainly compared to "comparable" languages like C++ where that time fighting the borrow checker might instead have been spent chasing random crashes.

[jvanderbot]

I have written both professionally for long enough to say that there's not real comparable advantage to either. You trade one complexity to fight for another when refactoring or iterating.

[consteval]

I don't think this is very true. Certainly, you can rapidly iterate in C#, and it's so much faster it's not even close.

But, if you want a dynamically typed experience, look no further than PHP or Perl. Also significantly faster, and, if I had to bet, you could probably iterate much faster in Perl. It wouldn't be fun, but honestly, I doubt that Perl is more footgunny than JS.

[timeon]

Writing server API'n'co is not unknown path that needs rapid prototyping.

[adastra22]

There is no reason data isolation should cost you 100x memory usage.

[chipdart]

> There is no reason data isolation should cost you 100x memory usage.

It really depends on what you mean by "memory usage".

The fundamental principle of any garbage collection system is that you allocate objects in the heap at will without freeing them until you really need to, and when that time comes you rely on garbage collection strategies to free and move objects. What this means is that processes end up allocating more data that the one being used, just because there is no need to free it. Consequently, with garbage collecting languages you configure processes with a specific memory budget. The larger the budget, the rarer these garbage collection strategies kick in.

I run a service written with a garbage collected language. It barely uses more than 100MB of memory to handle a couple hundred requests per minute. The process takes over as much as 2GB of RAM before triggering generation 0 garbage collection events. These events trigger around 2 or 3 times per month. A simplistic critic would argue the service is wasting 10x the memory. That critic would be manifesting his ignorance, because there is absolutely nothing to gain by lowering the memory budget.

[nicoburns]

> That critic would be manifesting his ignorance, because there is absolutely nothing to gain by lowering the memory budget.

Given that compute is often priced proportional to (maximum) memory usage, there is potentially a lot to be gained: dramatically cheaper hosting costs. Of course if your hosting costs are small to be begin with then this likely isn't worthwhile.

[chipdart]

> Given that compute is often priced proportional to (maximum) memory usage, (...)

Let's look at numbers.

Hetzner sells vCPUs with 4GB of RAM for less than 5$/month, and 8GB of RAM for less than $10/month.

https://www.hetzner.com/cloud/

In my example, the cost of having garbage collection generation 0 events triggering twice a year would be an extra $5. If I wanted the frequency of these events to double, in theory I would save perhaps $2/month.

If I ran a web-scale service with 10 times the nodes as-is, we're talking about a $50/month price tag difference.

How much does a company charge for an engineer's hourly labor? How many years would it take to recover the cost of having an engineer tune a service's garbage collection strategy?

People need to thing things through before discussing technical merits.

[toast0]

> That critic would be manifesting his ignorance, because there is absolutely nothing to gain by lowering the memory budget.

Well, that depends on information you haven't provided. Maybe your system does have an extra 900 MB of memory hanging around; I've certainly seem systems where the minimum provisionable memory[1] is more than what the system will use for program memory + a full cache of the disk. If that's the case, then yeah, there's nothing to gain. In most systems though, 900 MB of free memory could go towards caching more things from disk, or larger network buffers, or something more than absolutely nothing.

Even with all that, lowering your memory budget might mean more of your working memory fits in L1/L2/L3 cache, which could be a gain, although probably pretty small, since garbage isn't usually accessed. Absolutely nothing is a pretty low barrier though, so I'm sure we could measure something. Probably not worth the engineering cost though.

There are also environments where you can get rather cheap freeing by setting up your garbage to be easily collected. PHP does a per-request garbage collection by (more or less) resetting to the pre-request state after the request is finished; this avoids accumulating garbage across requests, without spending a lot of effort on analysis. An Erlang system that spawns short lived BEAM processes to handle requests can drop the process heap in one fell swoop when the process dies; if you configure the initial heap size so no GCs are triggered during the lifetime of the process, there's very little processing overhead. If something like that fits your environment and model, it can keep your memory usage lower without a lot of cost.

[1] Clouds usually have a minimum memory per vCPU; if you need a lot of CPUs and not a lot of memory, too bad. I don't think you can buy DDR4 SIMMs of less than 4GB, or DDR5 of less than 8GB. Etc

[chipdart]

> Well, that depends on information you haven't provided. Maybe your system does have an extra 900 MB of memory hanging around;

That's not how it works. You cannot make sweeping statements over how something is bad when you fail to consider how it's used and what are the actual real world constraints.

For example, you're arguing that minimizing memory consumption is somehow desirable, and if you're making that claim you need to actually make a case. I clearly refuted your point by clarifying how things work in the real world. If you feel you can come up with a corner case that refutes it, just do it. So far you haven't, but that didn't stopped you from making sweeping statements.

[marcosdumay]

There are plenty of reasons. They are just not intrinsic to the isolation, instead they come from complications rooted deeply on the underlying system.

If you rebuild Linux from the ground up with isolation in mind, you will be able to do it more efficiently. People are indeed in the process of rewriting it, but it's far from complete (and moving back and forward, as not every Linux dev cares about it).

[btilly]

Unless you can be concrete and specific about some of those reasons, you're just replacing handwaving with more vigorous handwaving.

What is it specifically about JavaScript's implementation of data isolation that, in your mind, helps cause the excessive memory usage?

[marcosdumay]

Just a day or two ago, there was an article here about problems implementing a kind of read-only memory constraint that Javacript benefited from in other OSes.

[btilly]

I must have missed that article. Can you find it?

Unless you can come up with a specific reference, it seems unlikely that this would explain the large memory efficiency difference. By contrast it is simple and straightforward to understand why keeping temporary garbage until garbage collection could result in tying up a lot of memory while continually running code that allocates memory and lets it go out of scope. If you search, you'll find lots of references to this happening in a variety of languages.

[chipdart]

> Or, in other words, it's the unavoidable result of insisting on using a language created for the frontend to write everything else.

I don't think this is an educated take.

The whole selling point of JavaScript in the backend has nothing to do with "frontend" things. The primary selling point is what makes Node.js take over half the world: it's async architecture.

And by the way, benchmarks such as Tech Empower Web Framework still features JavaScript frameworks that outperform Rust frameworks. How do you explain that?

[nicce]

> The primary selling point is what makes Node.js take over half the world: it's async architecture.

It is the availability of the developers who know the language (JavaScript) (aka cheaper available workforce).

[consteval]

I disagree, it's 100% to do with the frontend and pretty much only because of that.

Node.js is popular because js is popular. You pretty much guarantee an infinite pool of developers for, like, ever. And you can even use those developers across the entire stack with greater velocity and much less onboarding.

async is cool, but not that cool. CGI was doing basically that a long time ago, and it was even more automagical.

> Tech Empower Web Framework still features JavaScript frameworks that outperform Rust frameworks. How do you explain that?

The benchmarks are constructed in such a way that highlights the strengths of the particular JS JIT implementation. JS is good at a lot of things, so if you just do those things, it might appear that it has okay performance.

People do the same thing with C# vs C++; this has been a problem forever. Sure, C# is about as fast or close if you have 16 gigs allocated to the GC and your app is using 100 megs. Now run at 95% memory usage with lots of churning and the order of magnitude differences come out. It's just a fundamental problem with GC langs.

[runevault]

Rust has had async for a while (though it can be painful, but I think request/response systems like APIs should not run into a lot of the major footguns).

C# has excellent async for asp.net and has for a long time. I haven't touched Java in ages so cannot comment on the JVM ecosystem's async support. So there are other excellent options for async backends that don't have the drawbacks of javascript.

[nh2]

It's important to be aware that often it isn't the programming language that has the biggest effect on memory usage, but simply settings of the memory allocator and OS behaviour.

This also means that you cannot "simply measure memory usage" (e.g. using `time` or `htop`) without already having a relatively deep understanding of the underlying mechanisms.

Most importantly:

libc / malloc implementation:

glibc by default has heavy memory fragmentation, especially in multi-threaded programs. It means it will not return `malloc()`ed memory back to the OS when the application `free()`s it, keeping it instead for the next allocation, because that's faster. Its default settings will e.g. favour 10x increased RESident memory usage for 2% speed gain. Some of this can be turned off in glibc using e.g. the env var `MALLOC_MMAP_THRESHOLD_=65536` -- for many applications I've looked at, this instantaneously reduced RES fro 7 GiB to 1 GiB. Some other issues cannot be addressed, because the corresponding glibc tunables are bugged [2]. For jemalloc `MALLOC_CONF=dirty_decay_ms:0,muzzy_decay_ms:0` helps to return memory to the OS immediately.

Linux:

Memory is generally allocated from the OS using `mmap()`, and returned using `munmap()`. But that can be a bit slow. So some applications and programming language runtimes use instead `madvise(MADV_FREE)`; this effectively returns the memory to the OS, but the OS does not actually do costly mapping table changes unless it's under memory pressure. As a result, one observes hugely increased memory usage in `time` or `htop`. [2]

The above means that people are completely unware what actually eats their memory and what the actual resource usage is, easily "measuring wrong" by factor 10x.

For example, I've seen people switch between Haskell and Go (both directions) because they thought the other one used less memory. It actually was just the glibc/Linux flags that made the actual difference. Nobody made the effort to really understand what's going on.

Same thing for C++. You think without GC you have tight memory control, but in fact your memory is often not returned to the OS when the destructor is called, for the above reason.

This also means that the numbers for Rust or JS may easily be wrong (in either direction, or both).

So it's quite important to measure memory usage also with the tools above malloc(), otherwise you may just measure the wrong thing.

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=14827

[2]: https://downloads.haskell.org/ghc/latest/docs/users_guide/ru...

[Capricorn2481]

Why does no one ever talk about this? It is so weird to see a memory pissing match with no context like this. Thank you

[nh2]

Because people don't know.

That includes users of low-level languages. They assume free() means free when it doesn't.

And assumption- and hope-driven development are less bothersome to the mind!

It's annoying to have to fact-check every sane assumption, but unfortunately it's required. Of course for anything that exists, somebody somewhere built a cache around it for average-case performance gains that destroys simplicity and adds pathological edge cases.

Most people learn this only when they try to run a real-world system that inexplicably runs out of RAM, or if they see unreasonably large number and actually start digging instead of just accepting it.