6 ms·

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

• jstewartmobile 10y ago
  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!" ...
  • pdimitar 10y ago
    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.
    • deleted 10y ago
      [deleted]
    • psyc 10y ago
      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.
      • pdimitar 10y ago
        Absolutely. I'd be delighted to code in a simplified C++.
      • buserror 10y ago
        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!"
        • shakna 10y ago
          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++.
        • quicknir 10y ago
          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?
  • pcwalton 10y ago
    > 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.
• naasking 10y ago
  > 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.
  • psyc 10y ago
    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.
    • nickpsecurity 10y ago
      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 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.
      • psyc 10y ago
        Unfortunately, I'm not familiar with Modula-3 or Ada. But I will look into them. Thanks.
        • nickpsecurity 10y ago
          Oh wait, if doing Ada, then take this link: http://www.adacore.com/knowledge/technical-papers/safe-and-secure-software-an-invitation-to-ada-2012/ 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/uploads/itp_2014_r610.pdf http://www.spark-2014.org/about http://www.spark-2014.org/about
• unscaled 10y ago
  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.
  • htns 10y ago
    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.
    • nickpsecurity 10y ago
      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.
  • psyc 10y ago
    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).
• stymaar 10y ago
  > 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 !
• pjc50 10y ago
  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.
• pcwalton 10y ago
  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.
  • dikaiosune 10y ago
    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.
    • khedoros1 10y ago
      "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.
      • dikaiosune 10y ago
        Totally, although I assume at least some game shops are using shared C++ libraries on both client and server.
    • psyc 10y ago
• hash-set 10y ago
  The security community has been chasing these issues in UNIX for what? 40 years? It's a definite issue.