saynsedit

I.e. 50% of sanders' voters were women. You'll get similar proportional percentages of minorities.

Simpson's paradox creates the perception that sanders' voters are composed of mostly white males. It's untrue.

Gains can be made by "inter-bytecode" optimization in the same vein as inter-procedural optimization.

If you can prove more assumptions about types between the execution of sequential opcodes, you can remove more type checks and reduce the amount of code that must be run and make it faster.

E.g.:

    01: x = a + b
    02: y = x + c

The larger the sequence of opcodes you are optimizing over, the better gains you can make.

Right now I think Pyston uses a traditional inline-cache method. This only works for repeated executions. The code must eagerly fill the inline cache of each opcode to get the speed I'm talking about.

Another reason Python's runtime is slow is because there is no such thing as undefined behavior and programming errors are always checked against. E.g. The sqrt() function always checks if its argument is >= 0, even though it's programming error to use it incorrectly and should never happen. This can't be fixed by a compiler project, it's a problem at the language level.

Being LLVM based, I think Pyston has its greatest potential for success as an ahead-of-time mypy compiler (with type information statically available). IMO leave the JITing to PyPy.

Also this dependent name behavior of static_assert seems to be a precedent for always checking static_assert in constexpr if.

Maybe you've seen this already: http://nominolo.blogspot.co.uk/2012/07/implementing-fast-int... (notice the part about portability)

  template<class T>
  class foo;

  template<>
  class foo<int> {
    static_assert(false, "bad");
  };

  template<>
  class foo<float> {};

  template<class T>
  foo<T> foo_fn(T v) {
    if constexpr (std::is_same<T, int>::value) {
      return foo<int>{};
    }
    else if constexpr (std::is_same<T, float>::value) {
      return foo<float>{};
    }
    else {
      return foo<T>{};
    }
  }
  foo_fn(1.0); // <-- does not trigger static assert
  foo_fn(1); // <-- triggers static assert

Yeah, having foreign intelligence agencies interfere in sovereign elections does suck.

As for your "kernel attack surface is lowered" argument, it's incredibly silly. If read() and write() ever had a vulnerability we have much bigger problems than binaries in a SECCOMP. It's like saying SHA256 isn't secure because there is technically a risk of collision.

Determinism and robustness aren't valid, they can use checksums to verify data coming out of the SECCOMP container. Same effect, much less effort.

And for your argument against de facto security: security reasoning isn't binary. It's a risk based assessment. Nothing is 100% secure and context matters. Binary thinking and dogma are incredibly dangerous. Spouting "Rust is secure" is dogma, it's not true. Rust is "99%" secure, unknown unknowns will always be out there.

In this case, context is important. My point isn't that c-brotli is as secure as rust-brotli. My point is that using c-brotli doesn't introduce any significant new security risk on the client-side given that there are lots of other c-based libraries already interpreting file data. Given that context, reimplementing brotli in rust for the purposes of increased security only marginally accomplishes its goal. It's like optimizing the part of your program that takes the least time, lots of effort for almost no gain.

On the server side, there's no gain at all to porting c-brotli to rust since you can already use SECCOMP and checksums. It's just wasted effort.

Am I saying there is no valid reason to port things to Rust? No. I'm saying it's invalid to port a library to rust for security reasons if you already have effective means of mitigating binary attacks, I.e. SECCOMP and checksums.

This "future changes" logic would apply better if this were an upstream library that were expected to change often enough to offset the upfront cost of porting an entire library.

I'm sorry but the Rust rationale just isn't there. Porting to Rust is a strictly less efficient way of accomplishing the same exact goal.

Now, writing a new library in rust, that's a different story and actually is reasonable.

If they were going to run the whole thing in a SECCOMP container anyway, there is little damage a compromised C library could do.

If reasoning about uninitialized memory would take a review of the entire brotli code base, didn't the rust port require that anyway? (speaking as someone who has done a couple of cross-language rewrites)

The scale is literally 8 billion.

Btw, in case you didn't notice, I didn't like your rhetoric and I ignored all the logic in your post because it came across as preachy, or whatever. Next time be less preachy, or whatever, that will help, maybe?