Hacker News Reader

> Honestly, I feel safer writing in Rust than I do Java. Even Java has its footguns, especially with mutable state being shared across threads.

Apart from big differences between Java and Rust like memory management (not just GC vs. lifetimes but also stack allocation), approach to threading, and Cargo vs. Maven, Rust is so much nicer in the seemingly little things like:

* UTF-8 everywhere instead of UTF-16 everywhere.

* Unsigned integers.

* Bytes from I/O being unsigned by convention.

* Ability to bake plain old data into the data segment of the executable with genuinely no run-time initialization.

If you're in a stateless server environment, GC almost never needs tuning. Stateless servers are close to ideal for a generational GC. Cacheing can muck things up, but if you implement that at a higher level, you're in a good place.

That's fair, so long as all of your requests have similar allocation profiles. I work on a service which has requests of variable complexity ranging from basically free (10s of KBs) to 10s-100s of MB of allocation. G1GC with a low pause target eliminated a lot of the tuning necessary I'll admit. This could also be a "grass is greener" mentality, but I do believe that in return for the upfront development effort of managing memory as you go vs. deferring to GC leads to more predictable results. Of course, if your algorithms suck, nothing will save you. :P

And when you start managing memory you will discover that GC are more powerful than you thought because your simple memory allocator cannot beat 20+years of engineering in the JVM.

No, nothing can beat manual memory management in performance. GCs don't have a clue where and when they should make what trade offs, but programmers do.

GC can surpass the performance of manual memory management in certain situations, assuming that the manually managed code is forced to allocate for some reason. GCs almost universally use far more memory than manual schemes, though (I'm having a hard time imagining a counterexample).

That depends on the allocator you are using. Rust bundles jemalloc by default, which organizes deallocations/allocations such that they are very efficient.

You mean a select few programmers do. And even if you've struck gold and all of your programmers are from the 90's so that they know what it means to manage memory manually, the landscape - the code - always changes and so will the trade off. The deal is that you want to deliver software quickly and make sure it performs adequately, but no one needs perfectly, in regular business.

It really depends on what sort of business you're in.

If you're doing application development then UI performance is usually good enough using modern runtime environments and libraries. When this is true being able to release features quickly is the most important metric.

But if you're working on a 3d game engine, writing a web browser, writing code on an embedded platform or writing a database then performance itself is a feature. Being lazy with allocation or your choice of algorithms is a really expensive mistake that will hurt your bottom line.

If I know my allocation patterns I can guarantee my arena/fixed block allocator will beat the JVM, every time.

Nothing is absolute, there are always tradeoffs. If everything was a one-size-fits-all solution then Software Engineering wouldn't exist as a career.

GC enthusiasts say this, but I have never seen it actually be true.

The reason is that whoever wrote the GC for your language has to solve an extremely general problem for an extremely large body of users with very different use-cases.

A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do.

General-purpose GCs are like the F-35 or Space Shuttle ... due to the broad nature of demands they are very complicated, and are much more expensive and perform more poorly compared to specific solutions.

>>> A memory management system for a particular program only has to solve the problems of that program, which is a tremendously simpler thing to do.

I don't like to sound rhetorical, but writing a memory management system for anything non trivial (that is, a scenario where you allocate and deallocate memory) quickly becomes a difficult problem.

Besides, could you give us an example ? I'd like to know about it. My example is a video game where we were allocating thousands and thousands of small stuff and deallocating it. Soon you end up with a fragmented memory where you can't allocate big chunk of memory...

That's almost the canonical example. Say for a particle system you use a fixed-block allocator that's the size of your particles. Now your allocations are quick since you don't have to do fitting and you don't fragment memory since they're all clumped together.

Other common trick in video games is to have a single-frame arena allocator for objects that are transient frame to frame. You just move a pointer forward and reset the pointer at the end of the frame.

That's an odd example, given most video games are written in memory managed languages for performance reasons. Typically an allocation pool would be used for that case because there's some bound to the number of simultaneously allocated objects and each object has a homogeneous memory footprint.

It's also odd because you're replying to a well-known game designer.

That said, there are allocation-heavy workloads for which GC is well suited.

>>> It's also odd because you're replying to a well-known game designer.

Authority position ! :-) I worked on optimizing the Outcast game 3D engine (ok that was around 20 years ago). And I clearly remember other devs in the team struggling with memory allocation.

In the end, they sorted it out without resorting to a full fledged GC. But since our case was simple (loading resources for building a world, then releasing resources that are not useful anymore), I concluded that it's not easy.

In the end, it all depends on the nature of the problem, and one can optimize for any of them (as it is customary in video games). I know that.

> I don't like to sound rhetorical, but writing a memory management system for anything non trivial

Writing a generic memory management system is non-trivial.

Designing and implementing a memory management strategy with an understanding of the application semantics--especially when you can modify the semantics, or enlarge or narrow the relevant context, as appropriate--is much easier. Trivial in many cases.

Writing a GC for the JVM is difficult because the 1) JVM has far fewer degrees of freedom, and 2) they have to solve a much more difficult problem. All those awesome-sounding automatic optimizations JIT compilers can implement pale in comparison to the overall difficulty of the underlying problem.

By way of analogy, look at formal software verification. The underlying computational complexity of the algorithms are extremely costly. The only way to make it work is by using a human to refactor the big problems into many smaller problems, including smaller problems that encapsulate other smaller problems. Only humans can do that, and it will be that way for quite some time.

Manual memory management is the same way--a human can do better than a generic collector because only the human can refactor the program. Only a human can say, "this part is too complex, with too many lifetime and ownership interdependencies, so I'm going to refactor it so it's easier to use a more elegant memory management strategy". Generic collectors like those in the JVM can't do that--they have to work with the software they're given.

If you're having trouble with memory management, perhaps it's because you haven't yet figured out that you don't need to play by the same rules as an automatic garbage collector. And you certainly don't need to be, nor should you be, restricting yourself to a malloc/free-like interface.

Rust's allocation strategy beats the JVM hands down in every benchmark. 20+ years of engineering cannot cover the flaws of VM and GC languages. Writing efficient stack-allocated software will always trump GC/VM solutions.

Unless you're Go, then you optimize for latency at the cost of CPU, but that seems like a very acceptable tradeoff to make given how Go is most commonly used.

Here's how I see the use of GC in Go: It allows the programmer to more easily get to the point where there's a correct, running version of the system. Once you're at that point, you then optimize as much as you need to reduce GC pressure. Emphasizing latency at the cost of throughput is exactly the right tradeoff for this purpose. First you get it running, then you get it correct, then you make it fast.

Large pauses are more likely to be a barrier to program development than being a bit too slow.

Not everyone have to tune GC. I never had to do that. I work with government project which serves the whole country now (small cluster with jboss servers), nobody tuned GC there, because there was no need (except -Xmx setting, of course).

I wrote few simple programs with Rust, but its memory management model is much harder to use, than GC (no thinking about memory at all, just don't leak) or ARC (just think about cycles). While I understand why it's necessary to achieve higher performance, it's harder to use for developer.

It might have uses for multithreading, but, honestly, I never had any problems with it. It's usually better to write single-thread code and avoid multithreading except in few carefully written places. So it solves a problem I never had.

That's my perspective, I mostly did enterprise web development and iOS development. Probably from systems programming things look different.

Rusts guarantees aren't just about multithreading: http://manishearth.github.io/blog/2015/05/17/the-problem-wit...

I can see where my statement was ambiguous, I'd intended to say that the GC developers spend tons of time tuning their implementations to fit their users' workloads.

I will say that "government project which serves the whole country now" doesn't really specify how many requests you're doing or what kind of pauses are acceptable. If it's a traditional website, a 300ms GC pause might be invisible. A 2s pause might even be invisible.

For a service doing 30,000 requests/s (~1-2k/s per machine), a single STW pause of 2s is _very_ disruptive. Even 300ms is high. A 300ms pause is 600 queued requests @ 2k/s. We certainly tune this service to eliminate most STW GC. We were even hit by http://www.evanjones.ca/jvm-mmap-pause.html .

> It's usually better to write single-thread code and avoid multithreading except in few carefully written places.

implies that you did have some problem with multithreaded code, which is why you ultimately chose to avoid it.

Stuff like rayon in Rust lets you sprinkle multithreading over your codebase very easily without needing to worry at all, because Rust keeps it safe.

> but its memory management model is much harder to use

IME it takes some getting used to but once you do it's pretty automatic and you don't have to think about it much. YMMV.

If you're into safety than you should probably go with a functional programming language with low-cost abstractions. Rust isn't an expressive language, its only benefit compared to other general purpose languages is its memory management.

Rust is very expressive. The main benefits of functional programming languages is contained with Rust's Iterator trait and the ad-hoc polymorphism that traits allow.

I don't know that traits in Rust are an example of ad-hoc polymorphism, since they're fully type-safe.

I don't think that means it isn't ad hoc. Type classes in Haskell were originally introduced as a form of ad hoc polymorphism, for example: http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/a... (One of Wadler's great papers btw, worth a read.)

Of course, Haskell type classes and Rust traits aren't the same. But they are quite similar!

As I understand the term, "ad-hoc polymorphism" refers to dispatch based on types (as opposed to "parametric polymorphism", where one code path works for any type). Nothing to do with type-safety.

Here's an example: `Stdin` and `File` both implement the `Read` trait. Therefore, you can write a function that takes the traits that you want to use as input parameters.

fn do_something_with<S: Read>(source: S) {

    // do something with input source

}

Then you can do the following:

let stdout = io::stdout();

do_something_with(stdout.lock());

let file = File::open(path).unwrap();

do_something_with(file);

You're free to narrow down/expand the types/methods that can be used with the function if you add more traits.

"ad-hoc polymorphism" is an informal term; traits are sort of both ad hoc and parametric.

I've sometimes imagined someone writing a paper about specialization and naming it "How to make parametric polymorphism less parametric" after Wadler's paper.

I haven't developed this thesis fully, but I've been thinking that Rust's model is a better version of functional programming, and we lack a good term for it (since it's obviously not a pure functional language). The point of functional programming is to avoid shared mutable state by eliminating all side effects and using a rich type system that's hopefully easy for the programmer to use. Rust avoids unsafe shared mutable state, without requiring the avoidance of all side effects, and by using an even richer static-analysis system that tracks exactly what side effects are safe.

Of course, there are a lot of useful things a pure functional programming language gets you, like Haskell's implicit IO scheduling and threading, that Rust doesn't. But for many use cases where functional programming languages are great, they're great for specific reasons that Rust is also great at.

I've had similar thoughts. Rust does a really good job of asking, are you really sure you want that shared mutable state? It's possible to break out but I've found the friction involved has guided me towards better solutions.

It's worth noting that Haskell has "shared xor mutable" via the ST Monad. It effectively providing mutable memory cells that aren't allowed to "escape" a scope in much the same way as `&mut`.

Also having actual purity knowledge (something Rust punted on before 1.0) can sometimes be useful. Although honestly 99% of the time it's only for the benefit of the compiler, which isn't a big deal if you have the tools to write code that's efficient from the get-go.

e.g. list fusion is enabled by purity, but is largely uninteresting in Rust because lazy iterator chaining already orders operations and avoids intermediate lists just like list fusion.

A common point I've seen is that "Functional programming sees the aliasing vs mutability issue and declares that the solution is to avoid mutability altogether. Rust goes in a different direction, saying that only aliasing XOR mutability is allowed".

It's solving the same problems, and the solution ends up having many similarities with functional programming.

When people keep writing "aliasing XOR mutability", don't they actually mean "aliasing NAND mutability"? And if yes, is there a reason to use XOR here? And if no, isn't it the case that if it's worth communicating, it's worth communicating clearly?

Can you elaborate more what makes you think Rust isn't an expressive language ? And what feature your «functional programming language with low-cost abstractions» has that your miss with Rust ?

In my experience Rust is really close to OCaml in term of expressiveness. I don't know what feature Scala or F# have that Rust doesn't.

The only major thing I can think about is Higher Kinded Type in Haskell. They are indeed cool and there is work underway to add HKT to Rust (but nobody is sure yet if it's possible though).

I don't know a great deal about scala or f#, but I know scala has higher kinded types as well as implicit function arguments which are things that rust does not have. OCaml had parameterizable modules and functors, tail call optimization, and presumably other important features.

I'm much more familiar with Haskell, which definitely has a lot of things that rust does not, not just higher kinded types but sophisticated type level programming, type families, functional dependencies, existential types, etc etc etc. Additionally it has lazy evaluation, a very sophisticated green threading system, software transactional memory, etc. Not to mention of course the purity. Haskell has a bunch that rust does not -- of course the reverse is true as well, but it's worth mentioning.

At the end of the day, though, rust is meant to address use cases that no mainstream functional language does, and it is very successful at it, while also having a ton of really cool features which makes it very exciting for FP enthusiasts.

Thanks !