Is It More Energy-Efficient to Program in Rust?

Posted by EditorDavid

on Sunday February 20, 2022 @07:34AM from the language-barriers dept.

• ›

  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:

    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:

      b) C does everything, and you should be using C if your project needs to be speed-oriented.

      If there's such a speed requirement that unsafe Rust or C is needed over safe Rust, then you should probably be using assembler, not C.

      We have finally reached the point that there's a programming language that even C++ programmers can respect that's memory safe. The only thing stopping ourselves from removing C and its flaws from the computing ecosystem (outside of legacy code) is silly efficiency arguments that h

  • • Re:

      Only assembly language can beat C.

      • Re:

        FPGAs and ASICs can beat assembly, and both are used quite a lot in real world hardware to run otherwise very CPU hungry tasks (like media codecs) with much less energy consumption.
        
        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.

          Maybe Rust is a good language, but why was the language given the name "Rust"?

          
          
          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.

            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:

              Allegedly the name is derived from the rust fungi. A group of parasitic fungi causing diseases in plants.
              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:

              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:

            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:

        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:

          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

            Also it could be argued that fortan was optimised for 1960s hardware and hence doesnt do any better on modern FPUs than C.

    • 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:

        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:

          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.

          • 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

              Take a look at just how cut down the version of C++ for the arduino is. Good luck using the STL in 2K.

        • • • Re:

              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:

        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

        • "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.

          • 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.

          • "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:

                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:

              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:

          Yes. Including creating the most convoluted, unmaintainable, low-performance mess. Try doing that in C. In C++ it is easy.

      • Re:

        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

          A lot of those more portable language compilers and JVMs ironically being written in C. Sorry, you were saying?

          • Re:

            And that is relevant to the falsity of the superset claim above...how exactly? If on some architectures (such as those with multiple hardware stacks) C can't run well, those particular implementations of those languages logically WON'T be written in C. The fact that on other architectures well supporting C those same languages would be implemented in C is unrelated.

    • You have to go out of your way to do that in Java

      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

        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:

          I strongly suspect that your bill would be the lowest by far if you hosted the whole thing yourself.

      • Re:

        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)

  by The Evil Atheist ( 2484676 ) on Sunday February 20, 2022 @07:59AM (#62285293)

  It's more energy-efficient to program in COMPILED LANGUAGES compiled by OPTIMIZING COMPILERS.
  
  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:

    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.

    • Re:No. (Score:4, Interesting)

      by The Evil Atheist ( 2484676 ) on Sunday February 20, 2022 @09:12AM (#62285417)

      Rust is not the only compiled language to offer safety, and all the Rust CVEs shows that it does not actually escape the problems of other compiled languages.

    • by Joce640k ( 829181 ) on Sunday February 20, 2022 @09:31AM (#62285453) Homepage

      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:

          C++ has references. No copying needed.

          • Re:

            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:

              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:

          This is incorrect. C++11 introduce the move constructor and copy elision. Your knowledge of C++ is out of date.

  • Re:

    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:

      You can't do that with the default tools but yes, it is possible.

      How did you miss the "compiled by OPTIMIZING COMPILERS" part which completely sinks your argument? Seriously, it was on the first line.

      • Re:

        Here I was not even considering running Java through a non-optimizing compiler, be it a non-optimizing JIT compiler or a non-optimizing AOT compiler, so I'm not sure why this distinction would be relevant here. Of course we're talking about optimizing language implementations here. Why would you use any other these days? (Outside perhaps of some very restricted device profiles such as embedded applications, smart cards etc.)

        • Re:

          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:

            For long-running processes such as the ones in data centers, these are asymptotically indistinguishable. The compilation takes a fixed amount of time whereas execution is essentially unbounded. The ratio of a fixed number divided by an unbounded number converges to zero.

            • Re:

              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:

                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.

                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:

        You can't do that with the default tools but yes, it is possible.

        The default tools do indeed do that, just not when you're thinking they do. Java is never interpreted. It's compiled to machine code immediately before execution and that machine code typically exists until the instance of the application is terminated.

        But yeah IIRC there was a GCC front end that compiled Java to machine code so you could create an a.out file at one point. I don't know if it still exists.

        It's kind of interesting because

        • Re:

          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:

          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*

    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!

• 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:

    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:

      How about not waking up computers in the middle of the night to check for updates?

  • Re:

    I dunno. Java is a hot mess. Rust is a big cloud edge language now which makes me feel compelled to accept some of the hype. But I haven't personally pulled the trigger on it yet. Not saying I won't, just saying not yet.

    • Re:

      Go for it! I'm a big Rust fan and have `been using it for everything that I would have done in C++. The compiler error notifications and indeed the whole Rust ecosystem are just excellent. Whenever I complete a Rust project, I have this great feeling that I've produced something very solid.

• "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:

    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:

      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:

        "DTACK Grounded". Thank you Cypress for fast SRAM chips.

  • Re:

    JIT compilation.

    • Re:

      Yes, that certainly is another contributing factor.

  • Re:

    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:

        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.

• 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

    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:

      The thing folk almost certainly like but dont admit thats what it is, is the included libraries.
      
      People leave C/C++ in waves.
      
      These waves can be labeled. The Java wave. The.NET wave. The Python Wave.
      
      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

        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:

        If you give people more options, of course some of them will use the new options.

        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

    Unstable ABI is relevant only for Rust and means that you need the same compiler version to produce binaries. I don't see how is that an issue. Nothing prevents you from making a shared library in Rust and export symbols with C ABI.

• 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.

• The more mistakes you make, and the more serious they are, the more you learn and become a better programmer.

  • Re:

    There may be some survival bias embedded in that conclusion...

    • Re:

      Its easy for the least capable to claim that the thing they couldnt get over was unfair, that those that did get over it are biased.
      
      So easy, in fact... that its predictable. You are predictable.

    • Re:

      Just because Lefty isn't saying anything, and No-Head *can't* say anything, you reach this conclusion?:)

  • Re:

    C as trillion dollar economic damage training wheels for system programmers seems a poor investment to me.

  • Re:

    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

• Someone could generate a lot of electricity from all the hot air being blown around trying to sell Rust.
• As if the a programming language decided what energy is spoiled for... if you save a little here, people will add more abstraction layers and "bling bling" elsewhere to the software. And use less efficient algorithms and data structures because they cannot be bothered to contemplate their efficiency.
  
  And if, after all, any energy savings are left, crypto-miners will gladly use them up.

• 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.

• 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:

    I found the buzzkill at the language war!;)

• If you're worried about energy use and environmental impact, I'd ask what all this code is doing in the first place, and is it "necessary"? More cat videos? Another cryptocurrency? Duplicate Slashdot articles?
  
  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

    "You know I can break in to your house while wearing a mask, and the doorbell itself won't prevent anything?"

    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.

• 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:

    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.

• I'm a C programmer, but I recognize that it takes longer for a C program to be written and debugged than a Python or Java program. So if the end result can indeed be more power efficient, how much extra time (and computer power) has been spent developing and debugging it ?

  • Re:

    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.

• 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.

• 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

      You're math is terrible. You are very very wrong about that.

• 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?

• 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

• 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

• Java is most energy efficient language right now - b/c of 20+ years of coal mining that produced current state of open source libraries. Start with Rust and you have to reinvent all of it from scratch.

• 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

• 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.

• They are having a hard time finding developers in *any* language, let alone C developers who can program without shooting off their own foot, or Rust developers of any kind. C is mature, but it was developed along side Unix and like the OS it is "user friendly but picky about who is a friend". Rust is interesting, but isn't quite as stable or mature yet. If you code to standard C, you target the C99 spec and you're good. Rust was not even released until 2010. At that point, C was not only old enough to