1. 40
  1. 51

    Worldwide, data centers consume about 200 terawatt hours per year

    Exactly as much as Bitcoin!

    All the world’s communication/entertainment/business/traditional-finance/etc. vs. one ponzicurrency that supports seven transactions per second…

    It’s great that the “reasonable use of computing power” side is optimizing their use even further, but the world really, really needs to crack down on the “intentional waste of computing power” side, yesterday.

    1. 3

      Tbh I think most governments seem to think it’s useful because someone is making money. Which goes back to why are governments asleep at the wheel on climate change. Which goes back to…they probably think the problems won’t apply to them personally.

    2. 14

      I think the callout to the learning curve is great, but I don’t think I’ve ever seen any concrete proposals to fix it. I think it’s just baked in to the language.

      At Google (opinions my own) we are exceptionally conservative about adding new languages (we only really have Java, C++, Python and Go). The two strong reasons are library support and code sustainability in order years. We expect developers to be able to learn any language they need to, but with Rust I think the jury is out that even experience software engineers can get over the hump in a reasonable timeframe, let alone without writing pretty poor code along the way.

      Having worked in C++ for the last year, I do find the worry about lifetimes ever present and a constant nerve wracker. I’d like to see Google support Rust, but I just don’t see it happening unless something significantly changes along these dimensions, and i haven’t seen that in any roadmap of Rust I’ve seen.

      (I also deeply miss Steve Klabnik when it comes to community interactions… dude is a rockstar)

      I’d love it if any lobsters have any docs they think will help change my mind.

      EDIT: I also wonder how compile times factor into this energy sustainability argument: large companies are running thousands (tens of thousands?) of builds all the time: that’s a significant CPU burn.

      1. 32

        At Cloudflare we have lots of people learning Rust, and it’s working great for us. They do get stuck initially, but on simple problems that more experienced devs can help with.

        But the great thing is that novice Rust users are not dangerous. The worst thing they do is cloning objects more often than necessary. You can have noobs writing Rust with less experience than what is required to let anyone anywhere near a secure C++ codebase.

        1. 21

          but I don’t think I’ve ever seen any concrete proposals to fix it.

          • Polonius borrow checker to handle more cases than NLL, which was already a big improvement over 1.0 scope-based borrow checker (BTW, when people think borrow checking could be done with some metaprogramming in C++, they don’t even realize the depth of the problem).
          • View types, especially if they could be applied automatically to make getters/setters not annoying.
          • Async in traits (and async itself is dodging a lot of pains that used to exist with closures used for callbacks)
          • Generators

          Major improvements have already landed:

          • “match ergonomics” means you can get far without knowing the ref keyword and randomly inserting & Into match until it compiles.
          • 2018 modules syntax that is closer to what people expect
          • cargo fix
          • huge investment in high quality error messages and clippy lints (option.unwrap() used to get people stuck, now the compiler tells you where you need as_ref()).
          • const generics made arrays not broken for >32 elements.

          Rust isn’t easy, but has improved a great deal since 1.0, and it has been a conscious effort to flatten the learning curve.

          1. 2

            Thanks for all these, I really appreciate it!

          2. 11

            how compile times factor into this energy sustainability argument

            Surely even with the (sometimes maybe somewhat excessive) “test every push” CI culture that we have these days, production server infrastructure is orders of magnitude larger than the dev infrastructure… any efficiency in prod is multiplied by the size of prod.

            And with C++ being one of the incumbents, it’s not like everything has fast compile times before switching to Rust ;)

            1. 2

              And with C++ being one of the incumbents, it’s not like everything has fast compile times before switching to Rust ;)

              Oh tell me about it. My previous team was Go and I’d get kind of annoyed if my build times went to 8 seconds or so when I was writing tests in basically a live coding manner. Now my builds can take up to 40 seconds 😭

              1. 4

                up to 40 seconds

                Clearly you aren’t on the Chromium/Blink team…

            2. 9

              As to “getting over the hump”, I just recently finally did it. Coming from advanced-level Go and advanced background in C++ before that, I see three key reasons to my breakthrough: (1) “Programming in Rust, 2nd ed.” from O’Reilly; (2) Rust got better enough recently, finally overcoming some issues that annoyed me super much before, esp. thanks to anyhow and thiserror (and a few other things, like async, and NLL before that); (3) me realizing that in a triangle of language design priorities of: “performance - simplicity - security”, when in an irreconcilable conflict, Go chooses simplicity, Rust chooses performance AND security (which is crazy enough IMO that there’s an AND, not OR).

              Mind me, I’m still sadly writing tons of non-idiomatic Rust for now, and not everyone in my new workplace seems patient with that; yet let me tell you, I’ve seen way too many “advanced” Go programmers writing FAR-from-idiomatic Go (oh, the pain…). Google not adopting Rust now instead of C++, if you say it is so, in my opinion is a huge “yellow flag” for them, and will be seen as a costly (though probably not critical, with their deep pockets) blunder, probably resulting from a critical mass of C++ devs in house, who subconsciously fear having to admit to themselves their skills are becoming obsolete, and also fear the effort and risk required to learn new tech stack. Personally, I currently think of C++ in context of Rust already as having become “a COBOL” - for a new company to choose it, there can be reasons, but IMO all of them de facto legacy; at best because their target microcontroller doesn’t support Rust. Technically IMO “doesn’t yet”, but where “yet” will sadly probably mean some 15 years (or even more), given how hardware companies seem to think of software.

              Please note I by no means claim Rust is perfect. Notably, I’d certainly wish there was less of “as_ref()” etc. noise in the code, compile times are a downgrade from Go (though again, with incremental compilation it’s not that bad recently), and certainly I can prototype faster in Go. But when comparing with C++ specifically… I strongly believe the line is clearly crossed and I just can’t see how Rust could not overtake C++ in the long-term scale. If I met someone young who’d ask me whether to learn C++ or Rust, for their future advantage I could only recommend Rust. Maybe C too if they are of the kind whom I could recommend Assembly as well, i.e. for understanding the low-level and navigating critical legacy (like Linux codebase) - but only as a later extra.

              1. 5

                I think you’re being uncharitable re: why won’t Google adopt Rust yet. There’s a massive upkeep problem that has nothing to do with even the human element. You’ve got things like internal standard libraries, static code analysis like Sourcegraph that now has to understand a new language, build chains and release containers, security analysis and patching, interop with code that’s already written (it’s very rare that you get to start a new project with complete blue sky runway), Rust itself has churned really hard since inception, code written two years ago isn’t idiomatic today… the list goes on and on.

                I think the Chrome summation is a good start in understanding, at least in terms of interop: https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability/

                Again, nothing says that Rust won’t eventually be adopted and I personally think it’s inevitable, but thus far Java and C++ have remained exceptionally resilient in enterprises over new languages, even if those languages provide good benefits (Java in particular is pretty decent at porting good features from other languages into it).

                1. 2

                  I started thinking on what you wrote, but then it occurred to me, that if they wanted to use Rust, with the money they have they could take a few of their especially brilliant engineers with CS background and throw them at the problems listed in the doc, and probably have them solved quickly enough. So, for the time being, I’m still not especially convinced.

                  1. 1

                    “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” – Rob Pike, lead developer of Go.

                    Personally, I don’t see Google adapting anything they haven’t developed and control, but that’s my opinion.

                2. 8

                  Having made the awful awful mistake of learning C++ as a first language as a child, even beyond the “lifetimes prevent you from writing wrong code!!!” stuff, I feel like C++ has soooooo many obtuse rules and weirdness going on, that if you’re thinking about the rules and complexity, whether Rust or C++ is more complex feels like a wash? Stuff like lvalues/rvalues, specialization…. Rust doesn’t even have inheritence on its end!

                  And like…. god forbid you would have to use something like Scala (with its mix of OOP/FP and magic action at a distance with implicits, inline operators….).

                  I do feel like there’s a lot of discounting doable in Rust where the most-cited complex bits are caught by the compiler, rather than runtime surprises.

                  But even beyond that I feel like C++/Rust/Scala has always been that category of languages that are liked by people who like to play Magic The Gathering: you are writing programs, but also interacting with the language rules and doing a bunch of stuff there.

                  As to the “poor code” thing… I definitely agree that there’s a uniqueness to Rust where making the wrong data structure decision ends up infecting every related type signature because of lifetimes and the like, it feels like you would need very good initial codebases to get things running.

                3. 14

                  Is there any evidence at all that more efficient languages do anything other than induce additional demand, similar to adding more lanes to a highway? As much as I value Rust, I quickly became highly skeptical of the claims that started bouncing around the community pretty early on around efficiency somehow translating to meaningful high-level sustainability metrics. Having been privy to a number of internal usage studies at various large companies, I haven’t encountered a single case of an otherwise healthy company translating increased efficiency into actually lower aggregate energy usage.

                  If AWS actually started using fewer servers, and Rust’s CPU efficiency could be shown to meaningfully contribute to that, this would be interesting. If AWS continues to use more and more servers every year, this is just some greenwashing propaganda and they are ultimately contributing to the likelihood of us having a severe population collapse in the next century more like the BAU2 model than merely a massive but softer population decline along the lines of the CT model. We are exceedingly unlikely to sustain population levels. The main question is: do we keep accepting companies like Amazon’s growth that is making sudden, catastrophic population loss much more likely?

                  1. 5

                    We’ve always had the Gates’ law offsetting the Moore’s law. That’s why computers don’t boot in a millisecond, and keyboard to screen latency is often worse than it was in the ‘80s.

                    But the silver lining is that with a more efficient language we can get more useful work done for the same energy. We will use all of the energy, maybe even more (Jevon’s Paradox), but at least it will be spent on something else than garbage collection or dynamic type checks.

                    1. 4

                      I can tell you that I was part of an effort to rewrite a decent chunk of code from Python to C++, then to CUDA, to extract more performance when porting software from a high-power x86 device to a low-power ARM one. So the use case exists. This was definitely not in the server space though, I would love to hear the answer to this in a more general way.

                      I’m not going to try to extrapolate Rust’s performance into population dynamics, but I agree with the starting point that AWS seems unlikely to encourage anything that results in them selling fewer products. But on the flip side if they keep the same number of physical servers but can sell more VM’s because those VM’s are more lightly loaded running Rust services than Python ones, then everyone wins.

                      1. 3

                        I’ve spent a big portion of the last 3+ years of my career working on cloud cost efficiency. Any time we cut cloud costs, we are increasing the business margins, and when we do that, the business wants to monitor and ensure we hold into those savings and increased margins.

                        If you make your application more energy efficient, by what ever means, it’s also probably going to be more cost efficient. And the finance team is really going to want to hold onto those savings. So that is the counter balance against the induced demand that you’re worried about.

                      2. 6

                        Decades ago, the discussion was about C vs assembly language regarding speed and efficiency.

                        I’m glad to have more choices that allow greater abstractions.

                        1. 5

                          Extrapolating from the benchmarks game seems like a stretch too far for me. Firstly, the quality of implementation varies greatly between languages. I see no reasonable reason for such a large difference between JS and TS. Secondly, are the majority of cloud applications doing computations in that language? I would expect most applications to either be working a lot with databases, or to wrangle network IO. Both would see a significant reduction in language dependence, as computations are done in C/C++ DB/OS anyway.