8 ms·

Interesting perspective. I toyed with rust a bit from the perspective of a c# background (and a bit of java, php, classic asp, JavaScript, typescript, etc) . I

Interesting perspective. I toyed with rust a bit from the perspective of a c# background (and a bit of java, php, classic asp, JavaScript, typescript, etc) . I like rust, but I've come to still prefer c#'s object oriented features. Perhaps it's my naivety, but I've found c# AOT compilation to do plenty of trimming and startup performance optimization that I don't see it as a bad option. Have you made a personal comparison on Rust vs Object Oriented Languages like c#?

apatheticonion 6d ago
From a software design standpoint, it certainly takes some adjustment going from OOP to the compositional architecture and structural trait system used by Rust, but it's not that big a shift. The biggest downsides are the poor standard library that ships with Rust and the non prescriptive project structure which puts too much authority on the writer to figure out. The biggest wins are that runtime exceptions and concurrency bugs are impossible. So you can basically write Rust with your eyes closed and, if it compiles, it's probably right. Due to the high level of trust the compiler gives you, PR reviews (and reviewing AI generated code) is limited to design decisions and logic implementations. I only really think about architectural decisions, like "this code belongs to X domain, so I should put it in X crate" or "my project should use a hexagonal architecture, does this change violate that? Should I create a package/crate to contain this logic?" If you don't care about optimisations, a naive implementation in Rust will effortlessly outperform C# and use orders of magnitude less resources, but optionally, the pay off for optimisation is high.
- za3faran 6d ago
  We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
  - apatheticonion 5d ago
    Performance isn't really the selling point for me. It's the fact that runtime errors are essentially impossible, making writing, reviewing, testing code very easy. It also means LLMs can spin it out with the compiler, and if it compiles, it probably works. You just need to organize the code.
  - throwaway273748 5d ago
    It is mathematically impossible for a Java program to be faster than a well optimized Rust program, so long as the JVM exists and requires non-zero resources to run (to say nothing of GC etc). This isn't me glazing Rust, this is just the boring observation that a VM language is necessarily going to be outperformed by a language without a VM. VMs have good attributes, but they are never zero cost.
    - za3faran 5d ago
      Key is "well optimized". At some point and scale, it becomes almost impossible to chase those manual optimizations, not to mention that usage patterns at runtime can change in such a way that make such an optimization prohibitively expensive, if not outright impossible. And even then, you would end up matching what the JVM JIT offers anyway. What I mentioned is already something that people have observed for both Rust and C++ against programs written in Java. Now add features like observability, profiling, debugging, and dev productivity, and it becomes a worthwile tradeoff a lot of the time. For constrained environments, GraalVM offers native image.
      - deleted 5d ago
        [deleted]

apatheticonion 6d ago

From a software design standpoint, it certainly takes some adjustment going from OOP to the compositional architecture and structural trait system used by Rust, but it's not that big a shift. The biggest downsides are the poor standard library that ships with Rust and the non prescriptive project structure which puts too much authority on the writer to figure out. The biggest wins are that runtime exceptions and concurrency bugs are impossible. So you can basically write Rust with your eyes closed and, if it compiles, it's probably right. Due to the high level of trust the compiler gives you, PR reviews (and reviewing AI generated code) is limited to design decisions and logic implementations. I only really think about architectural decisions, like "this code belongs to X domain, so I should put it in X crate" or "my project should use a hexagonal architecture, does this change violate that? Should I create a package/crate to contain this logic?" If you don't care about optimisations, a naive implementation in Rust will effortlessly outperform C# and use orders of magnitude less resources, but optionally, the pay off for optimisation is high.

za3faran 6d ago
We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
- apatheticonion 5d ago
  Performance isn't really the selling point for me. It's the fact that runtime errors are essentially impossible, making writing, reviewing, testing code very easy. It also means LLMs can spin it out with the compiler, and if it compiles, it probably works. You just need to organize the code.
- throwaway273748 5d ago
  It is mathematically impossible for a Java program to be faster than a well optimized Rust program, so long as the JVM exists and requires non-zero resources to run (to say nothing of GC etc). This isn't me glazing Rust, this is just the boring observation that a VM language is necessarily going to be outperformed by a language without a VM. VMs have good attributes, but they are never zero cost.
  - za3faran 5d ago
    Key is "well optimized". At some point and scale, it becomes almost impossible to chase those manual optimizations, not to mention that usage patterns at runtime can change in such a way that make such an optimization prohibitively expensive, if not outright impossible. And even then, you would end up matching what the JVM JIT offers anyway. What I mentioned is already something that people have observed for both Rust and C++ against programs written in Java. Now add features like observability, profiling, debugging, and dev productivity, and it becomes a worthwile tradeoff a lot of the time. For constrained environments, GraalVM offers native image.
    - deleted 5d ago
      [deleted]