4 ms·

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 fact

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

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