Hacker News Reader

Comment by modalduality | Hacker News Reader

Not a Rust expert, but some thoughts on the negatives.

> Compilation time is too large

Can you try compiling incrementally? https://blog.rust-lang.org/2016/09/08/incremental.html. Might still only be on nightly.

> And, on the similar note, benchmarks.

I agree, profiling as well isn't as full featured as in more mature languages. Clojure, incidentally has great benchmarking due to being on the JVM.

> Also the tuple assignments.

Can't you just do

    fn main() {
        let (a, b) = (5, 2);
        println!("{}, {}", b, a);
    }

>There are many cases where compiler could do the stuff automatically.

I think this will be solved with the new non-lexical lifetimes RFC. Also a problem I had when starting, I generally assume referential transparency.

View on HN

> Clojure, incidentally has great benchmarking due to being on the JVM.

Eh? Benchmarking on the JVM is notoriously difficult bordering on impossible. There's things like Google Caliper but test runs take forever due to attempting to force JIT warmup and doing GCs after every run. And the project's own wiki tells you the results are basically meaningless for a variety of reasons.

Benchmarking things like C++ or Rust are trivial by comparison since when you call method foo() it's gonna do pretty much the same instructions every time. Highly consistent, highly repeatable, highly benchmarkable. Call method foo() in a JVM language and there's not a single person on the planet that can reliably tell you what's going to get executed on the metal.

That's why you typically profile JVM languages rather than benchmarking them.

Benchmarking is pretty meaningfree in the best cases. The JVM isn't any worse in this regard.

The JVM is slow in many regimes due to things like JIT warmup. Rather than accepting that many JVM people are hypersensitive: thou must only benchmark in the JVM's best case scenario.

> Benchmarking is pretty meaningfree in the best cases.

That's completely false. Benchmarking is a core staple of building & evaluating performance-sensitive libraries or other routines. It doesn't work (well) in non-deterministic languages which reduces its usefulness scope, but in things like C++ it's highly useful and reliable for evaluation of libraries and monitoring for regressions.

> The JVM is slow in many regimes due to things like JIT warmup. Rather than accepting that many JVM people are hypersensitive: thou must only benchmark in the JVM's best case scenario.

Well it's not just the JIT that's a problem. It's also things like GC passes. Does that get included in the results or not? Do you force GC passes between runs? How about finalizers? The answers to those questions depends on the state of the rest of the system and the expected workload, it's not something you can just trivially answer or even accommodate in a framework since most of the behavior is up to the particular implementation, which can then further vary based off of command line flags.

My bad, I meant profiling, not benchmarking.

> Can't you just do

That's a declaration not an assignment, TFA is (somewhat oddly) using the language precisely and fittingly: https://doc.rust-lang.org/reference/expressions.html#assignm...

And there are cases where shadowing is not acceptable e.g. when updating bindings within a loop, you usually want to see the updates from outside the loop.

I've found that using Linux tools like perf work well for profiling Rust, since it's compatible with C.

Yup! perf and kcachegrind actually work nearly as well for Rust as they do for C/C++. It's all just another LLVM compiler that emits debug info, as far as Linux tools are concerned.

Reply on news.ycombinator.com