Can Rust save the planet? Why, and why not
- Reference: 1638272048
- News link: https://www.theregister.co.uk/2021/11/30/aws_reinvent_rust/
- Source link:
Miller is also a senior engineering manager for AWS, and Lerche a principal engineer at the cloud giant.
How can Rust save the planet? The answer is that more efficient code requires fewer resources to run, which means lower energy usage in data centers and also in the environmental impact of manufacturing computing equipment and shipping it around the world.
[1]
Shane Miller and Carl Lerche speak on Rust efficiency and safety at this year's AWS Re:invent in Las Vegas
“Data centers consume … 1 per cent of all worldwide energy,” said Miller, though adding that the total energy consumed had changed little in ten years, thanks to technology advances and the fact that cloud tends to reduce the proportion of idle resources.
The second part of the argument is that Rust is among the most efficient programming languages. The source quoted for this is a 2017 paper
[2]PDF
that measured the performance, memory usage, and energy efficiency of 27 programming languages, and placed C as most efficient, but Rust close behind with just three per cent more energy use. Java uses nearly double the energy, C# over three times, and Python over 75 times as much, according to the stidy.[3]
Languages ranked by energy efficiency, according to a 2017 research project
This is an AWS conference after all
The research is problematic, as several at the session on Monday observed, not because of lack of care, but because languages have many implementations and compilers, some of which are more efficient than others. It is also odd to find TypeScript 10 times less efficient than JavaScript, considering that it compiles to JavaScript and similar code can be written in both.
Still, this is not all that important since there is no doubting Rust’s efficiency, as a systems language, and Miller and Lerche did not rely solely on this research. Miller also referenced case studies from Discord and from Tenable that showed huge efficiency gains.
[4]
In the Tenable case, a JavaScript component was rewritten in Rust and achieved a 50 per cent improvement in latency, a 75 per cent reduction in CPU usage, and a 95 per cent reduction in memory usage. “It’s kind of crazy,” said Miller. “It’s substantial savings, not just in infrastructure, it translates into savings in energy.”
[5]
[6]
Garbage-collecting languages are inherently less efficient, said Lerche. Garbage collection is a common means of automating memory management and works by identifying objects that are out of scope and freeing their memory.
“The garbage collector is going to have to pause the process to do the garbage collection pass. And when it's paused … the service is not able to respond anymore to requests,” he said. This means languages such as Java, C# and JavaScript can never be as efficient and performant as C and Rust.
[7]
Why not just use C and C++? The reason is security and memory-related bugs, said Lerche, quoting research that “70 per cent of all high severity security vulnerabilities in software in C and C++ are due to [lack of] memory safety.”
Rust is revolutionary, he said, because “Rust is the first mainstream programming language that is efficient while maintaining memory safety.” Lerche explained how Rust achieves memory safety by using the idea of [8]ownership , based on a concept called Affine logic, where each object has one and only one owner at a time.
Ownership rules are checked at compile time, so there is no runtime overhead. Concurrency too is easier and safer in Rust than in C or C++, leading to further performance and efficiency gains.
[9]
It seems too easy. All the developer and IT community needs to do is to migrate to Rust and code will run faster and more securely, world energy use will drop, and AWS can close half its data centers (though we did not hear this last idea during the session).
Big but
“But,” said Miller, “if we’re going to reach the carbon reduction goals … we’re going to need most new software written in energy efficient languages like C or Rust. But Rust does have a somewhat notorious learning curve … we are seeing that adoption but we are not seeing it everywhere.
Rust does have a somewhat notorious learning curve … we are seeing that adoption but we are not seeing it everywhere
"Where I’m seeing Rust growing the most is where there’s an outsized performance gain, so high volume database services, also in small resource-constrained environments like IoT and embedded. We’re not seeing it so much in: you’re writing a back-end for a JavaScript app.”
The problem is that coding in Rust is hard. One reason why languages like Java, JavaScript, and Python have seen such wide adoption is that programmers can become productive more quickly.
This then is the elephant in the room, “the famous learning curve,” said Miller. In a recent survey, “of the engineers who said they were no longer using the language, 55 per cent cited learning and productivity as their reason for abandoning it. Experienced engineers require three to six months of study supported by a subject matter expert before they are productive with the language.”
[10]All change at JetBrains: Remote development now, new IDE previewed
[11]AWS is on the threshold of adulthood, but is nowhere near grown up
[12]AWS chops data transfer fees by massive extension of free tier – 2 months after rival previewed R2 Storage
[13]AWS claims 'monumental step forward' with optional IPv6-only networks
Is there any possibility of reducing the learning curve? “Part of the challenge with the learning curve is not so much that it is difficult to use, but there are gaps in the developer experience, so we’re seeing feedback from engineers who are coming from languages like Java and trying to use Rust that they’re uncomfortable with the debugger experience,” Miller said, in answer to our question. “The performance profiling tools are not the same as they are accustomed to. And that’s an area we are investigating.”
“Rust came, historically, as a replacement for C++," Lerche added. "It was targeted at that use case. But what we’re finding is that there’s a lot of application in a higher level.
"If you’re coming to build a service, you go through the Rust book which is very thorough and you will get into lifetimes and traits and trait patterns and all these concepts that are part of the language but aren’t necessary to write a service.” There are plans, he said, to write simplified documentation that is “what you need to know to write a service.”
Although such initiatives will be helpful, it is difficult to envisage how Rust can become easy enough to learn that business application developers will be able to switch from Java or JavaScript, or C# or Python, when they have business problems to solve and can do more quickly in those other languages.
Further, lower down the computing stack the code probably is written in Rust or C or C++, because when it comes to the Linux kernel, or the core of a database engine, high performance and efficiency is already a requirement.
That said, the key point, that inefficient software is expensive for the environment as well as for the customer, was well made, and something to which the IT industry pays insufficient attention, even if Rust is only a small part of the solution. ®
Get our [14]Tech Resources
[1] https://regmedia.co.uk/2021/11/30/rusttalk.jpg
[2] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
[3] https://regmedia.co.uk/2021/11/30/languages.png
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YaZYvBn@Yly8qoLza2hxsgAAAEY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YaZYvBn@Yly8qoLza2hxsgAAAEY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YaZYvBn@Yly8qoLza2hxsgAAAEY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YaZYvBn@Yly8qoLza2hxsgAAAEY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YaZYvBn@Yly8qoLza2hxsgAAAEY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] https://www.theregister.com/2021/11/29/jetbrains_fleet_ide/
[11] https://www.theregister.com/2021/11/29/aws_reinvent_2021/
[12] https://www.theregister.com/2021/11/25/aws_chops_data_transfer_fees/
[13] https://www.theregister.com/2021/11/24/aws_claims_monumental_step_forward/
[14] https://whitepapers.theregister.com/
Re: That learning curve
Verily, would deserve a 2nd upvote for reference to Verity.
It is quite fascinating to see rankings of different languages by the 3 key metrics shown, even though we know that different applications have aspects that favour one or another.
Still, as a part-time C & python programmer I will probably stick with them as they cover most of what I need and life is getting short for learning a new and unusual language that really only promises a bit more security for my C side. And there is always apparmour as a bit of a backup.
Your C skills will still be usable long after we've all forgotten Rust existed.
Waiting for the next flavour of the day to arrive...
People said that about COBOL, Fortran. At some point something knocks the current king off their throne. Will it be Rust? No idea, but it'll happen eventually. But then you'll be able to charge a fortune for your C skills to maintain those "ancient" C systems that the new kids don't know how to fix. Should get you to retirement, worked for the COBOL guys.
Your C skills would be improved by learning Rust even if ceased to exist tomorrow. The things it beats you over the head about at compile time are transferable to C and C++.
Dumping the cloud
Would save more power than making everyone use Rust. Seriously. If YouTube, Netflix and all the other heavy data users were P2P and designed to use the most efficient routing possible, total server counts could be vastly reduced. Similarly, if we stopped encrypting non-confidential data and stuck to just signing it instead (for integrity), then ISPs could cache more things at the edge, further reducing burdens for remaining non-P2P services with many slow changing pages (e.g. mature parts of Wikipedia).
Then we could all use our dirty PHP. poncey Python and janky Java while still saving the planet!
Re: Dumping the cloud
The Cloud centralises computing and allows greater use of greener energy. In addition, the scale they operate is vastly more efficient than could be done in most on-prem data centres If you look at the three clouds that everyone uses - AWS (Netflix) & Azure say they will be on 100% renewable energy by 2025. (currently above 60%) and Google (YouTube) is already 100% renewable energy.
The biggest reason to doubt rust seems to be that it's "run" by multiple teams of enthusiasts, many of whom are at each others throats. Tantrums, walk-outs and other exciting internal politics abound. All good clean fun, no doubt, for hobbyists but doesn't encourage reliance.
This is utter nonsense.
I am more troubled than the author by the point that TypeScript appears to be 10x less efficient than JavaScript. As the author points, there really is no good reason for this. TypeScript is compiled to JavaScript in a comparatively straightforward manner. If the benchmarks show that much of a difference, I feel that the most likely explanation by far is that the person who coded the TypeScript solution was simply not as skilled, or not as focused on performance, as the person who coded the JavaScript solution. But if that is the case, then the validity of the whole dataset is cast in doubt.
I might be wrong, but I would definitely investigate that data point further, if I were one of the authors.
You could make the argument for C++ and C. It's not as dramatic, but there's no reason why the C++ performance should be noticeably different to C unless you've done something horrible.
Any time you take your code to a higher level, you introduce inefficiencies. Typescript is NOT Javascript, so the comparison is irrelevant. You could claim that everything eventually runs machine code so it is all the same, too.
That could explain, I dunno, JavaScript running 10x slower than C. It could, maybe, explain TypeScript running 5% slower than JavaScript.
That cannot explain TypeScript running 10x slower than JavaScript. The layer of abstraction is just too thin.
You can quite literally take your JavaScript and add types to it to make it typescript. The transpiler then strips the types off after type checking. If the code isn't the same there is either an issue with the transpiler or you didn't actually use the same code in the first place.
Typescript isn't actually executed by the browser in any case. When I was considering adding TypeScript support to the codebase of a large application I work on regularly I tested the performance difference for several common operations and it came out within the margin of error (+/- 5%). I'm using babel to transpile the code so perhaps they used tsc or something else?
Typescript translates into mostly equivalent Javascript. Perhaps there is some runtime overhead but whenever I've debugged JS compiled from TS it seems pretty tight. Maybe that by being a typed language that encourages the use of interfaces and classes that somehow it changes how people write code that is less efficient.
Some environments like deno also allow Typescript to be executed directly. I don't know if they compile it to JS on the fly or cache it somewhere, but I guess that would be less efficient. BTW Deno is written in Rust so things are converging.
> It is also odd to find TypeScript 10 times less efficient than JavaScript, considering that it compiles to JavaScript and similar code can be written in both.
Well, maybe it produces poor quality JavaScript. Maybe it uses excessive resources to compile. And so on. The only thing that would be unlikely is for it to be more efficient that JavaScipt.
Cool!
Looks like its time to brush up on my Pascal!
Mine is the with with a Turbo in the pocket.
Re: Cool!
Steady, next you will be claiming it is a Python in your pocket.
Re: Cool!
Cut it out, Paul!
IIRC that article is commonly considered junk, as it uses benchmark-game benchmarks, where some have been optimized for multithread use, and some not.
It shows more which community wants to invest more time in futile benchmark games than anything related to energy.
Reductio ad absurdum
Lets do everything in assembler, properly hand crafted will be top of all the benchmarks.....
More seriously, as people have said, complier used makes a huge difference (or interpreter for interpreted languages), and that's even the case for "efficient" languages such as C. Back in the day when I did real time work we would build C code using different compilers and examine performance / memory use / size of the resultant output etc. as sometimes trade-offs needed e.g. lower memory use could trump higher "speed" so long as it was fast enough to meet the spec.
Depending on the tasks involved, it was not always the same complier that was "top" in a particular metric, as a particular compiler could be great at optimising some things but comparatively awful at others.
Re: Reductio ad absurdum
> ...everything in assembler...
Assembler? You're lucky! In my day we had to carve hexadecimal on't cave walls. If our cave had walls.
Re: Reductio ad absurdum
You had it easy. We had to program by placing rocks. If there is a rock in the slot, its a 1/true, if there is no rock, its a 0. Used to take forever to bootstrap the Enirock. :)
Re: Reductio ad absurdum
Rocks! We could never afford those, we had to rely on grains of sand - a nightmare on a windy day!
I find it very amusing that Erlang is so far down that list, given how some people I used to work with went on about how it was the greatest language since sliced bread. Apparently Telcos don't care about power consumption. :)
"Apparently Telcos don't care about power consumption"
Most computing projects don't. If they did we would still be writing assembler. The reason we aren't is because time to produce the software is important. Very important.
If you have to tell your audience that your language needs months with the help of another person to become productive then what you have built there is a concept language - looks neat, does a good turn of speed, but isn't going to ever be on the mass market.
Hopefully someone will take Rust's Big Idea and apply it to a language with a sane syntax.
I would be interested in knowing what kind of C++ was used.
Was it:
1) old-school raw owning pointer style
2) unique_ptr and then raw non-owning pointer style
3) shared/weak_ptr everywhere
4) garbage collected (Boehm's or UE4's)
5) full of javascript-style lambdas
C++ is a multiparadigm language (as are many others) but this is quite critical as part of the measuring. Rust would be most similar to #2 (and raw pointer safety replaced with refs and safety of borrow checker)
I wish this madness would just stop
I have no particular issue with Rust - never used it but keep promising myself I will one day - but let’s face it - the world runs on C. With a bit of C++ sprinkled around (*)
Instead of constantly bashing C because it lets you shoot yourself in the foot, why not just learn how to bloody use it properly and stop writing buggy code. I can’t remember the last time I wrote some C that had a memory error. It’s not bloody rocket science - you just have to apply some common sense and a dose of discipline to what you’re doing. It annoys me how so many people complain about C because they are fuckwits who can’t learn how to use it.
The article also mentions the difficulty Java (etc) people have with Rust. Well that’s because Java and Python and (god forbid) JavaScript abstract away the machine so much that the users of these languages often have no clue at all about what is going on under the hood. This is also why we have obscenely inefficient libraries written in these abhorrences and calls to big fat inefficient routines with no appreciation of how heavy they are. This is a fault of our education system rather than the languages, of course.
(*) Of course there are still systems out there happily running Fortran and COBOL code, and while they are being replaced as time goes by, they are still there
Re: I wish this madness would just stop
'C' is the universal assembler, it lets you do all of the low level things you need to do in an OS, etc, including foot-shooting without having to learn assembly for a given CPU. There are many ways to make safer-C, such as enabling and responding to compiler errors, using static tools such as Coverity, and dynamic tools such as Valgrind to check things are going well in your memory-use department.
But the world runs on cheap, and good programmers are not so cheap and take longer to build, test, document, and retest their code. How many companies actually give a fsck about that?
That learning curve
Rust would be a lot easier to learn if it didn't insist on using terms we think we already understand to mean things that we don't think they mean.
An obvious example is the use of "variable" for something you can't vary (you need a mutable variable for that -- as [1]Verity explains).
Another example might be the use of "enum" to mean something that is more akin to a discriminated union than the simple enumerated integral types of most other languages (rust is not alone in this, Kotlin's enums are similar).
Those hoping to ascend the rust learning curve have first to break through the preconception barrier.
[1] https://www.theregister.com/2019/11/27/in_rust_we_trust_stob/