4 ms·

Several orders of magnitude more RAM used by Java as well for the same amount of work.

by ttfkam 2y ago

dukeyukey 2y ago
That both isn't true and doesn't matter. What matters is the post is wrong.
- ttfkam 2y ago
  Been coding in Java since the late 1990s with v1.0.2 and continue to this day with v21. Java has been and remains a comparative memory hog. Yes, it is still popular, but it is far less popular than it used to be for greenfield projects. Go: just as fast to code in as Java with a similarly shallow learning curve. Ridiculously better for targets like AWS Lambda compared to Java, even with the advent of GraalVM. Rust: much steeper learning curve than any listed here, but can be optimized for both CPU and RAM usage to an extent no garbage collected language can match without the outsized memory integrity issues found in other systems level languages like C or C++. For AWS Lambda, GraalVM is three times worse by latency during cold starts and double the RAM of Go. Java proper is over five times worse by latency during cold starts and over five times the RAM usage, disqualifying it for the smallest Lambda size. You can implement a fully functional REST server in Rust in less than 20MB of RAM while it's in use with Actix or Axum and almost no CPU time. Java can get close to this in CPU efficiency, but I'd be astounded if you can even start the service in less than 50MB, and as soon as the first few requests come in, you're in the hundreds of megabytes in no time. These scenarios may not matter to you, but they matter to a lot of folks today and even more tomorrow. So here we are: TS/JS on the browser, often on the server, and the primary language for infrastructure tools like the AWS CDK. Go allows for much more efficient code than JS/TS on the backend once you start hitting the limits. Rust takes you to the absolute limits of the metal without compromising safety. It's not that Java couldn't fit in this mix. It's that there's no need for Java in that list. Java can't run in the browser, isn't anywhere near the best fit for lambdas, uses more resources for the same task (higher costs) in containers/K8s, and hits a hard limit for optimization at the systems level. Again, Java's definitely not going away, but it's clearly no longer the default choice for greenfield in a growing number of orgs.
  - riku_iki 2y ago
    > These scenarios may not matter to you, but they matter to a lot of folks today and even more tomorrow. is it really true? Counting 10s MB sounds like irrelevant to both today and tomorrow when servers with 100GBs are very affordable.
    - ttfkam 2y ago
      Except when 10s of thousands of requests can be handled in 32GB of RAM versus in Java where you need an instance four times as big to handle a load one fourth the size. That's annoying when you only need one or two instances. A real dent to your operating costs when the instance count gets much larger. https://instances.vantage.sh/ https://instances.vantage.sh/ A 2GB RAM C7G medium instance costs 2.4¢/hr on a reserved instance. A C7G 16xlarge with 128GB RAM costs $1.53/hr on a reserved instance. It adds up quick. Do you want to pay for the work getting done or pay a Java memory tax?
      - riku_iki 2y ago
        > It adds up quick. Do you want to pay for the work getting done or pay a Java memory tax? for some corp "$1.53/hr" is very small expenses, and it is easier to make things done in more feature rich ecosystem. Also, diffs in memory footprint is closer to 2 times based on various benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
        neonsunset 2y ago
        Too bad it doesn't include C# by default :) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpcore.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (it also keeps AOT[0] a specialized workload so you can't directly compare, which brings down the baseline RAM usage from 30 to 19MiB[1], though that is also problematic as the benchmark suite compiles AOT to x86-x64-v1 aka SSE2 (!) which would not run code with SSE4 or AVX2 SIMD implementations, and runs much slower for implementations expecting vectorization in general) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] I have no idea where 30MiB for most cases comes from, make a simple program and run it today and you'll see the RAM use will be below 10 MiB as you launch it (2-4MiB for AOT). The usage gets higher as you start loading dlls/dylibs/so's but those pages can be de-duplicated by OS so not much of an issue

Several orders of magnitude more RAM used by Java as well for the same amount of work.

by ttfkam 2y ago

Several orders of magnitude more RAM used by Java as well for the same amount of work.

dukeyukey 2y ago

That both isn't true and doesn't matter. What matters is the post is wrong.

ttfkam 2y ago
Been coding in Java since the late 1990s with v1.0.2 and continue to this day with v21. Java has been and remains a comparative memory hog. Yes, it is still popular, but it is far less popular than it used to be for greenfield projects. Go: just as fast to code in as Java with a similarly shallow learning curve. Ridiculously better for targets like AWS Lambda compared to Java, even with the advent of GraalVM. Rust: much steeper learning curve than any listed here, but can be optimized for both CPU and RAM usage to an extent no garbage collected language can match without the outsized memory integrity issues found in other systems level languages like C or C++. For AWS Lambda, GraalVM is three times worse by latency during cold starts and double the RAM of Go. Java proper is over five times worse by latency during cold starts and over five times the RAM usage, disqualifying it for the smallest Lambda size. You can implement a fully functional REST server in Rust in less than 20MB of RAM while it's in use with Actix or Axum and almost no CPU time. Java can get close to this in CPU efficiency, but I'd be astounded if you can even start the service in less than 50MB, and as soon as the first few requests come in, you're in the hundreds of megabytes in no time. These scenarios may not matter to you, but they matter to a lot of folks today and even more tomorrow. So here we are: TS/JS on the browser, often on the server, and the primary language for infrastructure tools like the AWS CDK. Go allows for much more efficient code than JS/TS on the backend once you start hitting the limits. Rust takes you to the absolute limits of the metal without compromising safety. It's not that Java couldn't fit in this mix. It's that there's no need for Java in that list. Java can't run in the browser, isn't anywhere near the best fit for lambdas, uses more resources for the same task (higher costs) in containers/K8s, and hits a hard limit for optimization at the systems level. Again, Java's definitely not going away, but it's clearly no longer the default choice for greenfield in a growing number of orgs.
- riku_iki 2y ago
  > These scenarios may not matter to you, but they matter to a lot of folks today and even more tomorrow. is it really true? Counting 10s MB sounds like irrelevant to both today and tomorrow when servers with 100GBs are very affordable.
  - ttfkam 2y ago
    Except when 10s of thousands of requests can be handled in 32GB of RAM versus in Java where you need an instance four times as big to handle a load one fourth the size. That's annoying when you only need one or two instances. A real dent to your operating costs when the instance count gets much larger. https://instances.vantage.sh/ https://instances.vantage.sh/ A 2GB RAM C7G medium instance costs 2.4¢/hr on a reserved instance. A C7G 16xlarge with 128GB RAM costs $1.53/hr on a reserved instance. It adds up quick. Do you want to pay for the work getting done or pay a Java memory tax?
    - riku_iki 2y ago
      > It adds up quick. Do you want to pay for the work getting done or pay a Java memory tax? for some corp "$1.53/hr" is very small expenses, and it is easier to make things done in more feature rich ecosystem. Also, diffs in memory footprint is closer to 2 times based on various benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - neonsunset 2y ago
        Too bad it doesn't include C# by default :) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpcore.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (it also keeps AOT[0] a specialized workload so you can't directly compare, which brings down the baseline RAM usage from 30 to 19MiB[1], though that is also problematic as the benchmark suite compiles AOT to x86-x64-v1 aka SSE2 (!) which would not run code with SSE4 or AVX2 SIMD implementations, and runs much slower for implementations expecting vectorization in general) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] I have no idea where 30MiB for most cases comes from, make a simple program and run it today and you'll see the RAM use will be below 10 MiB as you launch it (2-4MiB for AOT). The usage gets higher as you start loading dlls/dylibs/so's but those pages can be de-duplicated by OS so not much of an issue