Hacker News Reader

Comment by 62951413 | Hacker News Reader

The JVM trades memory for all kinds of optimizations so it's less about raw performance and more about memory allocation tricks (and related FFI issues). This is where golang at the moment has an edge over it. Assuming you can tolerate its primitive abstractions.

Once Loom&Co get merged, the JVM is going to be unrecognizable. It's also very possible that one of those Kotlin-native/GraalVM AOT projects goes mainstream. But right now it's a problem for high-performance systems.

Personally I regret this trend because Java/Golang are much easier for people like me than C++/Rust. I cannot imagine myself going back to manually managing memory. Browsing Big Data open source code will not be as educational anymore.

View on HN

You don't do manual memory management in Rust either. AFAIK (correct me if I'm wrong), even in C++ manual memory management is discouraged in favor of RAII.

You surely do, first of all the borrow checker is only a compiler validation that you are writing the manual code correctly, and no one is magically writing Drop traits implementations for the user.

Likewise on the C++ side, someone has to write those constructor/destructor pairs, and there are ways to get RAII wrong.

Seriously, no, re: Rust.

Yes, you have to think about ownership. Because of single owner. But in general, not alloc/free. I work in Rust (after doing C++ for the 10ish years prior) full time and a couple nights ago was honestly the first time I had to really think about this (I had to do a 'forget' because I was passing a ptr to a vector back through from WebAssembly to our Rust-based runtime, and then clean it up back there instead of having Rust let it fall out of scope and free when the stack frame exited).

Think of Rust as a world where pretty much everything is inside a std::unique_ptr.

Most developers used to a GC language will have little problem working in Rust once they understand the single ownership model.

Try to write a native GUI application in Rust, or async code, and you will see how little you have to think about it.

Yes, GUI work is a pain because of the way event loops and ownership in existing UI toolkits work, they're generally not designed for this. But Arc<Mutex< is likely your friend here.

Async can be a pain, but you learn the ways. I work in a codebase with quite a bit of it.

There are appropriate and inappropriate places to apply Rust.

It surely is my friend, and I will need to manually call clone() and borrow().

> no one is magically writing Drop traits implementations for the user.

Yes, the compiler is - for almost all structs. I've been working with Rust since around 1.0 and I can count the number of times I manually had to write Drop implementations with my hands. Unless you are writing lower-level parts of the stack (which you rarely need to, since for many of those there are good crates already available) where you are responsible for resources that need a custom Drop implementation, the auto Drop implementation is good enough.

Trivial types don't count, their Drop implementation is basically do nothing.

And for Rust standard library, where the Drop actually does something, someone else wrote the implementation for you.

Reply on news.ycombinator.com