Is It More Energy-Efficient to Program in Rust? (amazon.com) 243
A recent post on the AWS Open Source blog announced that AWS "is investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions."
It was written by the chair of the Rust foundation (and leader of AWS's Rust team) with a Principal Engineer at AWS, and reminds us that Rust "combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java."
But there's another reason they're promoting Rust: Worldwide, data centers consume about 200 terawatt hours per year. That's roughly 1% of all energy consumed on our planet... [C]loud and hyperscale data centers have been implementing huge energy efficiency improvements, and the migration to that cloud infrastructure has been keeping the total energy use of data centers in balance despite massive growth in storage and compute for more than a decade... [I]s the status quo good enough? Is keeping data center energy use to 1% of worldwide energy consumption adequate..? [Will] innovations in energy efficiency continue to keep pace with growth in storage and compute in the future? Given the explosion we know is coming in autonomous drones, delivery robots, and vehicles, and the incredible amount of data consumption, processing, and machine learning training and inference required to support those technologies, it seems unlikely that energy efficiency innovations will be able to keep pace with demand...
[J]ust like security, sustainability is a shared responsibility. AWS customers are responsible for energy efficient choices in storage policies, software design, and compute utilization, while AWS owns efficiencies in hardware, utilization features, and cooling systems.... In the same way that operational excellence, security, and reliability have been principles of traditional software design, sustainability must be a principle in modern software design. That's why AWS announced a sixth pillar for sustainability to the AWS Well-Architected Framework. What that looks like in practice is choices like relaxing service-level agreements for non-critical functions and prioritizing resource use efficiency. We can take advantage of virtualization and allow for longer device upgrade cycles. We can leverage caching and longer times-to-live whenever possible. We can classify our data and implement automated lifecycle policies that delete data as soon as possible. When we choose algorithms for cryptography and compression, we can include efficiency in our decision criteria.
Last, but not least, we can choose to implement our software in energy efficient programming languages.
There was a really interesting study a few years ago that looked at the correlation between energy consumption, performance, and memory use.... What the study did is implement 10 benchmark problems in 27 different programming languages and measure execution time, energy consumption, and peak memory use. C and Rust significantly outperformed other languages in energy efficiency. In fact, they were roughly 50% more efficient than Java and 98% more efficient than Python. It's not a surprise that C and Rust are more efficient than other languages. What is shocking is the magnitude of the difference. Broad adoption of C and Rust could reduce energy consumption of compute by 50% — even with a conservative estimate....
No one developer, service, or corporation can deliver substantial impact on sustainability. Adoption of Rust is like recycling; it only has impact if we all participate. To achieve broad adoption, we are going to have to grow the developer community.
That "interesting study" cited also found that both C and Rust execute faster than other programming languages, the blog post points out, so "when you choose to implement your software in Rust for the sustainability and security benefits, you also get the optimized performance of C."
And the post also notes Linus Torvalds' recent acknowledgement that while he really loves C, it can be like juggling chainsaws, with easily-overlooked and "not always logical" type interactions. (Torvalds then went on to call Rust "the first language I saw which looked like this might actually be a solution.")
The Rust Foundation is a non-profit partnership between Amazon Web Services (AWS), Google, Huawei, Microsoft, and Mozilla.
It was written by the chair of the Rust foundation (and leader of AWS's Rust team) with a Principal Engineer at AWS, and reminds us that Rust "combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java."
But there's another reason they're promoting Rust: Worldwide, data centers consume about 200 terawatt hours per year. That's roughly 1% of all energy consumed on our planet... [C]loud and hyperscale data centers have been implementing huge energy efficiency improvements, and the migration to that cloud infrastructure has been keeping the total energy use of data centers in balance despite massive growth in storage and compute for more than a decade... [I]s the status quo good enough? Is keeping data center energy use to 1% of worldwide energy consumption adequate..? [Will] innovations in energy efficiency continue to keep pace with growth in storage and compute in the future? Given the explosion we know is coming in autonomous drones, delivery robots, and vehicles, and the incredible amount of data consumption, processing, and machine learning training and inference required to support those technologies, it seems unlikely that energy efficiency innovations will be able to keep pace with demand...
[J]ust like security, sustainability is a shared responsibility. AWS customers are responsible for energy efficient choices in storage policies, software design, and compute utilization, while AWS owns efficiencies in hardware, utilization features, and cooling systems.... In the same way that operational excellence, security, and reliability have been principles of traditional software design, sustainability must be a principle in modern software design. That's why AWS announced a sixth pillar for sustainability to the AWS Well-Architected Framework. What that looks like in practice is choices like relaxing service-level agreements for non-critical functions and prioritizing resource use efficiency. We can take advantage of virtualization and allow for longer device upgrade cycles. We can leverage caching and longer times-to-live whenever possible. We can classify our data and implement automated lifecycle policies that delete data as soon as possible. When we choose algorithms for cryptography and compression, we can include efficiency in our decision criteria.
Last, but not least, we can choose to implement our software in energy efficient programming languages.
There was a really interesting study a few years ago that looked at the correlation between energy consumption, performance, and memory use.... What the study did is implement 10 benchmark problems in 27 different programming languages and measure execution time, energy consumption, and peak memory use. C and Rust significantly outperformed other languages in energy efficiency. In fact, they were roughly 50% more efficient than Java and 98% more efficient than Python. It's not a surprise that C and Rust are more efficient than other languages. What is shocking is the magnitude of the difference. Broad adoption of C and Rust could reduce energy consumption of compute by 50% — even with a conservative estimate....
No one developer, service, or corporation can deliver substantial impact on sustainability. Adoption of Rust is like recycling; it only has impact if we all participate. To achieve broad adoption, we are going to have to grow the developer community.
That "interesting study" cited also found that both C and Rust execute faster than other programming languages, the blog post points out, so "when you choose to implement your software in Rust for the sustainability and security benefits, you also get the optimized performance of C."
And the post also notes Linus Torvalds' recent acknowledgement that while he really loves C, it can be like juggling chainsaws, with easily-overlooked and "not always logical" type interactions. (Torvalds then went on to call Rust "the first language I saw which looked like this might actually be a solution.")
The Rust Foundation is a non-profit partnership between Amazon Web Services (AWS), Google, Huawei, Microsoft, and Mozilla.
Well (Score:3)
Yes... but that's not the only reason. There's the ecosystem effect too, if it is less likely to have bugs due to the language design, then there's less overhead (transit, distro patching/maintenance etc).
Re: (Score:2)
The thing is,
a) Rust, horrible brand name, I wish it was called something that didn't sound like unwanted or a side effect.
b) C does everything, and you should be using C if your project needs to be speed-oriented.
If Rust is even 99% of C, it's still not C, and people will pick it apart for that.
That said, Java, Python, PHP, and Javascript (as in browsers and node.js) waste a lot of energy because their purpose is different. They are different tools.
If we want to jump on the energy efficiency argument, we s
Re: (Score:2)
Re: (Score:2)
Only assembly language can beat C.
Re: (Score:3, Interesting)
I wonder whether AMD buying Xilinx brought us nearer to a situation where ordinary user-space software can offload certain tasks to some on-the-fly programmed gate arrays.
"Rust" is a terrible name. (Score:2, Offtopic)
If whoever chose the name was trying to pick the worst possible 4-letter name, why choose "rust"? Why not poop, fart, junk, or crap?
Re: "Rust" is a terrible name. (Score:2)
What's wrong with rust? Your conclusion is so bias as to be bigotry. Rust is basically a chemical reaction that happens on iron... So too we could argue the development of Rust language is a reaction on the outside of more core programming languages...I think the name is fine, it's your perspective that is skewed.
Re: (Score:2)
The implication perhaps being that it grows on something that has become weak? No idea. And frankly I don't care.
If the name of something is the worst thing someone can come up when complaining about it, especially among programmers (who should understand what labels are), then they don't have anything substantial to complain about.
Re: (Score:2)
Because it's a terrible brand.
Nobody wants rust, because rust is primarily a side-effect of the oxidation or decay of metal.
It would likely be adopted a lot easier if people outside OS developer circles knew what it was. Everyone outside developer circles knows that C, C++, C# (or C++++) are. Many people confuse Java with JavaScript, (mistakenly believing that Java is an abbreviation of JavaScript)
That's the problem.
What it should have been called if they wanted to sound like "Rust" is "RRST".
Re: (Score:3)
why was the language given the name "Rust"?
The name is supposed to suggest the language is "down to the metal."
That was thought to be significant because so much language design then and today is based on a complex runtime or abstract machine model.
Re: (Score:3)
Fortran regularly beat the pants off C in performance.
Its a crusty old dinosaur of a language, but it was optimized at a time where "compute" was *real* expensive and recent Fortran compilers still produce shockingly good results in benchmarks , particularly around its core proficiency, math.
Re: (Score:3)
That's mostly due to the limitations of the language. Fortran can make all sorts of assumptions about aliasing that C, or any other language with pointers, simply can't.
Where does aliasing come into play? When you're multiplying matrices and things like that, hence Fortran's "proficiency".
As a general-purpose language? Fortran sucks. As a systems-programming language? Doubly so.
Fortran comes from the era when computers only had capital letters. The lower-case spelling of the name is quite recent.
Re: Well (Score:2)
Also it could be argued that fortan was optimised for 1960s hardware and hence doesnt do any better on modern FPUs than C.
C is one local optimum (Score:4, Insightful)
C has the advantage of being simple enough for the programmer to be able to understand it to a meaningful degree.
C also has the advantage of not being to comfortable. Doing complex messy things can quickly get out of hand. This teaches the programmer to avoid writing code.
C is also rather portable, if you avoid doing "weird" non-portable stuff. As long as your computer is vaguely PDP-11-like your code will run. This is, surprisingly, a superset of hardware other supposedly more "portable" languages will run.
There are of course other local optima.
Re: (Score:3)
This teaches the programmer to avoid writing code.
I strongly dispute this point. It teaches people to avoid writing code in C if they can, perhaps, but when there were few other choices, people wrote fucktons of code in C. Also look at Linux, the kernel and ecosystem as a slightly painful counterargument.
This is, surprisingly, a superset of hardware other supposedly more "portable" languages will run.
Which more "portable" languages? Given the topic, C++ and Rust have essentially the same underlying model of
Re: (Score:3)
Re:C is one local optimum (Score:4)
Yeah, I'm with you. C was one of my first languages, and it's not something I use anymore. For embedded shit, maybe - but in terms of getting real work done I just don't see it.
Yep. What sort of masochist would want to write any sort of data-handling code in C using malloc/free/strdup/strcpy instead of std::string and std::vector?
As far as "embedded" stuff goes: All those Arduinos out there are being programmed in C++ and they only have 2k RAM, 32k flash. They seem to be doing just fine in terms of efficiency. C advocates need to meditate on that for a while.
Re: C is one local optimum (Score:3)
Take a look at just how cut down the version of C++ for the arduino is. Good luck using the STL in 2K.
Re: (Score:3)
Was on a side project with a participating group that was all in on C++, with databases, on an embedded board though beefy enough that it ran linux. So, database too slow, the code style they wrote in was extremely difficult to understand, special templates that did nothing except increase aspirin sales. The rest of us just wrote in C or C++-as-C, and occasionally violated their platform rules because we couldn't afford a two minute boot up time. The "experts" were most definitely using dirty C++ tricks a
Re: (Score:3)
C has the advantage of being simple enough for the programmer to be able to understand it to a meaningful degree.
C also has the advantage of not being to comfortable. Doing complex messy things can quickly get out of hand. This teaches the programmer to avoid writing code.
C++ can do anything better than C. (Proof: C is pretty much a subset of C++)
Learning C++ means putting in the hours though so most programmers never bother. They keep on reinventing wheels in C.
Programming anything complex without RAII is a recipe for memory leaks, null pointers and buffer overflows. Not to mention all the extra code that you have to write when something goes wrong in deeply nested code like file reads encountering an unexpected end of file. In C++ we just throw an exception and the comp
Re:C is one local optimum (Score:4, Insightful)
"C++ can do anything better than C. (Proof: C is pretty much a subset of C++)"
No, not really, C++ actually kinda proves that C is an optimum. So far many of the features added to C by C++ just led to more complexity and new pitfalls. Many of the abstractions C++ offered were leaky. For example implicit object copies may sound like a nice idea, however if you combine that with manual memory management, it'll most likely lead to double frees. Modern dialects of OO-Pascal avoid this, by working with references. Object copies is something you need to code yourself.
However in recent years C++ has moved into another direction, attempting to actually tackle hard problems like concurrency on a below thread level. So C++ might get another chance, if people start new projects and ditch old misfeatures.
Re:C is one local optimum (Score:4, Interesting)
The "old misfeatures" is part of the way too many features of the C++ that make it a such problematic language. Because of the backward compatibility, there is no practical solution to this problem. The name mangling incompatibility across compilers is another C++ long time problem without practical solution. C++ is almost 40 years old now and allowed to test many new ideas on real world applications. It's now time to consolidate all that was learned in something new, clean, secure, and efficient: rust.
Re:C is one local optimum (Score:5, Insightful)
"C++ can do anything better than C. (Proof: C is pretty much a subset of C++)"
No, not really, C++ actually kinda proves that C is an optimum. So far many of the features added to C by C++ just led to more complexity and new pitfalls.
Many, many more of those features removed whole layers of complexity and pitfalls, eg. std::string vs. malloc/free/strdup, or making linked lists - do you really want to keep on recoding that every time you want a list?
C++ also supports object oriented programming. Writing large programs without that support is much more work.
The really big win of C++ is RAII - the compiler will write all sorts of boilerplate code for you automatically. It never forgets to do it and it de-clutters the code wonderfully - objects free themselves (and all their dependencies) without having to write a single line.
C is OK for small projects I guess but it would be lunacy to attempt anything big. I'm not saying it can't be done but the development time would be far longer.
My answer to anybody who says "I can do that in C!" is usually "you could also do it in assembly language, but you don't!"
TLDR; C++ is to C as C is to assembly language.
Every single argument for doing something in C instead of assembler can be changed to doing it in C++ instead of C via a simple text substitution. s/assembler/C s/C/C++.
Re: C is one local optimum (Score:5, Funny)
Re: (Score:3)
Ayup, C is only good for small projects like UNIX, BSD and Linux.
Yes. Noone would even try to write a serious operating system in C today. The above were started when C++ wasn't yet a viable option.
Re: (Score:2)
C++ also supports object oriented programming.
If you want to do OOP in particular (as opposed to say generic programs via templates), then C++ is a rather terrible choice. There's many languages much better equipped in that particular department.
Re: (Score:3)
C++ can do anything better than C.
Yes. Including creating the most convoluted, unmaintainable, low-performance mess. Try doing that in C. In C++ it is easy.
Re: (Score:2)
As long as your computer is vaguely PDP-11-like your code will run. This is, surprisingly, a superset of hardware other supposedly more "portable" languages will run.
It's not a superset at all. C has notorious problems with for example multi-stack machines, on which many 'supposedly more "portable" languages' will run without problems.
Re: C is one local optimum (Score:2)
A lot of those more portable language compilers and JVMs ironically being written in C. Sorry, you were saying?
Re: (Score:2)
You have to go out of your way to do that in Java (Score:2)
I have seen Java programs with horrible memory leaks. So I still prefer plain old ANSI-C.
You have to go out of your way to introduce memory leaks in Java. Skilled programmers can easily leak memory in C. Java devs?...well...first of all, it's not a memory leak if you just construct too many objects...that's just not thinking about scalability and NO language can stop you from doing that. I've never seen actual memory leaks, just people who leave too many references open...which again...is their conscious decision. No language can cure abject stupidity.
Secondly, actual memory leaks can occ
You already get an energy dashboard (Score:2)
Cloud vendors absolutely (and even pathologically) work toward optimizing their compute capacity to cost ratio with regard to hardware procurement and electricity/cooling requirements.
Any costs incurred by the provider are passed down to you. They all charge by compute capacity. (Also storage, but that's a different set of metrics.) If your program can do the task with smaller CPU capacity and less RAM, it costs less. Period.
AWS Lambda is charged by the number of requests (static between implementations) an
Re: (Score:2)
If your implementation in Python takes 30ms and your implementation in Rust takes 2ms, your bill will be substantially lower after ten million invocations.
I strongly suspect that your bill would be the lowest by far if you hosted the whole thing yourself.
Re: (Score:3)
There definitely is a big marketing vibe around Rust. If something really is that good then it doesn't need an army of evangelists.
No. (Score:5, Interesting)
There's nothing special about Rust that makes it energy-efficient. It's all to do with the fact that it does not need a translation layer to execute, just like every other compiled language.
And before any pedants come out, it's obvious from the context that I'm talking about languages compiled to the native machine for the machine it runs on, not compiling to bytecode of some sort.
Re: (Score:3)
Re:No. (Score:4, Interesting)
Re:No. (Score:4, Insightful)
Obviously the idea is that Rust lets you have the advantages of compiled languages without giving up safeties usually offered by interpreted languages. So if you don't want to "juggle chainsaws", as Torvalds put it, you don't have to choose a language with an inefficient runtime environment. You can choose Rust.
So does C++ if you use std::string, std::vector, etc., for storing data.
STL data storage means memory is freed automatically and buffer overflows are eliminated.
Re: (Score:2)
Only if you use value types and then you are doing a lot of copying.
Huh?
C++ has references. No copying needed.
Re: (Score:2)
Unless they've changed it recently, STL containers have always required copy constructors on the types you put in the container.
Yes C++ does have references, but those can't help you when the object being referred to goes out of scope and is destroyed by the RAII mechanism. Perhaps you mean smart pointers? STL predates reference-counted smart pointers.
Re: (Score:2)
Unless they've changed it recently, STL containers have always required copy constructors on the types you put in the container.
Things did change in C++11 when they introduced the move constructor and the introduction of copy elision. So, yeah, you're about a decade behind.
Re: (Score:3)
But std::string is emblematic of where C++ went off the rails. It's no longer a class like it had been previously, it's now a template. STL upended the entire concept of C++ in a lot of ways, it stopped being object oriented and became templates about templates, or smart macros.
In use it acts just like a class so what does it matter.
Templates aren't strictly necessary for std::string. It's handy to be able to use wchar_t instead of char but there really aren't too many possible variants. You wouldn't want a std::string of floats for example.
OTOH templates are absolutely necessary for std::vector, std::list, std::map, etc.
Linux kernel has almost no memory leaks but most average C++ applications do have leaks everywhere despite all the magic bullets.
Linus has almost no memory leaks because of the strict programming guidelines and thousands and thousands of hours spent chasing them down. The effort needed to a
Re: (Score:2)
STL data storage means memory is freed automatically and buffer overflows are eliminated.
Only if you use value types and then you are doing a lot of copying.
This is incorrect. C++11 introduce the move constructor and copy elision. Your knowledge of C++ is out of date.
Re: (Score:2)
And before any pedants come out, it's obvious from the context that I'm talking about languages compiled to the native machine for the machine it runs on
You can compile Java to native code, yet that sill won't magically make Java any more efficient if for example you need to deal with unsigned word-sized numbers efficiently, like you do in cryptography and some other types of programs.
Re: (Score:2)
You can compile Java to native code
You can't do that with the default tools but yes, it is possible.
yet that sill won't magically make Java any more efficient if for example you need to deal with unsigned word-sized numbers efficiently, like you do in cryptography and some other types of programs.
How did you miss the "compiled by OPTIMIZING COMPILERS" part which completely sinks your argument? Seriously, it was on the first line.
Re: (Score:2)
Re: (Score:2)
In that case, compiling to native code is more energy efficient than running bytecode because it doesn't depend on a dynamic recompiler AKA JIT to transform it into native code, a process which expends cycles.
It really doesn't get any more basic than that.
Re: (Score:2)
Re: (Score:2)
For long-running processes such as the ones in data centers, these are asymptotically indistinguishable.
It seems you are referring to the use of caching in the dynamic recompiler which results in increased memory use and is limited supporting runtime environments.
However, the point was abstract: scripts and bytecode are intrinsically more energy inefficient than native code because they must be translated to native code. QED.
Re: (Score:2)
It seems you are referring to the use of caching in the dynamic recompiler which results in increased memory use and is limited supporting runtime environments.
No, I'm not. I'm simply referring to the fact that compilation takes a bounded amount of time whereas execution of server processes takes an unbounded amount of time, and the limit of their ratio is zero. That has nothing to with caching, recompiling, memory use or anything like that.
scripts and bytecode are intrinsically more energy inefficient than native code because they must be translated to native code. QED.
They don't really *have* to be translated into native code, depending on the execution environment, but if they aren't translated, they are indeed much more inefficient (for example like MS Blazor's current use of a WASM intepr
Re: (Score:2)
Re: (Score:2)
It's compiled to machine code immediately before execution and that machine code typically exists until the instance of the application is terminated.
I'm fully aware of the dynamic recompilation and caching that is employed by JRE.
The fact that bytecode must be translated to native code means that addition energy is being expended compared to starting off as native code. QED.
Re: (Score:2)
I don't think there's anything in Java that cannot be achieved in Go, it has an identical memory model
Well, almost. Go allows for interior pointers to components of structs. That on one hand makes GC somewhat more complicated, but on the other hand saves quite a bit of working memory.
*gasp* (Score:2)
Are you somehow trying to imply that my Perl based Python interpreter is somehow energy inefficient?! Well I never!
Since this website only has silly insults, I won't be pointing my glorious Grail browser [wikipedia.org] toward it!
Throw more hardware at the problem. (Score:2)
Data centers use 1% of world energy and Rust is 50% more energy efficient than Java?
Nah, throw more hardware at the problem. Build a couple more wind generators.
Re: (Score:2)
I think this is the general point, but it also goes for the laptops/phones that people use. Poor software is driving hardware sales at the moment and contributing to ewaste. Imagine if phones/laptops didn't need such rapid hardware refreshes.
Re: (Score:2)
How about not waking up computers in the middle of the night to check for updates?
Re: (Score:2)
Re: (Score:2)
Honestly I'm surprised it's only 50% (Score:2)
"Interpreted languages" or "bytecode languages" traditionally lag behind native implementations by roughly a factor of 10, far more than the 50% cited here.
My guess is that practical computing has changed. In the olden days RAM could easily keep up with the CPU, so much so that some CPU architectures actually kept their registers in RAM. Modern processors however are much faster than RAM. So if you process some data that is not yet in the cache your CPU will have to wait quite some time for the data to arri
Re: (Score:2)
In the olden days RAM could easily keep up with the CPU, so much so that some CPU architectures actually kept their registers in RAM.
That hasn't been true for ... at least the not-quite-50 years that I've been programming, and probably longer. The first single-chip CPU I wrote code for was the 6800 (not 68000) and it had on-chip registes that were gobs faster than RAM. The then-contemporary Z-80, 8080, and 6502 also had on-chip registers.
Re: (Score:2)
Some 68k machines were the last machines I'm familiar with where it was more or less true, because they could use SRAM. I'm talking about select Amiga computers here, specifically. I believe you can add SRAM to 1000, 500, 2000, 600, and 1200 at least. Registers are still faster than having to access memory, but SRAM is wildly faster than DRAM.
Re: (Score:2)
Re: (Score:2)
there are plausible reasons why the ratio has shifted from 10x to 2x.
JIT compilation.
Re: (Score:2)
Yes, that certainly is another contributing factor.
Re: (Score:2)
I wrote tiny bytecode interpreters for primitive UI functions in an 8080 assembly environment, both for coding convenience and to conserve scarce memory. There was no cache, so every instruction required a memory read plus some number of internal clock cycles. The speed penalty was around a factor of 30 if the interpreter was general purpose (like Pascal bytecode) with a simulated register or stack model, but less for UI or electromechanical simple state machine and string formatting interpreters. Cache,
Re: (Score:2)
Technically the Pentium Pro combine cache on the same package, not die. Look at the pictures of the backside of the package where the CPU die and cache die are easily identifiable.
Energy-efficient when just looking at one aspect (Score:5, Informative)
Yeah, closer to the metal, better CPU utilization, captain Obvious.
But as good little Rust shills, let's avoid mentioning Rust's unstable ABI, that makes shared libraries a practical impossibility.
Static linking wastes disk space and memory, meaning beefier hardware is required.
And it also means the tiniest security problem in a library involves updating all programs using that library. Hope your recompile/reinstall cycle uses zero energy!
Please don't invoke the bullshit argument "the number of vulnerabilities is severely decreased, because Rust language itself makes code secure"; sure, it may help, but for such a niche language, I find the number of Rust-related CVEs [mitre.org] really impressive.
Of course everything else gets ignored (Score:3)
There's a reason these editors like rust so much. It's usually much more "loved" on stackoverflow than actually used.
Meaning the wannabes like drooling all over it. And... that's about it. They're not the ones that get around to using it and learning in minute detail what works and what doesn't work in and with that language and its "ecosystem".
As flawed as C is, it works, and works pretty well. We by and large know what you can and cannot, should and should not do with it. rust? If I had a task that was
Re: (Score:2)
People leave C/C++ in waves.
These waves can be labeled. The Java wave. The
We are now on the Rust wave. Like all the other fucking waves, the programmers moving from one language to another, all of the waves are the same. They are moving to something they could have gotten 30 years ago but at the fucking time they were badmouthing the obvious destination.
1980's BASIC:
let x = 1
Re: Of course everything else gets ignored (Score:2)
It seems like there are some recent developments in computer science that have passed you by. But that's understandable, type inference is only from 1958 after all, that's like yesterday.
Re: (Score:2)
People leave C/C++ in waves. These waves can be labeled. The Java wave. The .NET wave. The Python Wave.
If you give people more options, of course some of them will use the new options.
1980's BASIC: let x = 1 2020's C-like: var x = 1
Well at least the "2020's C-like" has structures now. 1980's BASIC as a rule didn't. (At least not any of the dialects I had access to back then...)
Re: Energy-efficient when just looking at one aspe (Score:2)
The language does not matter. (Score:4)
The efficiency of the code does. Nothing's going to help if you let a noob write a dozen nested loops instead of a proper algorithm to solve a problem.
Juggling chainsaws is a good thing (Score:2)
The more mistakes you make, and the more serious they are, the more you learn and become a better programmer.
Re: (Score:3)
There may be some survival bias embedded in that conclusion...
Re: (Score:2)
So easy, in fact... that its predictable. You are predictable.
Re: (Score:2)
Just because Lefty isn't saying anything, and No-Head *can't* say anything, you reach this conclusion? :)
hawk
Re: (Score:2)
C as trillion dollar economic damage training wheels for system programmers seems a poor investment to me.
Re: (Score:2)
One of the great things about Rust is that it has made me a better C++ programmer, because when I started programming in Rust, I made a lot of mistakes. However, the Rust compiler caught those mistakes (and told me how to avoid them). The mistakes didn't make it into a running application, like they would have if I had been programming in C++.
It really made me question things that I had never considered when programming C++ with a C mindset. I've come to realize that I really need to be more careful wit
Generate electricity (Score:2)
So more energy left, then, for crypto-miners? (Score:3)
And if, after all, any energy savings are left, crypto-miners will gladly use them up.
Evening News (Score:2)
The chair of the Rust Foundation released a study today indicating that programming in compiled languages is more efficient that programming in interpreted languages. In other news, the VP of Marketing for Nestle' Waters released a study indicating that drinking water is better for the body than drinking bleach... Details at 11.
I have no objections to Rust (Score:4, Interesting)
To me, all languages are syntactic sugar on top of an abstract description.
True, some things you can do in one language can't be done in another, but then not all sugar is interchangeable either.
When it comes to energy efficiency, I can believe Rust does a decent job. But there are tens, if not hundreds, of thousands of computer languages and I sincerely doubt this is a metric many of them have been weighed against.
Even if you're going to use C as the universal representative, you need to be careful.
Let's say a worker thread in C runs 10x as fast but generates 10x as much heat per second as a similar thread in language Blah, then the total energy efficiency of C and Blah for that task would be the same. In other words, it's total energy that matters.
But you can always refactor tasks. Make them more efficient, up to the level the language permits.
So the next obvious question is, how far does the language let you go? Does an ideal Rust solution optimised for energy beat an ideal C solution optimised for energy?
(Remember, there isn't an option for this in the Gnu C compiler.)
And how do you know when you've enough cases to be representative? What are we using to gauge the p value?
So I've absolutely no issue with anyone espousing a given solution. That's healthy.
Boasting about a metric by comparing it with popular alternatives only tells me that democracy doesn't work in finding good engineering solutions, but that's obvious.
Having a reasonably comprehensive table of languages and scenarios that allows you to compare any ordered pair of (language, scenario) to a given metric would be wonderful but nothing like it exists, nothing like it is likely to exist and we shouldn't pretend that it does.
Until you can tell me how Rust compares to Ada, Mars D, Eiffel, Erlang, Haskell, Occam Pi and MUMPS, in addition to ISO C, C++ and Java, all three of which are very similar, then you've not told me much.
And if you're comparing purely out of the box, so not including third party libraries, you've said even less because its apples to oranges.
(If I want to compare prefab houses to alternatives, I don't compare them to a pile of rocks, done wooden planks and a box of nails, I compare them to stone houses and half timber houses. Then it is like with like.)
But, again, there's a lot of libraries out there. Do we use GLibc or New Lib? Do we use the builtin malloc, mimalloc, tcmalloc or Hoard? Or even a debugger malloc?
(If we're trying to match features to get the closest apples to apples we can, this matters.)
And then there's expertise to consider. Just as it takes different skills to build a broch versus the prefabricated parts of a mobile home, how do we make sure we're comparing two equivalent programmers, one skilled in Rust and another in C?
A comparison of existing code won't help. McLaren builds very fast, powerful, fuel-hungry Formula 1 cars, comparing them to a hybrid on fuel efficiency is stupid.
But those same engineers build a car capable of 100mpg at 100mph carrying two adults and two children using the same tech as went into F1.
So we have to compare what tech will do when built for the same purpose not opposing purposes.
It is not a simple comparison.
Re: (Score:2)
I found the buzzkill at the language war! ;)
Ours is not to ask "Why?" (Score:2)
My friend proudly shows me his doorbell camera feed--this phone feed wastes juice every time he gets a delivered package. "It's for security." "You know I can break in to your house while wearing a mask, and the doorbell itself won't prevent anything?"
People, particularly their over-population
Da cloud, da cloud (Score:2)
No, no. You're completely missing the purpose of the modern doorbell camera feed, which is to provide for generalized surveillance at various levels of governance, while at the same time providing a mineable data stream for commercial operations.
Both the government and those commercial operations are quite certain that the money spent by those doorbell owners is well invested in their interests.
"You
No real UI support (Score:2)
If a programming language targets a specific subset of programming challenges, it's relatively easy to build an efficient platform. If a language is designed to support a full set of programming problems, including UIs, it becomes much more difficult.
So as much as it would be nice to take advantage of Rust's good performance and reliability, it's usefulness is limited because it doesn't cover apps that need a UI.
Yes, I know Rust can target WebAssembly and Electron and use HTML as a front end. But WebAssembl
Re: (Score:2)
Microsoft actively supports windows-rs [github.com]. With this you can build native UI application for Windows. This has the same performance as anything you might code in C/C++ on Windows; all you're doing here is calling the same ddls that a C/C++ program would call.
The well supported gtk-rs system provides a portable native GUI API. Here [gtk-rs.org] is the the official book on GTK for Rust. Again, you're calling the same native objects so the same performance will emerge.
Let's not spit in the soup... (Score:2)
Re: (Score:2)
Debugging it once compared to running it millions of times on a thousand servers? I think the development effort might get lost in the noise in terms of power efficiency. The energy aside, the engineering process is a good chunk of the software's cost in dollars and cents.
It depends. (Score:3)
If you know what you're doing and/or are programming embedded stuff, Rust is a very good candidate for energy efficiency. I doubt any part of the Mars Rovers is programmed in Python or Perl.
If however time to market is your constraint and the product is your typical web based application, then programming in Rust is likely to be so inefficient that the lifecycle uses more energy than, let's say, PHP.
Point in case: If I need to babysit and orchestrate a container setup just to keep something running, LAMP will be an order of magnitude more energy efficient. And efficient in others ways too.
So fucking stupid (Score:2)
How much energy is used by developers? Unless you are developing at extreme scale, the energy used to develop the software is going to dwarf the costs of running it.
Re: So fucking stupid (Score:2)
You're math is terrible. You are very very wrong about that.
An elite chess player burns 6000 calories (Score:2)
In a single tournament, an elite chess player burns 6000 calories. The amount of mental activity in a top performing human being can be staggering. Now how does Rust, Java, C, C++, Python and Go compare in terms of the human energy necessary to accomplish basic programming tasks?
The comparison for python is a bit misleading (Score:2)
If you compare a computationally expensive operation, like matrix inversion, by doing naive implementations in both c and python, of course c or rust is going to be 100x better. But in any production code, operations like that are going to be implemented in the same highly optimized libraries for all of those languages, such as blas.
The trade-off is really performance and reliability versus speed of implementation. It makes the most sense to write the majority of an application in a high-level language su
Energy efficiency = fewer frameworks (Score:2)
Ok, I have gray hair, but: the first computer I owned was at least 20,000 times slower than current systems, on top of which it did not have built in floating-point or any of the other fancy instructions. It worked just fine. Now we have nicer GUIs, and some nice things happening in the background, but it remains a mystery: where is that 20,000+ performance gain?
The answer isn't in the programming languages. The answer lies in frameworks. Joe and Jane average programmer doesn't write his own code any more
now spend 20y rewriting all opensource libs (Score:2)
The Python numbers must be bogus. (Score:2)
I routinely code my Python to be within 2x-3x speed of native C/C++/Rust/Go implementations. The memory footprint is always larger, but even so the 50x efficiency difference mentioned above must be bogus, unless the Python code was "stupid", intentionally avoiding any and all optimizations.
For comparisons against static languages, the dynamic nature of Python is NOT NEEDED, and there are multiple ways to bypass that burden, which greatly increases overall efficiency (speed, memory, power).
First, code to "l
Haha. (Score:2)
Energy efficient? All I care about is my own energy -- the effort to write a correct, efficient program -- and that's the only thing you should care about, too.