You're Allowed to Write Slow Rust Code | Hacker News Reader

You're Allowed to Write Slow Rust Code

blog.jonstodle.com

33 pointsingve56 comments

You are also allowed to write in a GC language.

The problem with GC languages is that if the requirements (or data sizes) change and you run into performance problems related to GC later (e.g unacceptable pause times or high heap usage) then it is extremely hard to get out. Often the only choice is a complete rewrite of time-critical parts. There is a whole world of difference between a Rust program that does clone() occasionally to escape borrow checker strictness and a Java program that allocates 99% of stuff like crazy on GCed heap.

True, but I expect that only ~2% of programs to ever run into this problem

Then how come everything is so ridiculously slow these days, despite faster computers?

I've ran into situations when displaying text on the screen was lagging - and that in several different programs, on various (modern) computers. Not saying GC was a problem there, but I guess this has something to do with the generally accepted culture of "only 2% of programs need high performance".

> Then how come everything is so ridiculously slow these days, despite faster computers?

There is difference between GC overhead, VM overhead, interpreter overhead, and programmer not understanding basic concepts and doing stupid shit.

Go is GC language and tools written in Go often approach C/C++ speeds, despite lacking an optimizer like LLVM and lack of some performance oriented features. Another example is OCaml.

> Then how come everything is so ridiculously slow these days, despite faster computers?

As you said, it's usually not a GC issue. Many of these ridiculously slow programs you talk about are written in C++.

VSCode, Slack, Intellij Idea, some random JS on a website - indeed all C++ programs. I'm not arguing against GC, but more about the philosophy of saying that only 2% programs need a good level of performance. It starts from using GC instead of thinking about object ownerships (which btw often also results in harder to read, more convoluted code) and ends up launching an embedded web-browser to display a few images and a bunch of text and taking 1 GB of RAM. But it is not developer's RAM, so who cares?

Summarising - using a GCed language instead of dropping a few occasional clone calls in the code is bad advice, unless the program is really a one-off fire and forget thing (but these are not 98% of software).

The soft I have the most performance issues are Firefox, LibreOffice and Aperçu (don't know its original name, but it's called that way in French -- Apple's PDF viewer). All of them written in different, non-GCed languages. Usuall the problem is abuse of abstraction layers, more than abuse of a GC. And your javascript examples are a good example of that. GCed languages tend to abuse dynamic allocation and dynamic dispatch, even when it's not needed (there is more garbage to deal with).

However I agree the idea only a few software need to run fast is bullcrap.

There was recent talk about the small kernel written in Go (I can't find the thread, though), which showed Go can have a performance profile good for systems programming.

The considerations can be very complex though, e.g. what's the effort required for reaching this performance profile? is it consistent across all the types of project? etc.etc.

When Java came out, and later when C#/.NET arrived some people did the same with them. Nihil novi.

It is often easier to get decent performance in tiny projects or micro-benchmarks, simply because you can spend so much more time on optimization vs all other tasks. That's probably why I often see Java benchmarks claiming close-to-C performance (only ~2x slower) levels, but I fail to see it in real big applications.

Yet I have replaced plenty of C++ systems with Java/.NET based ones, or hybrid solutions where C++ is left for a couple of high performance libraries (e.g. in COM), with the rest in some managed language.

If the hard deadlines are still met, it doesn't matter that another solution is 50% faster when it takes 150% more money to develop and doesn't bring anything to the table (hard deadlines were accomplished).

This is what people keep forgetting when arguing my language is faster than yours.

What I care is about project costs, meeting deadlines and acceptance criteria.

> What I care is about project costs, meeting deadlines and acceptance criteria.

Are you sure you're on the right website? :D

50% faster and 150% more expensive are numbers my experience doesn't agree with.

First, programs coded in Rust are typically nowhere near 50% faster than the ones coded in managed languages - I observe 500% to 5000% differences. And it is not just faster but also uses an order of magnitude less memory. In cloud based software this translates to savings on TCO users of the software I write do care about.

Second, as for 150% more development cost - this is also not my experience. There is some upfront cost related to learning a new language, but then later this pays off on maintenance and bug finding (lack of data races or relying on fragile runtime reflection are big ones). Plus Rust is more expressive than Java/C#/Go and many common programming problems are actually surprisingly faster to code. E.g serialization / deserialization of object graphs.

> and a Java program that allocates 99% of stuff like crazy on GCed heap

Java is too extreme with GC, not all languages are like that. In .NET it's only moderately hard to avoid GC when you want to. It has value types, real stack, and other relevant features. Here's an example of non-trivial code written in that style for performance reasons: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo

1 - Not all GC languages are Java

2 - Those languages offer C++ like features for memory management if one bothers to actually learn to use them

3 - Java is also getting them via projects Panama and Valhalla

So it is more a matter to actually bother to learn the tools one has at their disposition.

1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCed languages, in particular when we also take memory use and pauses into account, not just throughput. Throughput, low latency, low memory use - there are inherent tradeoffs between them and usually you can pick only one to tune for.

2 - Not really. The fact they allow to allocate/deallocate manually is not enough. Dealing with non-GCed memory in Java or C# is much more error-prone and less ergonomic than even in C++. E.g. no automatic reference counting nor RAII.

3 - It is 5 years in development now and as far as the specs goes value types will be limited to immutable objects only, so it is inefficient by design and it solves only half of the problem. Similarly high hopes were associated with escape analysis which turned out to be totally ineffective.

1 - Java is not the only game in town.

2 - automatic reference counting is slower than tracing GC. Strange to prefer something with less performance. RAII is possible in C# via IDispose (alongside Roslyn compiler errors for not using it properly) and FP patterns similar to -with in Common Lisp.

3 - It is a major engineering feat to design a feature that will work out of the box with 25 years old compiled jars without playing a Python 2 in the Java world. Naturally it takes its time to get right. Just like it took 10 years to get modules and concepts and they are still not available across all major C++ compilers. Good engineering takes time.

1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects.

2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient.

3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.

1 - Just like manual memory management isn't good in all aspects and before the FOSS wave there were companies whose only business was selling specialized versions of malloc()/free().

2 - Really? Here is one to start with, https://github.com/ixy-languages/ixy-languages. Enjoy the RC high performance from Swift. Additional SIGPLAN and ACM papers can be provided. The fact is that when RC gets fine tuned for performance, it is a tracing GC in disguise, with its background threads for deferred releases, like C++/WinRT is currently doing with COM/UWP.

3 - It takes some time to catch up with 25 years of libraries, OS and IDE support

2 - and your link only shows that Go, Java and C# have substantially lower performance than C and Rust on this task. So that doesn't refute my point. As I said, the whole trick relies on the fact that these languages don't need so much GC in the first place. Reference counting in Rust or C is something you do as the last resort. It doesnt matter it is slower per-single-object, when you have 1000x fewer objects.

3 - Mature doesn't mean all of it is always better. Take Cargo vs Maven/Gradle. Or libraries for async programming. Also not everything needs to be written from scratch.

Micro-benchmarks are meaningless if the project hard deadlines have been met and customer is happy with the result.

The point of my link was about Swift RC performance, Rust and C aren't using it.

> You can become productive in Rust in less time than they will be able to ship Valhalla.

Yeah, but they'll ship Valhalla before you rewrite your existing 4M LOC Java application.

Sure, but then when they finally ship Valhalla you'll still need to rewrite your 4M LOC Java app to use value types ;)

That is one of the engineering challenges of Valhalla, you don't, the JIT will do it for any type that is value like.

Apple fanboys or rust fanboys who talk about superiority of ARC on programming forums are also likely not knowing computer science terms like cache and contention.

Yeah, but dealing with debugging leaking resources (because memory is just one of many resources that a program will use, and GCs don't help with most of them) sucks.

https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...

Ownership model seems hard for people to internalize, but once learned feels very natural, leads to programs that are better structured and frees programmer from "manually managing resources".

That is what happens when one doesn't learn the available tooling for doing deterministic resource management in GC languages.

That also happens when the person is very eager to talk about rust.

Talking to the wrong person I guess.

> available tooling for doing deterministic resource management in GC languages

Other than Python's `with` and alikes, wrapping in a closure, `defer`/`scope` (Go/D), what else is there? What am I missing? None of these work if the lifetime of a resource is not a simple "this scope".

Swift, D and Nim have RAII just like C++.

Idris2 and now Haskell have linear types.

I'm seen other comments of yours and this is a final straw, which makes me stop wasting my time.

Good, now that you have more time available, you can learn how to do C++ style RAII on those languages.

The article mentions lifetimes and cloning. A very similar argument can be made for dyn traits, where some people seem to have an irrational fear of dynamic dispatch, even where it’s a much cleaner solution, in scenarios that aren’t remotely CPU bound.

It reminds me of the good old C++ times, when people were scared OOP would make their programs unacceptably slow because of virtual functions. That's why methods are not "virtual" by default, which led to nasty bugs when you were actually relying on polymorphism and forgot to declare a method virtual. Those were the days.

Rust being relatively new and shiny language compels everyone who just learned it to use all the features as often as possible. I keep falling down this hole too.

Good luck trying to make your Rust code actually slow with random `clone` here and there. You really have to find something huge, or in a tightest loop to even notice a difference. And most applications are IO bound on some DB connection anyway.

But it's a good advice. For some reason people tend to forget that copying stuff is super cheap, and most lifetime issues can be entirely avoided with a `.clone()`.

Oh yeah. I don't feel bad about `.clone()`, it tends to be when I make short-lived Strings when a str might suffice. Then I remember that I write PHP code at my day job.

Good advice for any language. Write it correct first and optimize what’s needed.

100x this. First correct, then make it shiny if necessary.

Make it work, then make it nice.

It's a very important point, and one that is often overlooked, that correctness trumps performance in almost every bit of code you ever write (though not all, there are exceptions). It's also very easy to fixate on measurable performance which is often very removed from the realities of where your code is running (with core contention and memory pressure etc).

I remember years ago coming across a highly optimised md5 calculation function in a legacy codebase that I inherited. Much care have been put into writing it, with comments highlighting how many clock cycles on an Athlon processor were required to run it. This was clever stuff, but the firm wasn't using Athlon processors, and hadn't for years. A quick comparison with boost showed that boost was faster (on the processors of the time), so it got chopped out.

Context is key. Are these folks mentioned in the article programming for fun or for profession? If it’s the former, that certainly is the time for silly optimizations.

TBH - if your code is not speed sensitive you might as well write it in a slower language like Python which is more productive.

There's something to be said about path dependency and honing your skills any way you can. I discovered nice features of Ada2012 (and things that have been neglected in the standard) while writing some scraping-and-generating-svg tools, or replacing some ugly bash scripts.

The more you use one tech (especially out of the usual zone) the more you learn. And maybe you learn to avoid that language.

Also I like being able to come back and pick up small tools in my 'main' languages without rewriting them. So for me it's java for GUIs or highly dynamic runtime-y stuff (introspection, code gen, AOP) or 'throwable' stuff, and Ada for 'serious real-time must run 2 years without crash' stuff.

Too many times I end up maintaining python scripts that have overgrown the 'script' phase and are full fledged business-critical tools and... It's then often too late to back off.

Languages like Python being more productive is a myth. A story people keep repeating, with absolutely no way to back it by facts, not to mention that productivity is not a scalar.

All there is just bunch of subjective experiences in specific circumstances.

But there's a cost induced with this superior productivity, and it's not only about speed. Maintaining and updating these (dynamically typed) programs in the future feels way less productive because things start to break everywhere, unless they've an extensive test base and use modern features like type annotations -- but then, you start losing the productivity advantage you had in the first place.

Not every program grows, or needs to run fast.

The problem is, you can't know in advance whether a given piece of code will ever need to grow in the future or not. I've seen way too many "one-off POC prototypes" eventually be used in production because they did the job. And then they need to be updated / extended a few months later "because we should deal with that new corner case too, now".

Very subjective. I find Python much less productive than Rust. Easy to learn != productive in the long run.

For things like string processing with messy data or data analysis with data I am seeing for the first time - I do find Python much faster than compiled languages - the interpreter really helps in poking at the data.

For things like string processing and data analysis I find Scala much more productive than Python. There are REPL / notebooks for quick iteration just like in Python, but static typing helps tremendously with getting things right the first time and accelerates coding. Features like autocomplete, error highlighting, documentation work much more reliably.

So you are better off with D in these cases.

Reasons for that assertion?

Garbage collected, so I think OP implies its slow? D is a dream to write, and it models problem domains so well. Walter will probably chime in if he reads this

D is also as fast as C++, it is a matter of the developer skils to actually use the tools made available to them.

Reply on news.ycombinator.com