10 ms·

I think reduction in the number of errors is a worthwhile goal. Switching from C++ to a language without memory safety issues while being just as fast would red

I think reduction in the number of errors is a worthwhile goal. Switching from C++ to a language without memory safety issues while being just as fast would reduce the number of things the developer and code reviewer have to worry about. They could spend more time searching for bugs in the logic, potentially eliminating further issues. In practice what I’ve found is that people prefer to deal in absolutes. A large reduction in a category of bugs isn’t enough, it needs to be eliminated altogether, they say. If it’s still possible in a contrived example, what’s the point of investing in switching?

whatshisface 6y ago
It's a miracle that people who think like that use computers at all - after all, computers only reduce the time it takes to perform a clerical task or a calculation, they do not eliminate it.
- TeMPOraL 6y ago
  No, it's a reflection of a very important heuristic used in programming (that's arguably much more fundamental on a philosophical level, but correct words to categorize it escape me): the zero-one-many principle. If there's more than one something, you have to treat it as if there may be an unbounded number of something. You can only get it out of your head if you can put reliable bounds on it; the best if you can prove there's less than two of something.
  - rictic 6y ago
    So if you could make your build 70% faster, philosophically it wouldn't matter, because you would still have a build step?
    - jfoutz 6y ago
      No, you sort of walked past their point. A thing can happen zero times (never). An example might be 1+1 =0. You could get really unlucky with cosmic rays or something, but really adding two registers, both containing 1, that result isn't going to be zero unless there's some sort of hardware failure. A thing can happen once. an example might be, you can delete a file once. There are ways to get unlucky, of corse, but once it's unlinked it's gone. if it happens more than once, you really should probably think about an unbounded number of times. now days, that sorta means 2^64 times. There will be bugs when something overflows int64, but I hope you get the gist. The parent comment is talking about invariants you can use in an algorithm. I think you might be worried about python vs C or something along those lines. Really, it should all work with a pencil and paper. Which is obviously going to be slower than pushing around electrons. But if you can find those invariants, 0-1-many, you can make a better algorithm. If you're stuck with a pencil it'll still make that faster.
  - smitty1e 6y ago
    I think you're after Mathematical Induction. https://en.m.wikipedia.org/wiki/Mathematical_induction https://en.m.wikipedia.org/wiki/Mathematical_induction
  - barrkel 6y ago
    It's a category error to apply the intuition to a risk calculation, though.
    - TeMPOraL 6y ago
      It's not a category error if you're doing an initial guess. Not to mention, particularly in information security, most of "risk calculation" is intuition and guesses, maaaybe sometimes plugged into a probabilistic framework with something resembling rigor.
      - barrkel 6y ago
        I'd say binary considerations are incompatible with risk calculations because no person and no procedure is perfect nor perfectly followed, nothing is completely bug free, etc. Some small part of a calculation might appear binary, but other terms usually dominate. Risk calculations are far broader than infosec and don't deserve the dismissiveness you seem to be casting towards them. Risk calculations are the core of business. Almost every decision a business makes is a risk calculation; every action has an opportunity cost if it isn't intrinsically risky, and actions with certainty are very rare. (For the avoidance of doubt, I believe that use of memory-unsafe languages should be avoided if reasonably possible, but there are still plenty of reasonable reasons to use C, C++ etc. instead.)
        TeMPOraL 6y ago
        I'm not trying to dismiss risk calculations. I appreciate them and challenges involved, having worked on tools supporting risk calculations in corporate space. I feel this thread is getting out of hand. I initially replied to say why, in general, the kind of thinking that makes you unsatisfied with reductions but not eliminations of concerns, is common among programmers - because it's a sound heuristic. Reducing is good, but eliminating is better.
- deleted 6y ago
  [deleted]
fpoling 6y ago
Also memory-safe languages with GC allow for simpler API and design. That in turn gives more time to think on errors in logic.
- erichocean 6y ago
  They're simpler only if you could care less about performance. C and C++ are primarily used in situations where you do care about performance.
  - saagarjha 6y ago
    They do well in those contexts. They’re used in other places too, but generally with poorer justification and results.
  - _ph_ 6y ago
    Memory safety and performance are not a contradiction, they are widely independant. Yes, some strategies like GC induce an overhead. But in the age of multiprocessor machines, this overhead gets very much reduced by parallel collection. And practice has shown, in programs with a lot of dynamic memory allocation, garbage collected languages often perform even better. There are different approaches, like memory safety by the compiler as Rust does it. And with "performance" in mind, you shouldn't forget, that most large C/C++ programs tend to use libraries to provide some amount of safety, but those libraries are of course adding some overhead too. Finally, the less time you spend on questions of memory management, the more time you have to write an actually fast program.
    - dirtydroog 6y ago
      Sorry, this is hand wavy nonsense. One counter example, we switched from Cassandra (JVM) to Scylla (C++). It was a win in terms of both query latency and infrastructure costs as we required fewer machines to handle the same load. As for having more time to write a fast program... that's funny. If you want a fast program on something JVM based you're pretty much going to be spending the majority of your time writing things in a way where the GC plays as little role as possible.
johnr2 6y ago
> Switching from C++ to a language without memory safety issues while being just as fast Does that actually exist? (I mean in the general case, not just a few carefully chosen benchmarks).
- _ph_ 6y ago
  Yes, they do exist. The safety of Rust comes from the compiler (which takes its time), not from run-time checks. For certain style of code, the JVM is actually faster than C++. You also have to consider, that a lot of things you do in a C++ program to make it safer add up performance costs.
  - andrepd 6y ago
    >For certain style of code, the JVM is actually faster than C++. I find this very hard to believe.
    - _ph_ 6y ago
      It depends on the nature of the code. Static code is very fast in C++, but dynamic code is less so. Virtual method dispatch in C++ is comparatively slow. Hotspot can eliminate much of the cost by using runtime type information. Using runtime information generally is a way for Hotspot to perform optimizations, a static compiler cannot do, because they would be a bad tradeoff. Heap allocation in the JVM is as fast as stack allocation, this gives another boost vs. heap allocation in C++. And even GCing the youngest generation is basically cost free, as long as you don't have many surviving objects. I don't claim that Java is always faster than C++, that would be silly and there are plenty of Java programs in the wild which proves that it isn't. But there are quite some tasks at which Java is indeed faster.
      - sigotirandolas 6y ago
        In the general case, virtual dispatch has an overhead in both C++ and Java (which btw is only <5 machine instructions), but it's true that Java can sometimes eliminate it with runtime information, which C++ can not use. However, in my experience, using virtual dispatch is a relatively rare ocurrence in C++ (compared to the vast majority of method calls). On the other hand, on Java, most of _everything else_ is indirect and has overhead: All objects are allocated on the heap, primitives (int) are often objects (Integer) where they ought not to be, all objects have 16 bytes of overhead, etc. But the JVM will convert those heap allocations to stack allocations! And it will realize those Integers are used as int and remove the overhead! And it will realize you're not using the information on the header of every object! Perhaps in synthetic benchmarks, but in real programs, where there are an almost infinite amount of code paths, dumb 'data transfer' objects are common and things need to be modularized, the JVM is forced to assume the worst case can happen (even if you as an human can prove that it won't happen) and inhibit those optimizations. And now you have indirect accesses everywhere, memory overhead (=cache trashing) everywhere, the runtime can't vectorize that tight due to Integers, etc. In fact, I can't think of any domain where there is heavy competition and where high performance is a determining factor where Java has won to C/C++. In browsers, it certainly has not.

whatshisface 6y ago

It's a miracle that people who think like that use computers at all - after all, computers only reduce the time it takes to perform a clerical task or a calculation, they do not eliminate it.

TeMPOraL 6y ago
No, it's a reflection of a very important heuristic used in programming (that's arguably much more fundamental on a philosophical level, but correct words to categorize it escape me): the zero-one-many principle. If there's more than one something, you have to treat it as if there may be an unbounded number of something. You can only get it out of your head if you can put reliable bounds on it; the best if you can prove there's less than two of something.
- rictic 6y ago
  So if you could make your build 70% faster, philosophically it wouldn't matter, because you would still have a build step?
  - jfoutz 6y ago
    No, you sort of walked past their point. A thing can happen zero times (never). An example might be 1+1 =0. You could get really unlucky with cosmic rays or something, but really adding two registers, both containing 1, that result isn't going to be zero unless there's some sort of hardware failure. A thing can happen once. an example might be, you can delete a file once. There are ways to get unlucky, of corse, but once it's unlinked it's gone. if it happens more than once, you really should probably think about an unbounded number of times. now days, that sorta means 2^64 times. There will be bugs when something overflows int64, but I hope you get the gist. The parent comment is talking about invariants you can use in an algorithm. I think you might be worried about python vs C or something along those lines. Really, it should all work with a pencil and paper. Which is obviously going to be slower than pushing around electrons. But if you can find those invariants, 0-1-many, you can make a better algorithm. If you're stuck with a pencil it'll still make that faster.
- smitty1e 6y ago
  I think you're after Mathematical Induction. https://en.m.wikipedia.org/wiki/Mathematical_induction https://en.m.wikipedia.org/wiki/Mathematical_induction
- barrkel 6y ago
  It's a category error to apply the intuition to a risk calculation, though.
  - TeMPOraL 6y ago
    It's not a category error if you're doing an initial guess. Not to mention, particularly in information security, most of "risk calculation" is intuition and guesses, maaaybe sometimes plugged into a probabilistic framework with something resembling rigor.
    - barrkel 6y ago
      I'd say binary considerations are incompatible with risk calculations because no person and no procedure is perfect nor perfectly followed, nothing is completely bug free, etc. Some small part of a calculation might appear binary, but other terms usually dominate. Risk calculations are far broader than infosec and don't deserve the dismissiveness you seem to be casting towards them. Risk calculations are the core of business. Almost every decision a business makes is a risk calculation; every action has an opportunity cost if it isn't intrinsically risky, and actions with certainty are very rare. (For the avoidance of doubt, I believe that use of memory-unsafe languages should be avoided if reasonably possible, but there are still plenty of reasonable reasons to use C, C++ etc. instead.)
      - TeMPOraL 6y ago
        I'm not trying to dismiss risk calculations. I appreciate them and challenges involved, having worked on tools supporting risk calculations in corporate space. I feel this thread is getting out of hand. I initially replied to say why, in general, the kind of thinking that makes you unsatisfied with reductions but not eliminations of concerns, is common among programmers - because it's a sound heuristic. Reducing is good, but eliminating is better.
deleted 6y ago
[deleted]

fpoling 6y ago

Also memory-safe languages with GC allow for simpler API and design. That in turn gives more time to think on errors in logic.

erichocean 6y ago
They're simpler only if you could care less about performance. C and C++ are primarily used in situations where you do care about performance.
- saagarjha 6y ago
  They do well in those contexts. They’re used in other places too, but generally with poorer justification and results.
- _ph_ 6y ago
  Memory safety and performance are not a contradiction, they are widely independant. Yes, some strategies like GC induce an overhead. But in the age of multiprocessor machines, this overhead gets very much reduced by parallel collection. And practice has shown, in programs with a lot of dynamic memory allocation, garbage collected languages often perform even better. There are different approaches, like memory safety by the compiler as Rust does it. And with "performance" in mind, you shouldn't forget, that most large C/C++ programs tend to use libraries to provide some amount of safety, but those libraries are of course adding some overhead too. Finally, the less time you spend on questions of memory management, the more time you have to write an actually fast program.
  - dirtydroog 6y ago
    Sorry, this is hand wavy nonsense. One counter example, we switched from Cassandra (JVM) to Scylla (C++). It was a win in terms of both query latency and infrastructure costs as we required fewer machines to handle the same load. As for having more time to write a fast program... that's funny. If you want a fast program on something JVM based you're pretty much going to be spending the majority of your time writing things in a way where the GC plays as little role as possible.

johnr2 6y ago

> Switching from C++ to a language without memory safety issues while being just as fast Does that actually exist? (I mean in the general case, not just a few carefully chosen benchmarks).

_ph_ 6y ago
Yes, they do exist. The safety of Rust comes from the compiler (which takes its time), not from run-time checks. For certain style of code, the JVM is actually faster than C++. You also have to consider, that a lot of things you do in a C++ program to make it safer add up performance costs.
- andrepd 6y ago
  >For certain style of code, the JVM is actually faster than C++. I find this very hard to believe.
  - _ph_ 6y ago
    It depends on the nature of the code. Static code is very fast in C++, but dynamic code is less so. Virtual method dispatch in C++ is comparatively slow. Hotspot can eliminate much of the cost by using runtime type information. Using runtime information generally is a way for Hotspot to perform optimizations, a static compiler cannot do, because they would be a bad tradeoff. Heap allocation in the JVM is as fast as stack allocation, this gives another boost vs. heap allocation in C++. And even GCing the youngest generation is basically cost free, as long as you don't have many surviving objects. I don't claim that Java is always faster than C++, that would be silly and there are plenty of Java programs in the wild which proves that it isn't. But there are quite some tasks at which Java is indeed faster.
    - sigotirandolas 6y ago
      In the general case, virtual dispatch has an overhead in both C++ and Java (which btw is only <5 machine instructions), but it's true that Java can sometimes eliminate it with runtime information, which C++ can not use. However, in my experience, using virtual dispatch is a relatively rare ocurrence in C++ (compared to the vast majority of method calls). On the other hand, on Java, most of _everything else_ is indirect and has overhead: All objects are allocated on the heap, primitives (int) are often objects (Integer) where they ought not to be, all objects have 16 bytes of overhead, etc. But the JVM will convert those heap allocations to stack allocations! And it will realize those Integers are used as int and remove the overhead! And it will realize you're not using the information on the header of every object! Perhaps in synthetic benchmarks, but in real programs, where there are an almost infinite amount of code paths, dumb 'data transfer' objects are common and things need to be modularized, the JVM is forced to assume the worst case can happen (even if you as an human can prove that it won't happen) and inhibit those optimizations. And now you have indirect accesses everywhere, memory overhead (=cache trashing) everywhere, the runtime can't vectorize that tight due to Integers, etc. In fact, I can't think of any domain where there is heavy competition and where high performance is a determining factor where Java has won to C/C++. In browsers, it certainly has not.