Hacker News Reader

Comment by psyc | Hacker News Reader

I agree with you. I've been a C and C++ programmer for decades, and nothing to do with memory safety or leaks has ever risen to the level of prohibitive or even annoying. Ironically, I've had infinitely more grief from fighting hostile garbage collectors, but that's because I'm a game programmer. I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.

I'm always met with strawman arguments about how I can't possibly write "correct" code. It's a strawman because I don't claim to write correct code. I don't care if Herb Sutter can find 1000 "bugs" in my C++. I care that my users and myself are happy.

View on HN

I've heard this criticism from several game developers at this point. Contrary to some other voices here, I do think it's legitimate: if safety isn't important to you, then I can't argue with that.

At the same time, I think that Rust made the right choice for most domains. For most software, memory safety problems that hostile attackers find have consequences. Games are an exception, not the rule. It would be irresponsible for us to target servers or network-facing client software without memory safety.

It's also of course true that we have many game developers in the Rust community. A lot of people, including me, see safety as a productivity booster, especially combined with all the other features in Rust. I've advanced suggestions in the past for making unsafe Rust easier to program in, effectively turning off some of the safety checks, specifically for game developers who would prefer not to have the restrictions. These suggestions have been very unpopular in the Rust community, including from the game devs, and so they haven't gone further.

I'm a little confused game developers are so dismissive of attack surface -- after all, most games I've played in recent memory have some level of network access (multiplayer, achievements, etc.), and very few game developers seem to be OK with rampant exploitation in their online communities.

"Never trust the client". The assumption should always be that the game client is lying to the server, whenever that's possible. In multiplayer games, a stream of keypresses is sent to the server, and a game state is sent back to the client.

At least, that's part of the argument that I assume they'd make.

Totally, although I assume at least some game shops are using shared C++ libraries on both client and server.

Am I dismissive of the catastrophic effects of being shot, because I never wear a bulletproof vest? Again, not every individual app has the same problems. I'm not working on WoW. My best guess as to the number of people trying to attack my games is honestly zero.

The real problem with C (and to a lesser extent C++) nowadays is not just memory leaks or segfaults, but all the security vulnerabilities you get from the lack of memory safety.

Your code might work 100% correctly for your users, but it may also put their system into risk when processing arbitrary and potentially malicious data. When your system needs to handle data that may come from anywhere - and almost every system does - writing Herb Sutter-correct code is no longer just a nice-to-have.

That might be the chorus when it comes to selling new languages, but there is no reason C could not be compiled with memory safety. It is not done because by the end of the day people don't care for safety much.

It's obviously not happening because C's design... especially lack of any guarantees... combined with what those checks required made complete, memory safety hurt performance a lot. Talking multiples worse (300+%). Things like Softbound+CETS and Criswell's SAFEcode have gotten it down below 100% worse performance in many cases. Others seem to explode in delay on specific routines due to how they interact with the bookkeeping methods.

Whereas, Ada, Wirth, and Eiffel languages were designed to make the job easier for users and tooling. SPARK was even tailored to make it easy to prove absence of C-style vulnerabilities with automated proving. That was done by a small team over a period of years whereas global assortment of teams putting decades into static analysis or proof tools for C haven't pulled that off outside even more restrictive tools like Astree Analyzer.

C is just inherently bad for safety despite safe ways of doing it existing. That's because it was designed almost exclusively to run fast on a PDP-11. That simple. On other end, Hansen wrote Edison for a ultra-minimal language for a PDP-11. It was smaller than C, easier to process, and still had safety features. Reiterates it was simply a personal preference by C's designers to not care about safety while many others did.

A big part of the point I meant to make is the difference between theoretical problems and practical problems, and how priorities and risk vary a lot across applications. The number of complaints I've received about malware targeting my games over the last 25 years is exactly zero. So when I go looking for my perfect language, that's not a problem that I'm trying to solve. I'm not arguing that other languages shouldn't exist, I'm saying they don't address the most important problems in my domain (roughly, expressiveness and performance).

> A big part of the point I meant to make is the difference between theoretical problems and practical problems, and how priorities and risk vary a lot across applications.

And this is how we had ILoveYou and similar viruses. In the name of the whole internet, I hereby thank you very much for your hard work in this matter.

ILoveYou was an email attachment virus. Email attachments are forever being targeted, games less so.

I would say, far lesser extent C++ (unless you're just writing C and compiling with a C++ compiler).

As a game programmer, exploitability is fairly low on your list of priorities, but for other systems it's quite important. If hackers can find 1000 bugs in your C++ that get them remote access to your computer through the browser, ... well, this is why people hate Adobe.

> I don't care if Herb Sutter can find 1000 "bugs" in my C++.

Until the new release of GCC improve its performance by 10% by optimizing more cleverly an Undefined Behaviour but OOPS it now breaks your code …

> I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.

Rust isn't only about safety, it's also a «C++ on steroid from 2015» with a ton of cool features : Modern type system, no null pointer, parallel code without fear, package manager …

Rust is a huge productivity booster IMHO !

> I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.

There are plenty of other expressiveness advantages to Rust, over and above the safety advantages you apparently wouldn't benefit from.

The problem is that stuff like ownership and mutability are explicit and smack in the center of the language. They're not optional. I don't want to write those semantics at all.

How would you feel about Modula-3 without the upper-case and a bit less verbosity? It was industrial development of Wirth's philosophy at DEC. I always thought it did the best of the safer languages balancing features, simplicity, safety, fast compiles, and runtime performance. Example is built-in concurrency, simplified (optional) OOP, and deciding on per variable basis whether to use garbage collection.

https://en.wikipedia.org/wiki/Modula-3

I've considered rebooting it with a few modern lessons built-in plus some Ada safety features. Everything transparent where it doesn't go into the language unless it's easy to work with and consistent. Add Scheme-like macros and good FFI for C like in Julia.

EDIT: I just saw your comment about cherry-picked subset of C++. That's how I describe Modula-3 in many comments elsewhere. Now I'm extra curious what gripes you may have with it.

Unfortunately, I'm not familiar with Modula-3 or Ada. But I will look into them. Thanks.

Oh wait, if doing Ada, then take this link:

http://www.adacore.com/knowledge/technical-papers/safe-and-s...

Remember as you read it that it starts a bit from scratch in the 1980's mainly for embedded, real-time systems that can't fail. The thing to focus on as you skim table of contents or chapter contents is they systematically find the constructions that screw people up, statically prevent them where possible at type system, catch others dynamically by default, and let you drop to unsafety where necessary. The range types (esp existential types), ability to control bit layout, & concurrency safety are old favorites of users in safety-critical space.

SPARK is a subset of Ada with extra annotations to help it catch errors statically. It can, with automated provers, show the most common problems can never happen in your code. Here it is:

http://www.spark-2014.org/uploads/itp_2014_r610.pdf

http://www.spark-2014.org/about

Modula-3 sounds interesting, from a couple of fans I've spoken to over the years. I'm curious as to how it was simultaneously (a) taught in universities for years and (b) completely forgotten in the popular culture.

It's a social and economic phenomenon. It happens so much I discussed here the possibility of creating some central resource for knowledge in programming, security, etc specifically designed to prevent it. It would have an accompanying forum of people vetted to know about various tech or skills. That way experienced people can pass the wisdom onto new crowd to cut down on some of the fads or at least how they deafen everything.

A number of companies used Modula-3 experiencing its benefits. Only use I recall in FOSS that was widespread was CVsup which was since rewritten.

https://modula3.elegosoft.com/pm3/intro/questions/whym3.html

There used to be a big ad for Module-2 ( not 3 ) toolchains in the back of Byte magazine ( when it was relevant ) but they were all bytecode interpreted, and not as performant as 'C'.

Universities weren't that relevant back then. Fully half the people I worked with through the end of the 20th Century did not have CS degrees.

In good part because Universities where I was (partly due to donations and funds from IBM) did not tolerate microcomputers, connect to them, and refused to put in a single course regarding them. PC's weren't classy, they were only the future.

"Upgrading" Modula-3 is an interesting idea, but I wonder how much you'd have to tweak for it to be worth the effort. I suspect that adding a new chrome would end up as something awfully like Go.

Go, in my opinion, is currently the best distillation of the Wirth progression of languages that we have. The Go authors (one of whom worked on Oberon-2 at Wirth's ETH Zürich) took a lot of inspiration from Wirth, and Go is in many ways a reactionary language as a result: A simple, strict type system; easy to parse (Wirth's languages all famously fit on a single screen of EBNF grammar, not sure if Go is quite that small); design choices favouring the pragmatic over the theoretical (ignoring the last 30 years of type theory), reasonably performant, etc.

I'm not sure there's that much left in the original well. Modula-3 did have a "safe" construct, but it seems a bit naive today (nowhere near Rust's advanced, complicated safety features). Explicitly choosing between GC/non-GC seems like something compiler writers should be able to automatically optimize. Modula-3 did have generics, of course.

I think it could be a bit better if it got close to Ada's safety features without their unusability. I was considering adding a borrow checker, ref counting, and Go-style GC to it for various use cases. Idea being people could choose along spectrum from quick prototyping with reasonable performance to hard work for safety without GC. Add Design-by-Contract support from Eiffel with SPARK-like static analysis on modules simple enough to allow it. Complex modules could be analyzed easier than C since it's a Wirth-style language. Port either Rust's or SCOOP's concurrency model so it's safe-by-default. Maybe a few things from functional programming for decoupling of modules without getting too much overhead.

I don't think it has to be Go language or have nothing we've learned from type theory while being easy to use. Just has to have a base as easy to use as Go with options to bring you closer to Ada, Eiffel, or Rust in safety + performance. Plus macros maybe with compiler being LISP on inside for ultra-easy transforms like Julia did. :) The combination should be quite advantageous where baseline of safety & maintenance is achieved at Go speeds with effort of rest increasing other attributes.

That was my brainstorm on it anyway. It's all up for debate outside the part where it would be easier to learn & compile than Rust or Ada. Their strategies are intrinsically complex vs a Wirth language with some upgrades.

I think a language like that could be great if you managed to synthesize all the good parts into a modern whole.

I always liked the very pragmatic mechanism, in Wirth's languages and in Ada, of attaching constraints to data types; for example, defining a type as an integer of range 1..9. On the one hand, from a type-theoretical viewpoint, it's completely cheating — the mechanism is hardwired into the language, there's no real underlying system or symmetry to it, unlike a proof-based language such as Idris or Agda. On the other, it's awfully pragmatic.

Sorry, I still don't see it. Once you internalise the logic of Rust's borrow checker, you'll see that probably 80% of your code already follows this discipline and would pass the borrow checks without trouble.

Some small amount of code is probably hiding mistake in various corner cases which the borrow checker will point out. The remainder is legit safe code, and you can use unsafe annotations to do what you would do in C.

So you're throwing away a powerful tool just because it impacts maybe 5% of the code you want to write, but not even in a way that would really impede you in the end.

Sometimes you have to wonder if these admonitions from industry trendsetters are really just sneaky tricks to slow the rest of us down...

"Hey, that C++ code that's been working for years? All wrong! Go rewrite it in Node.js. No, no, no, in Go this time. Now Rust!" ...

I absolutely don't disagree with both of you.

That being said, I've been knowing game developers for years and while I don't know their exact complaints, they kept saying they wished they were working with something else than C++.

I think it's mostly solving the same problems many times over and over, during their entire career.

I do wish I was working with something else. Something I'm still surprised doesn't exist yet. I understand the reason it doesn't exist is that a cherry-picked subset of C++ is good enough. This hypothetical language would be a greatly simplified C++ with a couple dozen small annoyances smoothed over.

Absolutely. I'd be delighted to code in a simplified C++.

Well, you CAN do simplified C++. Apple even had their own version of it called 'Embedded C++' (the drivers in OSX are like that) -- basically, remove RTTI, exceptions, templating and a few other bits and you get a C with namespacing, objects, nice context-based stack based objects and a few other nice things, without the bloat.

So, yes technically you CAN write nice lightweight C++; but you won't be able to enforce it in a team, as everyone will need 'their' pet feature of doom to bring back the bloat.

How do I know? Well, I tried for years to do it like that; and eventually I had to give up. Now I do plain C, because it can't be corrupted in the same way.

"But, but, I just #included <vector>!!"

"... What, for a 5 byte constant array?"

"Yeah I know, but the compiler will just inline it!"

Or worse:

    #include <boost/fusion/container/vector.hpp>

"Why do we need Boost for this single vector?"

"Well... We're using Boost elsewhere..."

Now we use C. Not C++.

If someone is using a vector for a small array of fixed size in C++, in a place where performance matters, then their knowledge level is so low that you are going to have issues with them no matter what, I'm afraid. Knowing that vector uses the heap is beginner level knowledge.

On the other hand, in C you are stuck with a built in array now. If you pass this to a function that doesn't get inlined, it will decay into a pointer, then inside that function the compiler has actually "lost" knowledge of the size of the array. Now you have to pay for a loop.

In C++ you can pass a std::array by const reference, the compiler knows exactly how big that array is at all times, and for small arrays the loop checks can be eliminated entirely.

Many of the arguments against C++ boil down to: if you're working with a lot of people who have a knowledge level below what I would expect someone with 1 year of good experience to have, then they can make more mistakes. Is the level of developers generally really that low?

To which my answer would be "write your own". Whenever I program in C I always use my own dynamic, bound checked arrays that store their own length.

I am often surprised that many C programmers often don't build their own abstractions. The OpenSSL library is a prime example of this - the same 4 or 5 arguments passed in the same order to hundreds of functions. I am always surprised they didn't just make a struct.

You are missing my point.

It can store it's own length, but the compiler will still not be aware of the length, except in a real local context (i.e. in the same block of code, either actually, or via inlining). So if you decide to loop over your array, you have to pay the price of looping (jumping and comparing).

If you know that you are working with an array of fixed length, and you use a C++ std::array, you can pass this by reference to functions and those functions will know at compile time how long the array is. So you don't have to pay for looping at all; if you do something small in a loop the compiler will unroll it to 3 assignments or what not.

In addition, the reason that C programmers don't build their own abstractions is because C does not have templates. So building your own abstraction either means that it's not very abstract (i.e. restricted to one data type), or you are using void, or macros, or both. These things are all horrible to work with, void based data structures also involve a performance hit. This tilts the trade-off between writing abstraction and single-use code far, far towards the latter.

In C++ you have templates which are far better for writing your own data structure than macros, and have no performance penalty.

You might be interested in Jai[0], Jonathan Blow's (as yet) unreleased language designed with game development in mind.

It's not strictly a subset of C++, but rather focuses on syntax and semantics that are convenient for the rapid development/exploratory refactoring and high performance that are characteristic of game dev.

Lots of tools for different kinds of manual memory management, build rules integrated into the source, syntax support for easily switching between "arrays of structs" and "structs of arrays" (and data-oriented types in general), simple static typing with type inference, that kind of thing.

[0] https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

> Sometimes you have to wonder if these admonitions from industry trendsetters are really just sneaky tricks to slow the rest of us down...

No, I didn't work on Rust for the past six years while sitting in the office twirling my mustache trying to think of ways to slow the industry down.

I worked on it because we kept seeing the same issues come up again and again and again.

Reply on news.ycombinator.com