Hacker News Reader

Comment by namKS | Hacker News Reader

Ok, so CPython is broken by default and by design. Yes Sir, understood sir, no exceptions, sir!

Sure. Do you have any arguments why it isn't broken and go against the arguments linked in the related HN discussion? Is CPython in some way immune to overflows, use-after-free, double freeing, and so on? How much of CPython is actually implemented in C, and how much in itself and/or in Python?

Why should we care about arguments in a random HN discussion? We should care about arguments from people who have done substantial work.

Totals grouped by language (dominant language first):

  python:      578880 (54.33%)
  ansic:       475310 (44.61%)
  sh:            4073 (0.38%)
  cpp:           3847 (0.36%)
  asm:           1486 (0.14%)
  objc:           761 (0.07%)
  lisp:           502 (0.05%)
  pascal:         353 (0.03%)
  xml:            308 (0.03%)
  csh:             21 (0.00%)

Most of pure Python is in the stdlib.

> We should care about arguments from people who have done substantial work.

OK, we can drop the HN comments. Since Stefan Hajnoczi is a substantial QEMU contributor, how would you respond to the arguments linked in http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c...?

is any rust code some way immune to unsafe blocks?

That's a little different. If you're running a C linter that statically guarantees safety, then it's comparable; otherwise, you're comparing mostly Safe Rust (with some Unsafe Rust in it) to Unsafe C.

Safe Rust is automatically immune to lots of these issues. Unsafe Rust isn't, but all of C is unsafe (unless you're using a safety-enforcing linter that only gives you access to a subset of the language).

Reply on news.ycombinator.com