7 ms·

But "large project that uses language known for memory safety issues" describes a lot of important software today. It's not like there are tons of practical lan

But "large project that uses language known for memory safety issues" describes a lot of important software today. It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started. So while this may be unsurprising to those paying attention to Rust and memory safety, it's still relevant to a lot of software and a great confirmation of Rust's importance.

networkimprov 6y ago
Java is mature and regarded as high performance, even if it is a memory glutton.
- jolux 6y ago
  Rust has significantly less overhead than Java
  - lmm 6y ago
    Like a factor of 2 at best. Nice to have, but not the difference between usable and unusable.
    - scottlamb 6y ago
      Do you really think at any time in Chrome's lifespan that its developers would accept a decision that is so foundational (aka hard to reverse) and slows everything down by a factor of 2? I don't. If they had, I don't think it would be the most popular browser today, and arguably it wouldn't even still be around. IIRC, speed was a major selling point when it was released. (I also don't really think Java is that much slower but substitute a more precise guess and my statement stands. And I think Java and other GCed languages really do use ~2X as much RAM which is also unacceptable.)
      - lmm 6y ago
        The speed of Chrome's from-scratch JavaScript engine was a major selling point when released, yes. But that speed came from a lot of places - after all, competing JavaScript engines were also written in C++, and in particular areas V8 was thousands of times faster than them. Using Java over C++ would have meant a factor of 2 up-front performance cost. But it would also have meant significantly less time debugging, easier testing, faster iteration, better automated refactoring support... all of which would have added up to being able to spend more development effort finding the kind of algorithmic improvements that give you those 1000x speedups. I'm not at all convinced that the end result would have been slower.
        scottlamb 6y ago
        In particular areas (short timespans, specific tasks), Java can be thousands of times slower than C++/Rust. (Warmup/pre-JIT function evaluation, GC pauses, etc.) I have these kinds of performance rough spots, but I'm surprised to hear you do. It doesn't seem consistent with an argument for Java.
        scottlamb 6y ago
        s/have/hate/
        lmm 6y ago
        I don't think you'll find a realistic case where Java is thousands of times slower than C++/Rust. You're even less likely to find a case where it's a worse order of asymptotic complexity. Whereas you'll find plenty of cases where (at least 2008-era) SpiderMonkey is in a worse complexity order than V8.
        jolux 6y ago
        Client warmup times are not great. Java is incredibly fast but attempts to write an HTML engine in it in the past didn’t really pan out. Also, WebKit was already written in C++.
        6y ago
    - kelnos 6y ago
      A factor of 2 is a lot. Especially when considering that web browsers are already memory hogs and aren't all that fast.
    - kllrnohj 6y ago
      Java when written like C is within a factor of 2 at best. Java when written like Java isn't anywhere close to C/C++. And the gap is getting _wider_ as Java is an increasingly bad fit for modern CPUs due to the heavy pointer chasing nature of it. It desperately needs value types to stay competitive in a performance battle.
  - _ph_ 6y ago
    The previous posters were talking about languages available when chromium was started. So while Rust probably would be the language of choice today (see Firefox), it wasn't an option, but Java was already around and mature.
    - jolux 6y ago
      I don’t think Java is an option either for writing a web browser specifically for reasons of overheard. Rust is probably an option now but bringing up Java in this context was weird.
- erichocean 6y ago
  > regarded as high performance LOL. Is this LinkedIn? People on HN actually know Java requires mountains of C++ to be performant (c.f. Cassandra). Even then, actual C++ is 10x faster/lower latency (c.f. ScyllaDB). Update: Downvote all you want, Cassandra has tons of C++ to work around terrible Java performance, and the native C++ ScyllaDB absolutely smokes it in benchmarks. Not even close.
  - nurettin 6y ago
    Judging from your lol, you must surely remember debian aliot comparison pages, or various coding competition websites ranking the times for java solutions very close to c++ solutions back in the 2000s.
    - kllrnohj 6y ago
      Those comparison pages still exist: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Time has not been kind it seems. Not just the gap in performance, but also the gap in memory usage.
      - tom_mellior 6y ago
        The C and C++ versions of those benchmarks are manually vectorized to death using vector intrinsics. You don't have those in Java, nor in the standard versions of C and C++. So yes, those speedups are real, if you invest a lot of work. But if you don't, there is no magical 5x speedup of C++ over Java.
        unrealhoang 6y ago
        That is, if you write your program for the benchmark, i.e. writing C in Java by writing procedural code with packed primitives, or juggling and write all magic hacks just to make the code falls into correct JIT path. Otherwise, if you write normal OOP Java, 10x should be the performance gap.
- entha_saava 6y ago
  Hehe.. Lol no value types.. Lol virtual by default. Lol believing JIT can be efficient.
lmm 6y ago
> It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started. Chromium started in 2008, at which point there were plenty of mature cross-platform high-performance memory-safe languages that would have been suitable (e.g. OCaml or Haskell).
- ac29 6y ago
  Chromium came from WebKit, which came from KHTML, which dates back to 1998.
  - lmm 6y ago
    Chromium took parts from WebKit, but e.g. the whole JavaScript engine was completely new. Even if they needed to depend on some libraries written in C++, that doesn't justify writing the whole application in that language. And once they forked WebCore as Blink they could have gradually pushed the borderline down.
    - throwaway17_17 6y ago
      I wish I had read this comment before I replied to your parent, if I had thought about a primary Haskell or OCaml implementation with FFI and then gradually shifting I might have just kept my mouth/keyboard shut.
    - josefx 6y ago
      > but e.g. the whole JavaScript engine was completely new. A quick check of Wikipedia shows that they derived it from an existing small talk implementation.
      - lmm 6y ago
        Java is closer to SmallTalk than C++ is.
        6y ago

networkimprov 6y ago

Java is mature and regarded as high performance, even if it is a memory glutton.

jolux 6y ago
Rust has significantly less overhead than Java
- lmm 6y ago
  Like a factor of 2 at best. Nice to have, but not the difference between usable and unusable.
  - scottlamb 6y ago
    Do you really think at any time in Chrome's lifespan that its developers would accept a decision that is so foundational (aka hard to reverse) and slows everything down by a factor of 2? I don't. If they had, I don't think it would be the most popular browser today, and arguably it wouldn't even still be around. IIRC, speed was a major selling point when it was released. (I also don't really think Java is that much slower but substitute a more precise guess and my statement stands. And I think Java and other GCed languages really do use ~2X as much RAM which is also unacceptable.)
    - lmm 6y ago
      The speed of Chrome's from-scratch JavaScript engine was a major selling point when released, yes. But that speed came from a lot of places - after all, competing JavaScript engines were also written in C++, and in particular areas V8 was thousands of times faster than them. Using Java over C++ would have meant a factor of 2 up-front performance cost. But it would also have meant significantly less time debugging, easier testing, faster iteration, better automated refactoring support... all of which would have added up to being able to spend more development effort finding the kind of algorithmic improvements that give you those 1000x speedups. I'm not at all convinced that the end result would have been slower.
      - scottlamb 6y ago
        In particular areas (short timespans, specific tasks), Java can be thousands of times slower than C++/Rust. (Warmup/pre-JIT function evaluation, GC pauses, etc.) I have these kinds of performance rough spots, but I'm surprised to hear you do. It doesn't seem consistent with an argument for Java.
        scottlamb 6y ago
        s/have/hate/
        lmm 6y ago
        I don't think you'll find a realistic case where Java is thousands of times slower than C++/Rust. You're even less likely to find a case where it's a worse order of asymptotic complexity. Whereas you'll find plenty of cases where (at least 2008-era) SpiderMonkey is in a worse complexity order than V8.
        jolux 6y ago
        Client warmup times are not great. Java is incredibly fast but attempts to write an HTML engine in it in the past didn’t really pan out. Also, WebKit was already written in C++.
        6y ago
  - kelnos 6y ago
    A factor of 2 is a lot. Especially when considering that web browsers are already memory hogs and aren't all that fast.
  - kllrnohj 6y ago
    Java when written like C is within a factor of 2 at best. Java when written like Java isn't anywhere close to C/C++. And the gap is getting _wider_ as Java is an increasingly bad fit for modern CPUs due to the heavy pointer chasing nature of it. It desperately needs value types to stay competitive in a performance battle.
- _ph_ 6y ago
  The previous posters were talking about languages available when chromium was started. So while Rust probably would be the language of choice today (see Firefox), it wasn't an option, but Java was already around and mature.
  - jolux 6y ago
    I don’t think Java is an option either for writing a web browser specifically for reasons of overheard. Rust is probably an option now but bringing up Java in this context was weird.
erichocean 6y ago
> regarded as high performance LOL. Is this LinkedIn? People on HN actually know Java requires mountains of C++ to be performant (c.f. Cassandra). Even then, actual C++ is 10x faster/lower latency (c.f. ScyllaDB). Update: Downvote all you want, Cassandra has tons of C++ to work around terrible Java performance, and the native C++ ScyllaDB absolutely smokes it in benchmarks. Not even close.
- nurettin 6y ago
  Judging from your lol, you must surely remember debian aliot comparison pages, or various coding competition websites ranking the times for java solutions very close to c++ solutions back in the 2000s.
  - kllrnohj 6y ago
    Those comparison pages still exist: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Time has not been kind it seems. Not just the gap in performance, but also the gap in memory usage.
    - tom_mellior 6y ago
      The C and C++ versions of those benchmarks are manually vectorized to death using vector intrinsics. You don't have those in Java, nor in the standard versions of C and C++. So yes, those speedups are real, if you invest a lot of work. But if you don't, there is no magical 5x speedup of C++ over Java.
      - unrealhoang 6y ago
        That is, if you write your program for the benchmark, i.e. writing C in Java by writing procedural code with packed primitives, or juggling and write all magic hacks just to make the code falls into correct JIT path. Otherwise, if you write normal OOP Java, 10x should be the performance gap.
entha_saava 6y ago
Hehe.. Lol no value types.. Lol virtual by default. Lol believing JIT can be efficient.

lmm 6y ago

> It's not like there are tons of practical language options for memory-safe high-performance code, and there were essentially none when many such projects started. Chromium started in 2008, at which point there were plenty of mature cross-platform high-performance memory-safe languages that would have been suitable (e.g. OCaml or Haskell).

ac29 6y ago
Chromium came from WebKit, which came from KHTML, which dates back to 1998.
- lmm 6y ago
  Chromium took parts from WebKit, but e.g. the whole JavaScript engine was completely new. Even if they needed to depend on some libraries written in C++, that doesn't justify writing the whole application in that language. And once they forked WebCore as Blink they could have gradually pushed the borderline down.
  - throwaway17_17 6y ago
    I wish I had read this comment before I replied to your parent, if I had thought about a primary Haskell or OCaml implementation with FFI and then gradually shifting I might have just kept my mouth/keyboard shut.
  - josefx 6y ago
    > but e.g. the whole JavaScript engine was completely new. A quick check of Wikipedia shows that they derived it from an existing small talk implementation.
    - lmm 6y ago
      Java is closer to SmallTalk than C++ is.
      - 6y ago