Hacker News Reader

Comment by johnnycerberus | Hacker News Reader

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

View on HN

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.

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?

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.

Reply on news.ycombinator.com