7 ms·

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 we

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.

manquer 2y ago
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 2y ago
  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.
jeroenhd 2y ago
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.
- Klonoar 2y ago
  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.
- jandrewrogers 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
      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!)
materielle 2y ago
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?
- dartos 2y ago
  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 2y ago
    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 2y ago
      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.
- neonsunset 2y ago
  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.
consteval 2y ago
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 2y ago
  > 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.

manquer 2y ago

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 2y ago
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.

jeroenhd 2y ago

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.

Klonoar 2y ago
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.
jandrewrogers 2y ago
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 2y ago
  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 2y ago
    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 2y ago
    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!)

materielle 2y ago

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?

dartos 2y ago
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 2y ago
  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 2y ago
    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.
neonsunset 2y ago
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.

consteval 2y ago

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 2y ago
> 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.