3 ms·

Exactly. That is why Rust does so many more things, but Go compiles so fast. Even with two wildly different approaches to language design, each has their place

Exactly. That is why Rust does so many more things, but Go compiles so fast. Even with two wildly different approaches to language design, each has their place, and their own set of drawbacks.

repolfx 8y ago
It's a false dichotomy. Languages like Java or Kotlin compile fast and have exceptions too.
- hactually 8y ago
  Not quite - Java is faster than Kotlin [0] but I've never seen a Golang app take more than 10 seconds (and that's something huge like Kubernetes or Docker components) [0] https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d https://medium.com/keepsafe-engineering/kotlin-vs-java-compi...
  - rhencke 8y ago
    The article you link comes to a different conclusion: > With the Gradle daemon running and incremental compilation turned on, Kotlin compiles as fast or slightly faster than Java.
- mmirate 8y ago
  Because the JVM takes another tradeoff against Go and Rust: it has a runtime interpreter+JIT, which causes even more performance overhead than Go's GC let alone Rust which - at runtime - is effectively a zero-cost abstraction over C and jemalloc.
  - repolfx 8y ago
    The JVM GCs generally have much lower overhead than Go's does. Go imposes enormous collection costs on apps to try and drive latency so low. This is widely acknowledged in discussions of the various GC tradeoffs.
    - mmirate 8y ago
      The GCs alone? Yes. The rest of their respective runtime architectures? Highly doubtful. As GC-dependent as Go may be, it still does end up as native code. But frankly, comparing Go to Java when things like Rust exist ... seems analogous to comparing the z80 to the AVR when 32-bit ARM cores exist.
      - repolfx 8y ago
        Offtopic/meta: for some reason your post was dead. The comment at the end is kind of pointless and flamey, Rust isn't that good, but doesn't seem to justify a post kill. I vouched for you to bring it back.

Exactly. That is why Rust does so many more things, but Go compiles so fast. Even with two wildly different approaches to language design, each has their place, and their own set of drawbacks.

repolfx 8y ago

It's a false dichotomy. Languages like Java or Kotlin compile fast and have exceptions too.

hactually 8y ago
Not quite - Java is faster than Kotlin [0] but I've never seen a Golang app take more than 10 seconds (and that's something huge like Kubernetes or Docker components) [0] https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d https://medium.com/keepsafe-engineering/kotlin-vs-java-compi...
- rhencke 8y ago
  The article you link comes to a different conclusion: > With the Gradle daemon running and incremental compilation turned on, Kotlin compiles as fast or slightly faster than Java.
mmirate 8y ago
Because the JVM takes another tradeoff against Go and Rust: it has a runtime interpreter+JIT, which causes even more performance overhead than Go's GC let alone Rust which - at runtime - is effectively a zero-cost abstraction over C and jemalloc.
- repolfx 8y ago
  The JVM GCs generally have much lower overhead than Go's does. Go imposes enormous collection costs on apps to try and drive latency so low. This is widely acknowledged in discussions of the various GC tradeoffs.
  - mmirate 8y ago
    The GCs alone? Yes. The rest of their respective runtime architectures? Highly doubtful. As GC-dependent as Go may be, it still does end up as native code. But frankly, comparing Go to Java when things like Rust exist ... seems analogous to comparing the z80 to the AVR when 32-bit ARM cores exist.
    - repolfx 8y ago
      Offtopic/meta: for some reason your post was dead. The comment at the end is kind of pointless and flamey, Rust isn't that good, but doesn't seem to justify a post kill. I vouched for you to bring it back.