Aria Beingessner

> there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11

ABI breaks are everywhere in C++... consider a class

class foo {
public:
foo();
void do_something();
private:
int x;
}

and an impl in the dynamic library:

#include "foo.h"
foo::foo() {
this->x = 0;
}
void foo::do_something() { std::cout << this->x << std::endl; }

You build a libfoo.so and clients use it, calling `foo f; f.do_something();`, it calls your library and it's great.

But as soon as you ship a new version that adds a new field to foo (still source-code compatible):

class foo {
public:
foo();
void do_something();
private:
int x;
int y;
};

With a new function body in your shared object:

void foo::do_something() { std::cout << this->x << this->y << std::endl; }

You're hosed. Clients have to recompile, or they get:

$ ./main
0, 0
*** stack smashing detected ***: terminated
[1] 2625391 IOT instruction (core dumped) ./main

Because the size information for an instance of foo is only known at compile-time, so the clients aren't allocating enough space on the stack for it (ditto the heap if you're using `new foo();`)

The way around this is awkward and involves the pimpl pattern and moving all your constructors out-of-line... but you also need to freeze all virtual methods (even just adding a new one breaks ABI), and avoid using any template-heavy std:: types (not even std::string), since those…

I’m not sure whether those toolkits abstracted over native GUI interfaces or whether they attempted to recreate a native look and feel or whether they attempted to provide their own look and feel across platforms, but in any case the problem isn’t languages and compilers, it’s that the expectations for a GUI toolkit are dramatically greater now than then. Here are a few things that are (I think) expected from GUI toolkits today, but not 30 years ago:

* Hardware acceleration (in particular abstracting over metal, opengl, direct x, vulkan, etc)

* More complex layouts

* Animations

* Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/

* Accessibility

And if you want to emulate a native experience, getting keyboard shortcuts, focus behavior, and a billion other details correct is nearly impossible.

And by the way, today we have web engines that take care of most of these things for free and a huge pool of people who know how to build for them, so it’s often easier to leverage that capability than to essentially reinvent them.

And if people can contain their knee-jerk anti-electron reaction for a moment, I think that’s a pretty reasonable approach. I would really like to see something like an unlocked ChromeOS where the browser is the native interface, but unlike electron, we don’t ship a web browser with each app. Especially as webasm takes form, I could see this as a more compelling solution for cross-platform…

This is on point. I work on small-ish embedded Linux systems and I would really like to use Rust there, but a single Rust binary takes up enough space for 10 C programs, so it's prohibitive. You can dynamically link your libraries (especially since these systems are usually built as full images, so ABI compatibility does not really matter) and it helps a little, but nowhere close to the order of magnitude you need.

Alas, there is little interest in/awareness of the middle ground between the no_std world and the "size doesn't matter" world in the Rust community right now. I've asked a bunch of people for pointers as to where to start working towards supporting those cases but I mainly got shrugs. There were attempts at more lightweight stdlibs and so on, but they all seem to have fizzled out.

I wonder how much of this is inherent in the language design. Rust heavily leans on monomorphization, so as a first approximation, you will always generate more code (before maybe optimizing that away again). Famously, the Swift people went to great lengths to avoid these problems: https://faultlore.com/blah/swift-abi/. But while running Swift on Linux is possible, this is even more niche.

Vastly oversimplified, that'd be because fonts are individual strokes of varying width and free layout that get rendered on a array of pixels with fixed sizes and fixed layout.

Resampling comes with some aliasing/information loss. Font rendering is about picking which losses you're willing to take.

And you can't just "ask designers" because the trade-offs are different based on resolution and pixel layout. And they change as you scale the font up and down. ("Font hinting" tries to fix issues with that scaling. It's got its own downsides)

And because it's fun, there's also a perception component, where different people can just look at the same font and process it differently.

Font rendering is the art of making compromises that offend the least amount of people. A good starting point on the subject: "Text rendering hates you" - https://faultlore.com/blah/text-hates-you/

(I could swear there was also a great post by Raph Levien, but I can't find it)

> - Assume our language has a specification, even if it's entirely in your head

It does not, and at the current pace, it might never have a spec.

The reason there is no spec - not even an hypothetical spec in my head - is that the exact semantics of Rust has not been settled.

With the constraints the Rust project are operating with, the only way forward I can think of is following the ideas laid out in post

https://faultlore.com/blah/tower-of-weakenings/

With the understanding that you can have multiple specs if one is entirely more permissive than the other (and as such, programmers must conform to the least permissive spec, that is, the spec that allows the smallest number of things)

But the problem is, Rust doesn't even have this least permissive spec. Or any other.

I think if AI can help us modernize the current state of hardware verification, I think that would be an enormous boon to the tech industry.

Server class CPUs and GPUs are littered with side channels which are very difficult to “close”, even in hardened cloud VMs.

We haven’t verified “frontier performance” hardware down to the logic gate in quite some time. Prof. Margaret Martinosi’s lab and her students have spent quite some time on this challenge, and i am excited to see better, safer memory models oyt in the wild.

A lot of the same big ideas used in hardware are making their way into the software later too, see https://faultlore.com/blah/tower-of-weakenings/