C Is the Greenest Programming Language | Hacker News Reader

C Is the Greenest Programming Language

hackaday.com

39 pointsaberoham33 comments

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.

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.

How does the hourly energy requirements of a human change per language?

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

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.

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.

> Right now I'm working with fax machines

People still use fax machines? What is the use case?

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_act... or https://carette.xyz/posts/zero_cost_abstraction/.

The complexity that comes from the zero-cost abstractions promoted by both C++ and Rust here isn’t in performance (not runtime nor compiletime) but in programmer reasoning and refactoring.

Better C would be Zig.

I just took a glance at Zig, but I don't think we need better C. C has it's niche and will for some time.

The most natural evolution at this point is to develop languages that have powerful, native multi-threading support.

So far, only Rust, Go and few functional languages qualify for this.

What do you mean native multi-threading? How is e.g. something like java, c++, etc not native multi-threaded

I meant that it is built-in to the language and supported in syntax.

Something like Go's channels.

All of my mentioned languages have it built-in to the language (though arguably, c++’s solution is “only a lib”)

Ada has had language-integrated concurrency features for decades.

Don't forget Ada, quite similar to C but fewer footguns and much better safety properties. It's niche, but it has its users.

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.

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

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/

There are lies, utter lies and benchmarks.

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.

Maybe a more compact heap? If the C heap does more bookkeeping or sentinels, then there would be a bit of overhead.

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!

I don't see any mention of Forth there.

https://www.youtube.com/watch?v=0PclgBd6_Zs

hackaday links to 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

And results table: https://sites.google.com/view/energy-efficiency-languages/re...

And results charts: https://sites.google.com/view/energy-efficiency-languages/up...

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.

Run time >>> build time

Depends on frequency of updates.

are you building each time you run? maybe while developing, but never in production.

run time is far more important than build time.

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.

In some cases a build is more expensive than a run.

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.

even developer incremental builds don't have to be too bad when caching (like with ccache or run-vcpkg on github) and use smaller C files (unless you change some header file which triggers make world).

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.

Reply on news.ycombinator.com