7 ms·

Between how long it took us to get standard library hardening in C++ and seeing what ISO did to the co-founder of MPEG, I'm convinced ISO is fundamentally incap

Between how long it took us to get standard library hardening in C++ and seeing what ISO did to the co-founder of MPEG, I'm convinced ISO is fundamentally incapable of actually being responsive to stakeholders, specifically because of the insane national body vetocracy. For context, under Leonardo Chiariglione's stewardship, MPEG attempted to ship a royalty-free codec called Internet Video Coding (IVC) and it was immediately torpedoed by Samsung claiming ownership. In any sane environment you would amend the standard to remove the claimed technology, but ISO specifically does not allow you to do this. There is no obligation for an ISO participant to identify the patents being claimed unless they refuse to offer a license on FRAND terms. Ergo, Samsung just said "we own this and will sell licenses for money", and IVC was dead in the water as a standard[0]. Leonardo attempted to bring this to the attention of ISO, but the actual formal process for this was blocked by... you guessed it, a national body vetoing it. So the patent policy that prohibits ISO from distinguishing between royalty-free and royalty-bearing codecs stayed. Oh, and then they cut MPEG up into six pieces so Leonardo would have nothing to run anymore. C++ was an unusual language in that, for about 10-15 years, the only other competing systems programming language was C - another ISO standard, and the one C++ was originally based off of. The standard answer to "but I want memory safety" was "use a garbage collector"[1]. I distinctly remember hearing interviews with compiler developers talking about how adding even these basic features to C++ would be interminably painful, because you'd inevitably have to debug some deeply nested macro in a library somewhere, so shut up and just enjoy that we gave you Vector<T>.at(). The day Rust becomes an ISO standard is the day it becomes dead to me. [0] IVC was specifically designed to be inferior to the royalty-bearing H.265 standard, as Leonardo himself wanted to keep the royalty-free codecs second-tier. [1] To be clear, there was research into non-GC languages with memory safety - that's where Rust got its ideas from - but it was a very small niche until Mozilla put their feet down and gave legitimacy to something.

Xirdus 16d ago
Re: [1] - correct me if I'm wrong, but from what I remember, Rust originally did have GC and relied on it for safety, but as development went on, they added more static checks and eventually, very late into pre-alpha phase, realized they don't actually depend on GC anymore and can cut it out? As in, Rust wasn't part of the non-GC safety research at all, it just happened organically?
- deleted 16d ago
  [deleted]
- kmeisthax 16d ago
  Yes, but at this point the critical piece that made no-GC memory safety possible - linear types - had already been researched and known in the FP community. Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types". Okay, strictly speaking, Rust types are affine, not linear. Leaking Rust values is a safe operation. In a linear Rust the compiler would have to prove all values do not leak, but this would be incredibly difficult and probably make reference counting illegal.
  - Xirdus 16d ago
    Yeah, this makes sense. Although all this affine type stuff was also the basis for the C++ move semantics (although the resulting type system isn't affine at all, the mental model is very much that, with deleted copy constructors and all), which predates Rust project by at least a few years. So by the time Rust 1.0 rolled out, it wasn't a new concept at all even in system programming circles. The actually innovative thing about Rust is how they made object lifetimes into a H-M-esque type system and used this 50 year old algorithm to detect dangling pointers at compile time.
    - steveklabnik 16d ago
      To further this, "destructive move" as C++ calls it almost happened, but ended up not. So it almost had it the same way as Rust too.
      - kmeisthax 16d ago
        The funny thing is, Rust doesn't quite have a destructive move either. Or, at the very least, it's not exposed to the type system. The Drop trait that tells you if a value of a type T was destroyed can only give you a &mut T to it. There's no type to represent a value you own stored in memory you don't. So we have the funny situation where if you implement Drop, you can't take values out of the thing that got dropped.

Xirdus 16d ago

Re: [1] - correct me if I'm wrong, but from what I remember, Rust originally did have GC and relied on it for safety, but as development went on, they added more static checks and eventually, very late into pre-alpha phase, realized they don't actually depend on GC anymore and can cut it out? As in, Rust wasn't part of the non-GC safety research at all, it just happened organically?

deleted 16d ago
[deleted]
kmeisthax 16d ago
Yes, but at this point the critical piece that made no-GC memory safety possible - linear types - had already been researched and known in the FP community. Rust's critical invention was "what if we modeled heap ownership and borrowing with linear types". Okay, strictly speaking, Rust types are affine, not linear. Leaking Rust values is a safe operation. In a linear Rust the compiler would have to prove all values do not leak, but this would be incredibly difficult and probably make reference counting illegal.
- Xirdus 16d ago
  Yeah, this makes sense. Although all this affine type stuff was also the basis for the C++ move semantics (although the resulting type system isn't affine at all, the mental model is very much that, with deleted copy constructors and all), which predates Rust project by at least a few years. So by the time Rust 1.0 rolled out, it wasn't a new concept at all even in system programming circles. The actually innovative thing about Rust is how they made object lifetimes into a H-M-esque type system and used this 50 year old algorithm to detect dangling pointers at compile time.
  - steveklabnik 16d ago
    To further this, "destructive move" as C++ calls it almost happened, but ended up not. So it almost had it the same way as Rust too.
    - kmeisthax 16d ago
      The funny thing is, Rust doesn't quite have a destructive move either. Or, at the very least, it's not exposed to the type system. The Drop trait that tells you if a value of a type T was destroyed can only give you a &mut T to it. There's no type to represent a value you own stored in memory you don't. So we have the funny situation where if you implement Drop, you can't take values out of the thing that got dropped.