Languages performance

Posted Dec 4, 2022 5:22 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: Languages performance by stephen.pollei
Parent article: Memory Safe Languages in Android 13 (Google security blog)

> At the moment, rust seems like it could be slower to develop in then a few other languages.

This may be true. Beware of people making stronger statements than that. It is inherently difficult to empirically validate general claims about development time or effort. This is because of a combination of the Hawthorne effect (when people know they are being studied, they work harder), and various software-specific issues identified by Fred Brooks, most importantly the non-fungibility of developers and software projects.

Rust might be slower than other languages, ceteris paribus, or it might not, but real life is not ceteris paribus, and other confounding variables should also be considered. Use the language that best fits your requirements.

Languages performance

Posted Dec 4, 2022 7:22 UTC (Sun) by stephen.pollei (subscriber, #125364) [Link] (1 responses)

Yes, I'm conjecturing based on limited data. Using Rust at a startup: A cautionary tale by Matt Welsh and a few second-hand sources. Rust seems like an interesting language and I'm very ignorant about what it is like to actually use it. Even if it is slower to develop in and remains slower for certain projects, it still might make a lot of sense for many projects. Things certainly are not ceteris paribus; As developers gain experience with this new language, libraries and documentation mature then it will be a more even test.

Languages performance

Posted Dec 5, 2022 18:03 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I'd say it's something like this:

- Rust is faster out of the gate (cargo beats autoconf, meson, CMake, etc. at getting the basics in order).
- C and C++ allow for quicker initial iteration because the compiler lets you get away with stuff while Rust requests more up-front design work.
- Once established (MVP or similar), the Rust project is likely to be faster as there is not a gamut of instrumented CI builds to wait on for every MR (to paper over gaps the compiler can't notify about).
- Maintenance is *way* better in Rust because I'm not tracking down memory problems in `gdb` or `valgrind` and instead dealing with (usually) structured errors and messages instead of random memory corruption.

So where Rust falls behind is a place that would help C and C++ projects *anyways* if it were done: a little more planning ahead about the overall terrain the project will apply to.

Languages performance

Posted Dec 4, 2022 7:47 UTC (Sun) by d4no0 (guest, #115694) [Link] (3 responses)

I totally agree, a language is just a tool to accomplish your task, each language has ecosystems best suited for their areas. When I hear people wanting to use rust for developing web servers, motivating that on language popularity and "performance" it makes me question their skills as an engineer. At the end of the day an engineer is supposed to solve a problem, but not write code for the sake of writing more code.

Languages performance

Posted Dec 4, 2022 13:14 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (1 responses)

I guess this depends what you think "web servers" means. If we want to correctly serve maybe 100 simultaneous users of this site that's mostly calling database procedures as they click on stuff I agree that Java and C# makes lots of sense, but I'm just not sure I'd call that a "web server". I spend a lot of my working hours doing this stuff, in C#, it's not exactly thrilling but it works, so why change it?

On the other hand Rust might very well be the correct choice to write a replacement for Apache httpd / nginx / IIS / etc. which are what I think about as a web server.

Languages performance

Posted Dec 4, 2022 20:29 UTC (Sun) by stephen.pollei (subscriber, #125364) [Link]

Yes, I read recently that CloudFlare is replacing many uses of nginx with something they are writing in rust.How we built Pingora, the proxy that connects Cloudflare to the Internet ; Cloudflare is moving away from NGINX | The Backend Engineering Show .

CloudFlare claims, "Having a developer friendly interface engineers are familiar with while eliminating the previous constraints allows us to develop more features, more quickly." . This is different than the other project that I referred to. They also seem to claim that it allowed them to do better multiprocessor optimizations realistically and thus be more performant in practice than other languages. It seems like there are a lot of interesting project happening with rust

Languages performance

Posted Dec 5, 2022 6:01 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

If it's the same engineer, with roughly equal skill in both rust, and an interpreted language like java or javascript, it's likely rust will go faster. It's not totally unreasonable.

Hotspot claims notwithstanding, interpretation imposes a noticeable overhead, and GC, even the latest ones in java 17, still gets you with tail latencies. And in k8s, I've even seen the overhead from java running (relatively speaking) like molasses until most of the classes are loaded, impact how you provision autoscaling.

If it's two different engineers, with different skills (particularly if the first is gone, and the new one has less experience in the given domain), then, yeah, making a blanket statement like "rust will be faster" is questionable.

As far as maintainable, yeah, it's a curate's egg, that one. I love the Rust language, the language itself is reasonably mature, but the existing libraries / frameworks for web serving are very immature.

I like Java (although people abusing Optionals and Streams is getting tiresome, basically autocomplete encourages people to stop making methods, and just chain a bunch of fugly lambdas together, and Spring *sigh* I use it, but *sigh*, known bad practices, per the Spring engineers, are still endemic to Spring code), but the frameworks & libs are better than what Rust has.

Javascript is alright. Particularly in terms of ExpressJS being at pretty much the perfect level of abstraction for how I think. But even with async / await, callback hell persists. And nodejs can have impressive performance.. until it doesn't, and it's still overhead you won't have in Rust.

So, without context, if someone says "Rust will be faster".. hey, they might be right.