[ysleepy]

I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box. If you use swift, everything is ref counted, why subject yourself to so much pain for marginal gain.

Tutorials and books should be more open about that, instead of pushing complex lifetime hacks etc., also show the safe and easy ways.

The article gives Java a worse devx rank than Go and I can't agree. Java is at least on par with go in every aspect of devx, and better in IDE support, expressiveness, and dependency mgmt.

[VorpalWay]

> I agree that the rust community frowns a little too much on the use of Arc/Cloning/Box

As usual, this depends heavily on what you do. I had written a program where Arc reference counting was 25 % of the runtime. All from a single instance as well. I refactored to use borrows and annotated relevant structs with lifetimes. This also enabled additional optimisation where I could also avoid some copies, and in total I saved around 36% of the total runtime compared to before.

The reason Arc was so expensive here is likely that the reference count was contended, so the cacheline was bouncing back and forth between the cores that ran the threads in the threadpool working on the task.

In conclusion, neither extreme is correct. Often Arc is fine, sometimes it really isn't. And the only way to know is to profile. Always profile, humans are terrible at predicting performance.

(And to quite a few people, coming up with ways to avoid Arc/clone/Box, etc can be fun, so there is that too. If you don't enjoy that, then don't participate in that hobby.)

[indigo945]

For the use cases outlined in the OP, a 36% performance gain for an optimization that complex would be considered a waste of time. OP was explicitly not talking about code that cares about the performance of its hot path that much. Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.

[satvikpendem]

Adding a few borrows and annotations is not "an optimization that complex"; use Arc at first but then find those bottlenecks via profiling then fix them.

[3uler]

Fix them if needed, the OP’s point is that for a lot of applications it is not needed.

For most cases you will still be comfortably in the JVM/golang performance window.

Rust is great language, fighting the borrow checker sucks, don’t do it if you don’t need to.

[VorpalWay]

> Most applications spend 90% of their runtime waiting for IO anyway, so optimizations of this scale don't do anything.

Again, depends on what you are doing. If you are doing web servers, electron apps or microcontrollers, sure. If you are doing batch computation, games, simulation, anything number crunchy, etc: no. As soon as you are CPU or memory bandwidth bound, optimisation does matter. And if you care about battery usage you also want to go to sleep as soon as possible (so any phone apps for example).

[bryanlarsen]

There is a significant chunk of the rust community that encourages the use of Arc, clone and Box outside of the hot path. Perhaps you're just hooked up with the wrong part of the community?

You're likely to get more pushback when creating public crates: you don't know if it's going to be someone else's hot path.

But the internal code for pretty much any major rust shop contains a lot more Arc, Box and clone than external code.

[fyrn_]

Pretty sure by devx they mean something like syntax ergonomics. Because otherwise rust's devx first class (cargo, clippy, crates.io) so kind of a nonstandard definition.

I think it's fair to say Java's "syntax ergonomics" are a little below the rest / somewhat manual like rust or C++ by default.

[ysleepy]

Yeah, but worse than Go?

[drzaiusx11]

go's type system is significantly more limited in what it can do for you, as opposed to rust or ts. Limited syntax seems to be one of the overarching design decisions for that language, making it more like C with better concurrency primitives. It can feel a bit limiting at times, but at least they have generics now and you can almost do things like union types by constructing interfaces that mimic them, but it isn't exactly ergonomic.

[hactually]

The go tooling and ecosystem and how it "just works" runs rings around the Java clowncar.

[jim33442]

I could see myself picking Java over Go just cause of the error handling

[dev_l1x_be]

I am not sure the community frowns on these. In fact I use those in almost every Rust code I write. The point is that i can grep for those because Rust does not do it in a hidden way.

[netbioserror]

If you use Nim, it's value semantics by default. Everything (and I do mean everything, all types primitive to composite) is managed by the stack, including stuff that needs to hold a heap pointer. All lifetimes are scoped. You only get ref counted types when you opt in.

It's astoundingly easy to build software with that behavior set. Even if the occasional copy is necessary, you're paying a far lower cost for it than for an interpreted language. Slice off a couple important components into stateless executables built like this, and it's clean sailing.