6 ms·

C Is the Greenest Programming Language

39 points by aberoham 5y ago

wheelerof4te 5y ago
C is also one of the hardest languages to master. It is dead simple to learn, but also hard to use the language to do any complex thing on time. Should we factor in the additional energy and time of running the developer's machine just to implement some basic features built-in in languages such as Python? I love writing C don't get me wrong. But it is a tricky language for modern software development, and a very big security liability.
- heavenlyblue 5y ago
  Should we factor in the additional energy required to support that soft mess of a human body writing complex C code? The food it eats, the climate control it needs and the trash it exhausts on a daily basis just to write some incredibly "green code". Sounds like green credits.
  - PinkMilkshake 5y ago
    How does the hourly energy requirements of a human change per language?
- johnnycerberus 5y ago
  This is why I prefer to write core components in C and then call them through the FFI available in the Java, Python or Node runtimes. Or you can go the "zero-cost abstraction" path which is the middle ground, like C++ or Rust, only that abstractions are not alaways zero cost and low level details will creep into the high level APIs. Different people, different preferences. Like seriously, the only reason I still use C++ is because of its HPC ecosystem coupled with its metaprogramming capabilities which are light years ahead from anything that is offered on the market in that department. This is also the reason why game development can't get out of the C++ trap. The future of critical low-level programming is a better C or just plain simple C used in tandem with code generators like F*, deductive program verification like Why3 or just good old mathematics that many are irrationaly afraid of like TLA+.
  - wheelerof4te 5y ago
    C++ is indeed the most useful for use-cases where high-performance coincides with heavy OOP needs. Games fall right into that category. But my hope is that one day people will write games in more secure and slightly less verbose languages, like Rust. Most other software needs can be fulfilled by wrappping C function calls in Python or some other interpreted language.
    - johnnycerberus 5y ago
      I agree with you, I believe that simulators, games, software that are "walled-gardens" in the sense that they don't have a lot of interactions with the external world aside from IO and netcode for multiplayer games (that's a pita though), will be usually better in a purely functional model. We must either stay single-threaded or adopt purely functional programming or transactions in those kind of systems. Now, this can be achieved in both C++ and Rust as those kind of systems are not "safety critical", C++ has the edge in metaprogramming while Rust is one step forward in moving the lifetime correctness on the programmer's turf. It's hard to make a point which one is better suited right now as both in my opinion are flawed and have their advantages, it gets evangelical pretty fast. One thing I know is that C++ has the upperhand just because of the sheer amount of libraries that exist in the space and its supporters like Autocad, Valve, Epic and other companies that have billion $ infrastructure built on it. Right now I'm working with fax machines and I have to provide a C library which is consumed by Scala services. Neither C++ nor Rust would have been an advantage as we are familiar with other methods of verification which are more battletested.
      - CodeGlitch 5y ago
        > Right now I'm working with fax machines People still use fax machines? What is the use case?
  - physicsyogi 5y ago
    The cost of Rust's abstractions are largely at compile time, not at runtime. For example, see https://idursun.com/posts/rust_zero_cost_abstractions_in_action/ https://idursun.com/posts/rust_zero_cost_abstractions_in_act... or https://carette.xyz/posts/zero_cost_abstraction/ https://carette.xyz/posts/zero_cost_abstraction/.
chunkyguy 5y ago
Shouldn't the energy labels also account for build times? Surprising to see Rust and C++ occupying top positions, even though they're notorious for slow build times.
- ironmagma 5y ago
  Run time >>> build time
  - GoblinSlayer 5y ago
    Depends on frequency of updates.
    - naikrovek 5y ago
      are you building each time you run? maybe while developing, but never in production. run time is far more important than build time.
      - hnfong 5y ago
        Generally you're probably right, but it does depend on how many users you have. Not speaking from experience, but I'd presume there are quite a few custom software projects that are designed for one single client running on a cluster of handful of machines.
      - GoblinSlayer 5y ago
        In some cases a build is more expensive than a run.
        ironmagma 5y ago
        In those cases, you should probably be using a scripting language instead of a compiled one. But really, in most cases you aren’t running once per compilation.
- em3rgent0rdr 5y ago
GoblinSlayer 5y ago
There are lies, utter lies and benchmarks.
- TheMonarchist 5y ago
  I agree in sentiment, but those results are actually pretty close to what I expected to see. Edit: I was most surprised to see Pascal on top, but that's probably due to it being very old. Back then it had to be fast by modern standards, to be usable on contemporary machines.
  - GoblinSlayer 5y ago
    Maybe a more compact heap? If the C heap does more bookkeeping or sentinels, then there would be a bit of overhead.
- OldHand2018 5y ago
  Keep in mind that these results were presented at a conference in 2017. Both Go and Rust have had compiler improvements since then. Would that change the rankings if rerun today? Maybe! > We analyzed 27 different programming languages, each with roughly 10 solutions to the proposed problems, totaling out to almost 270 different cases. These solutions were developed by experts in each of the programming languages, with the main goal of "winning" by producing the best solution for performance time. While the different languages contain different implementations, they were written under the same rules, all produced the same exact output, and were implemented to be the fastest and most efficient as possible. Having these different yet efficient solutions for the same scenarios allows us to compare the different programming languages in a quite just manner as they were all placed against the same problem. If this is their methodology, I'll give them the benefit of the doubt on their results. I'd love to see the code!
mikewarot 5y ago
Free Pascal/Lazarus is also near the top of that list, and it lacks a bunch of constructs that make handy footguns. It doesn't do macros. It doesn't have all the .H files. It doesn't default to null terminated strings It also has a lot of nice features Begin/End make it easy to see blocks It has clear syntax for dealing with pointers. @P is the address of P, P^ is what the pointer P points to It makes it easy to tell assignment := from equality tests = It defaults to passing function parameters by value, but can also pass by reference, or pointer. It does separate compilation (units) Strings are memory managed for you, counted, and can even have nulls in them. Identifiers aren't case sensitive. It now supports for .. each in loops You can even participate in the Google Kickstart rounds in free pascal to hone your skills.
- KronisLV 5y ago
  If anyone would like to learn a bit more about Pascal, have a look here for something pretty up to date: https://castle-engine.io/modern_pascal_introduction.html https://castle-engine.io/modern_pascal_introduction.html As for the IDEs, Lazarus is indeed a great option, allowing for both desktop software and most other kinds of development (though admittedly Pascal's strengths don't lie in webdev): https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
bmitc 5y ago
I don't see any mention of Forth there. https://www.youtube.com/watch?v=0PclgBd6_Zs https://www.youtube.com/watch?v=0PclgBd6_Zs
butterisgood 5y ago
It helps that hardware vendors attempt to make their platforms run like a PDP... C and hardware are a bit of a cyclic match of dependencies. It doesn't have to stay this way, but it probably will.
em3rgent0rdr 5y ago
hackaday links to https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle... Seems there is an updated paper by same author: https://haslab.github.io/SAFER/scp21.pdf https://haslab.github.io/SAFER/scp21.pdf And results table: https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re... And results charts: https://sites.google.com/view/energy-efficiency-languages/updated-functional-results-2020 https://sites.google.com/view/energy-efficiency-languages/up...

39 points by aberoham 5y ago

C is also one of the hardest languages to master. It is dead simple to learn, but also hard to use the language to do any complex thing on time. Should we factor in the additional energy and time of running the developer's machine just to implement some basic features built-in in languages such as Python? I love writing C don't get me wrong. But it is a tricky language for modern software development, and a very big security liability.

heavenlyblue 5y ago
Should we factor in the additional energy required to support that soft mess of a human body writing complex C code? The food it eats, the climate control it needs and the trash it exhausts on a daily basis just to write some incredibly "green code". Sounds like green credits.
- PinkMilkshake 5y ago
  How does the hourly energy requirements of a human change per language?
johnnycerberus 5y ago
This is why I prefer to write core components in C and then call them through the FFI available in the Java, Python or Node runtimes. Or you can go the "zero-cost abstraction" path which is the middle ground, like C++ or Rust, only that abstractions are not alaways zero cost and low level details will creep into the high level APIs. Different people, different preferences. Like seriously, the only reason I still use C++ is because of its HPC ecosystem coupled with its metaprogramming capabilities which are light years ahead from anything that is offered on the market in that department. This is also the reason why game development can't get out of the C++ trap. The future of critical low-level programming is a better C or just plain simple C used in tandem with code generators like F*, deductive program verification like Why3 or just good old mathematics that many are irrationaly afraid of like TLA+.
- wheelerof4te 5y ago
  C++ is indeed the most useful for use-cases where high-performance coincides with heavy OOP needs. Games fall right into that category. But my hope is that one day people will write games in more secure and slightly less verbose languages, like Rust. Most other software needs can be fulfilled by wrappping C function calls in Python or some other interpreted language.
  - johnnycerberus 5y ago
    I agree with you, I believe that simulators, games, software that are "walled-gardens" in the sense that they don't have a lot of interactions with the external world aside from IO and netcode for multiplayer games (that's a pita though), will be usually better in a purely functional model. We must either stay single-threaded or adopt purely functional programming or transactions in those kind of systems. Now, this can be achieved in both C++ and Rust as those kind of systems are not "safety critical", C++ has the edge in metaprogramming while Rust is one step forward in moving the lifetime correctness on the programmer's turf. It's hard to make a point which one is better suited right now as both in my opinion are flawed and have their advantages, it gets evangelical pretty fast. One thing I know is that C++ has the upperhand just because of the sheer amount of libraries that exist in the space and its supporters like Autocad, Valve, Epic and other companies that have billion $ infrastructure built on it. Right now I'm working with fax machines and I have to provide a C library which is consumed by Scala services. Neither C++ nor Rust would have been an advantage as we are familiar with other methods of verification which are more battletested.
    - CodeGlitch 5y ago
      > Right now I'm working with fax machines People still use fax machines? What is the use case?
- physicsyogi 5y ago
  The cost of Rust's abstractions are largely at compile time, not at runtime. For example, see https://idursun.com/posts/rust_zero_cost_abstractions_in_action/ https://idursun.com/posts/rust_zero_cost_abstractions_in_act... or https://carette.xyz/posts/zero_cost_abstraction/ https://carette.xyz/posts/zero_cost_abstraction/.

chunkyguy 5y ago

Shouldn't the energy labels also account for build times? Surprising to see Rust and C++ occupying top positions, even though they're notorious for slow build times.

ironmagma 5y ago
Run time >>> build time
- GoblinSlayer 5y ago
  Depends on frequency of updates.
  - naikrovek 5y ago
    are you building each time you run? maybe while developing, but never in production. run time is far more important than build time.
    - hnfong 5y ago
      Generally you're probably right, but it does depend on how many users you have. Not speaking from experience, but I'd presume there are quite a few custom software projects that are designed for one single client running on a cluster of handful of machines.
    - GoblinSlayer 5y ago
      In some cases a build is more expensive than a run.
      - ironmagma 5y ago
        In those cases, you should probably be using a scripting language instead of a compiled one. But really, in most cases you aren’t running once per compilation.
em3rgent0rdr 5y ago

GoblinSlayer 5y ago

There are lies, utter lies and benchmarks.

TheMonarchist 5y ago
I agree in sentiment, but those results are actually pretty close to what I expected to see. Edit: I was most surprised to see Pascal on top, but that's probably due to it being very old. Back then it had to be fast by modern standards, to be usable on contemporary machines.
- GoblinSlayer 5y ago
  Maybe a more compact heap? If the C heap does more bookkeeping or sentinels, then there would be a bit of overhead.
OldHand2018 5y ago
Keep in mind that these results were presented at a conference in 2017. Both Go and Rust have had compiler improvements since then. Would that change the rankings if rerun today? Maybe! > We analyzed 27 different programming languages, each with roughly 10 solutions to the proposed problems, totaling out to almost 270 different cases. These solutions were developed by experts in each of the programming languages, with the main goal of "winning" by producing the best solution for performance time. While the different languages contain different implementations, they were written under the same rules, all produced the same exact output, and were implemented to be the fastest and most efficient as possible. Having these different yet efficient solutions for the same scenarios allows us to compare the different programming languages in a quite just manner as they were all placed against the same problem. If this is their methodology, I'll give them the benefit of the doubt on their results. I'd love to see the code!

mikewarot 5y ago

Free Pascal/Lazarus is also near the top of that list, and it lacks a bunch of constructs that make handy footguns. It doesn't do macros. It doesn't have all the .H files. It doesn't default to null terminated strings It also has a lot of nice features Begin/End make it easy to see blocks It has clear syntax for dealing with pointers. @P is the address of P, P^ is what the pointer P points to It makes it easy to tell assignment := from equality tests = It defaults to passing function parameters by value, but can also pass by reference, or pointer. It does separate compilation (units) Strings are memory managed for you, counted, and can even have nulls in them. Identifiers aren't case sensitive. It now supports for .. each in loops You can even participate in the Google Kickstart rounds in free pascal to hone your skills.

KronisLV 5y ago
If anyone would like to learn a bit more about Pascal, have a look here for something pretty up to date: https://castle-engine.io/modern_pascal_introduction.html https://castle-engine.io/modern_pascal_introduction.html As for the IDEs, Lazarus is indeed a great option, allowing for both desktop software and most other kinds of development (though admittedly Pascal's strengths don't lie in webdev): https://www.lazarus-ide.org/ https://www.lazarus-ide.org/

bmitc 5y ago

I don't see any mention of Forth there. https://www.youtube.com/watch?v=0PclgBd6_Zs https://www.youtube.com/watch?v=0PclgBd6_Zs

butterisgood 5y ago

It helps that hardware vendors attempt to make their platforms run like a PDP... C and hardware are a bit of a cyclic match of dependencies. It doesn't have to stay this way, but it probably will.

em3rgent0rdr 5y ago

hackaday links to https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle... Seems there is an updated paper by same author: https://haslab.github.io/SAFER/scp21.pdf https://haslab.github.io/SAFER/scp21.pdf And results table: https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re... And results charts: https://sites.google.com/view/energy-efficiency-languages/updated-functional-results-2020 https://sites.google.com/view/energy-efficiency-languages/up...