Hacker News Reader

Comment by tormeh | Hacker News Reader

I once said that Rust would never become really, Java-level, popular. Mostly because I thought it focused too much on performance to the detriment of elegance and productivity. I'm not so sure anymore. This is a step in the right direction. That said, what makes me most nervous about Rust is pointers and mutability being mandatory for certain things, rather than the absence of books. Maybe that's just me, though. Anyway, in my opinion, pointers and mutability should be something I think about once I'm optimizing the program, not something I do while figuring out the logic. As long as copying everything every time fits in my compute budget I don't get why I should be forced by the stdlib to do otherwise.

Anyway, huge fan of what the Rust devs are doing. It's truly awesome.

View on HN

> I once said that Rust would never become really, Java-level, popular.

I like Rust, but IMO no language will ever again be Java-level popular (not even Java!) in the same way that e.g. there will never again be a band as big as the Beatles. Technological contexts have changed such that niche languages can now successfully thrive and counteract the lower switching cost that comes with a monoculture; while certain languages "in the middle" will still dominate, the long tail will get longer and subsequently lower any dominant language's market cap.

c#?

References (lifetimes and borrow checking) and mutability are there for safety, not speed.

Copying everything every time is a trivial (and very slow) solution to the memory safety problem. It just means that everything is on the stack (or at least that only one stack frame has a reference to any given object), so it is simply deallocated along with the stack frame. That's it. There's nothing unsafe about it.

What do you mean by saying mutability is for safety? That's a very unusual opinion.

Explicitly tracking shared mutability is for safety - obviously not mutability in of itself.

Copying everything every time isn't a solution in a multithreaded world if you actually want your threads to share data.

"sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking, and in many cases it can lead to abysmal performance. It is often much better for performance to design parallel algorithms around shared-nothing i.e. local mutability + explicit message passing right from the start.

> "sharing data" is quite illusory. Even if two threads have a reference to the same object, the CPU deals with it internally by making several copies, asynchronous message passing and locking,

No. Two threads on the same CPU core really access the same data(1) without the delay and no locking happens unless the programmer wrote some locking code.

Synchronizing the different cores or processors is another topic, but it's also typically dependent on the software.

----

1) But there is also reordering https://en.wikipedia.org/wiki/Memory_barrier and out-of-order execution https://en.wikipedia.org/wiki/Out-of-order_execution

Most of the time the implemented techniques do significantly speed up the execution. And it's mostly software design that initiates the slowdowns, not the CPU.

Even on a single core, there are several copies in different cache layers and synchronizing them is done by sending asynchronous messages. Sure, in that one particular edge case when the threads are sharing a core you're right, but this is not a typical scenario for multi-threaded applications. Most of the time for high multi-threaded performance you want exactly opposite - one thread per core and pinning threads to cores. And if you don't do anything, you can never be sure if your threads run on the same core or not and you should assume the worst.

> And it's mostly software design that initiates the slowdowns, not the CPU.

This is quite vague statement and I'm not sure what you really meant here. Software written using a simplified abstraction model (e.g. flat memory with stuff shared between threads, ordered sequential execution) much different than the way how CPU really works (hierarchical memory, out-of-order execution, implicit parallelism etc.) is very likely to cause "magic" slowdowns. See e.g. false-sharing.

Also algorithms designed around the concept of shared mutability do not scale. Sure, you may hide some of the problems with reordering, out-of-order, etc. To some degree it will help, but not when you go to scale of several thousands cores in a geographically distributed system.

> See e.g. false-sharing.

It's also an effect of a badly written software, not something that is constantly present in the CPU execution. You based the claim to which I've replied on "sharing is illusory", "if two threads" and "the CPU deals with it" like it's necessary to happen all the time in the CPU as soon as the threads exist and they access the same data.

> when you go to scale of several thousands cores in a geographically distributed system.

There you are not describing "a CPU" (as in, the thing that's in the CPU slot of the motherboard) which is all I discussed, and I'm not interested in changing the topic.

Aren't they closely related? Single-ownership semantics benefit concurrency and optimization by eliminating the need for locks and synchronization except in those (rarer) cases where data explicitly needs to be shared between threads, in which case Rust forces you to go through mutexes. In other languages that don't offer this safety, you're likely to lock a lot more stuff as a purely defensive measure, because the only thing preventing unsafe access is the programmer.

Since the borrow checker happens at compile time, the whole mechanism is "zero cost". This results in more efficient code, because you can do things like safely hand out references (pointers) to privately held pieces of data without needing a heap allocation to track the pointer (e.g. shared_ptr in C++); the final code needs no lifetime checks, because the compiler did all the analysis for you.

I imagine the combination of ownership and immutability also lets the compiler reorder, eliminate and simplify generated code better than most other languages (Haskell being a possible exception here). Not sure if Haskell-style automatic parallelization is planned.

Doesn't having less reliance on indirection help speed?

For my curiosity, what do you find in Java that you think is more elegant than rust?

Reply on news.ycombinator.com