josephg

> Nobody I ever worked with ever said anything even remotely close to that first paragraph.

No, they’re correct. Many people in the web dev community spent a couple of decades there obsessed with being beginner friendly. For example, “Anyone can learn to code”. We pushed back against anything perceived as gate keeping. There was general assembly and other coding bootcamps, to teach beginners web dev. And a million beginner videos. Web dev events at the time were full of beginners. I remember a show of hands once at SydJS. 70% of people in the room had been programming for a year or less. I stopped going, because speakers started catering to the audience.

Other areas of programming aren’t like this. Nobody runs 12 week coding bootcamps to teach complete beginners to build operating systems. It’s accepted you shouldn’t roll your own crypto. And we tell beginners to use Postgres, not roll their own database.

I’m not saying it’s a good or a bad thing. But it was definitely a thing.

> based on a personal belief that everyone around you is incompetent and incapable of critical reasoning.

This is all news to me. I don’t think any of that. Do you make a habit of writing fanfic about other people? You also seem upset that I used word “everyone”. I thought my exaggeration was obvious. How embarrassing for us both.

If you want to make any technical arguments in support of react, I’m all ears. The only argument I can find in your comment is that react is popular right now. But that doesn’t mean react can’t be improved upon. Jquery was once that popular. Then react displaced it, by being better. Soon react will be displaced in turn, by a library which addresses react’s flaws. I can’t wait.

> most companies were indeed using it wrong

If everyone is using react wrong, react has a design flaw. Other frameworks aren't slow by default.

I should probably be more balanced when criticising react. React moved the state of the art forward when it came out. Compared to the other options we had at the time, it was excellent. But it's not better now. At least not for technical reasons.

> Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?

Virtual dom diffing is pure overhead. It increases the JS bundle size (react is big). Vdom diffing is really slow. And it's simply not necessary.

I agree that if you make heavy use of comparator functions, react apps can feel ok to use. But most sites don't do that. Look at the new reddit site. Insanely slow and insanely inefficient. They've improved it a lot since the new design landed. But it's still 19mb of javascript or something, and much slower than it should be. Maybe reddit is only slow because they're holding react wrong. But if everyone holds react wrong, it's react's fault.

If you don't like the asthetics of svelte, check out SolidJS. Solid is aesthetically almost identical to react. Solid - like react - only needs compilation if you're using jsx. The difference between solid and react is that solid only executes component functions once. Reactivity is implemented via fine-grained signals. Solidjs apps perform better, because there's no vdom. The default way to use solid is already fast.

> if something was truly dramatically better, then I think it would have a fair shake at beating out React.

Eh. Lots of old technologies are still in use. Most software engineers don't enjoy learning new frameworks every few years. And react still works fine, even if there are other options today. I think solid and svelte are better, but they might not be better enough to displace react for the average web developer.

If you like react, give solidjs a try. It's essentially "react with signals", which I find to be a significant improvement. You get much smaller JS bundles, better performance and better state management. All while keeping a lot of the best parts of react's design philosophy. It's great.

> React is a relatively well-designed library that isn't really that bloated.

I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:

- They have excellent documentation. And have, from day 1.

- They produced videos, sample projects, and all sorts of "getting started" documentation.

- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.

The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)

By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.

Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.

There’s probably an npm library for that. Not all heroes wear capes.

Programming jobs differ wildly though. Working as a solutions architect is different from working at a startup, or a big corporate, or a company making video games, or a big tech company like google.

If you love programming but hate working at your current programming job, the problem might be the company.

One of the big differences using the better models is that you don’t need to hold their hand anywhere near as much. Fable is crazy expensive, but I’ve seen it just one-shot some remarkably complex projects. The code it produces is much better, too.

Code reviews also work better in sub agents because the reviewer agent didn’t write the code being reviewed.

Sure, but the point is to try and fix that.

Our software is already malleable in a bunch of ways: APIs, integrations, extensions, plugins and compatible formats (eg lots of programs can edit a .md file). But all of this stuff is special-cased. Every program that wants to read a .psd has to write its own - probably buggy - parser. I can't just take the data in application A as JSON - at least not without claude. And I can't connect applications A and B and have them bidirectionally sync except with hacky scripts which will break in lots of situations.

I love the idea of fixing that.

Yeah. Sites like GitHub pay a lot of money every month for servers. At scale, a bit of performance work can save you millions on your bills. And make your site run faster for users at the same time.

To be really clear, the performance of GitHub’s website has basically always been terrible. I don’t know why. It has bothered be forever. And it’s weird - GitHub doesn’t actually render much content. But it often takes seconds to load that tiny bit of content. I often clone entire repos locally rather than browse them on GitHub just so I don’t have to wait for their webpage.

To continue the comparison, cyberpunk can render night city in 16ms. Which makes me embarassed for GitHub that they can’t render a list of files and a static markdown readme in under a second.

If your job makes you hate programming, why do you stay there? Sounds miserable.

Sometimes you gotta do things that others don’t value highly. A long career needs you to act with good judgment. Even - sometimes - when the optics are bad.

Exactly. The windows operating system isn’t just the nt kernel. It’s also all the UI that comes out of the box, that sits on top of that kernel. What is iOS? An operating system. What kind of software is springboard? It’s part of iOS. Part of the operating system.

An operating system is a lot more than just the kernel.

Me too! Though I never learned how to use functions (subroutines) until I picked up C from a book later on. I still have dozens of programs I wrote back in the day in qbasic, largely based off the examples in the help system.

There were a lot of books written back then on programming. My local book shops had a section dedicated to computer programming - including all the popular programming languages of the day like C, C++, Basic (and eventually Visual Basic), Java and so on. The books were technical and specific, but they were incredibly easy to find. And back in those days book shops were everywhere.

I learned C, Java, JavaScript and Obj-C from books over the years. Those books were honestly much better resources for a beginner programmer than most online resources are today.

You can also pull up a repl in any desktop web browser by pressing F12.

> that's a different thing.

I hear what you’re saying, but we don’t have a word for that different thing. OS means the kernel. But OS also means the entire distribution - all of macOS, all of iOS, all of windows, Ubuntu, Android, etc.

Until we have a standard word for the ui “shell” that comes out of the box with the OS distribution, people - including me - are gonna call (and think of it) as the OS. Or part of the os. Or something like that.

It’s not a rust thing. Custom markup is usually implemented in rust frameworks using macros. If mixing macros and logic becomes a problem, we can change how the macros are implemented.

> But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.

This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.

> Consider the most common task the SecurityManager was deployed for: stopping plugins calling System.exit() by accident. One might say, the right to exit the process should be an object capability.

I don't think this is a great example. Caps are generally for resources outside of your program or module scope. A program already has the capability to exit, so that wouldn't be something you would pass in from outside of the program.

> Java programs start at main() and it doesn't receive an object.

I agree that retrofitting caps into an existing language like java would be difficult and inconvenient. Passing a "god cap" to main() is the easy part! The hard part is just how much of the standard library implicitly depends on ambient authority. I've thought about doing this in rust, and concluded that I'd probably need to fork rust's std library.

> You'd get an explosion of types.

I've never heard of that stopping java programmers before.

The way SeL4 handles this is to have a generic call() interface for capabilities. It's very simple, and it would work fine in this example.

> Why would you want all HTTP requests to flow through a single capability object?

Capabilities are a combination of resource + access rights over that resource. If I wanted to give a module access to a REST endpoint, I'd make a cap representing that endpoint. The resource is the URL base (eg "example.com/foo/bar"). And I'd also specify access rights (eg only HEAD+GET, or HEAD+GET+POST or whatever makes sense). Then pass that object around to any modules which need access. I'd even keep the URL prefix private in the capability object. The capability object would only expose methods for http_get(), http_head(), http_post() and so on. This design would be more or less impossible to misuse. And it would be super handy for unit testing and dev environments.

It's not "one capability for everything" and it's not "a million fine-grained access rights". You want one cap per semantic resource, just like one fd per open file. If you want to refine the granted permissions, just reimplement the same interface with a different implementation of http_get() and friends. (Or, simpler: just wrap your existing RESTEndpoint class with another class which adds your extra checks).

> except then there's a weird ioctl escape hatch that isn't properly typed,

This is a flaw of the unix syscall API. In comparison, SeL4 only has 9 syscalls (plus 2 for debugging). The syscalls just let you call capabilities, and have your capabilities be called by other processes. And yield(). That's all the syscalls on sel4.

Because everything runs through that same API, it's trivial to stub out or replace capabilities provided by different components. Eg, any program can reimplement the filesystem API if it wants to. No need for FUSE, or special loopback mounting or anything like that. Because the filesystem is just a userland process which doesn't have access to the kernel's memory, there are no ioctls that you can accidentally forget to sandbox. The only special thing about the filesystem is that it holds a capability to do raw IO on the block device. (And that cap, in turn, is provided by another userland process.)

> My guess is you'd need a lot of language features to hide the explicit object capabilities away for ergonomic reasons

Yeah, I think that's our big disagreement. You seem to think that hiding object capabilities would be a necessary design choice. I think using caps directly would be much more ergonomic than a SecurityManager style design because custom caps can just be implemented in normal code. And caps are better because they encapsulate a resource, not just access control rights.

> still laughably behind by nearly 20%

20% slower than the M5 is still a great result. I'm still using an M1 macbook pro, and it's more than fast enough for editing film, browsing the internet and writing code.

I've always called it "tvOS" or "MovieOS". Like, "oh, a lot of flashing lights on tvos today!"

It would be a fun exercise trying to recreate a lot of the screens from movies and tv shows. "This is unix! I know this!"

> I am confident a human and about 5 minutes with chrome debugger would yield better results

It really depends which human. I've worked with very few engineers who were good at this sort of optimisation work. A depressingly large percentage of people who make websites for a living don't really understand how http requests are really processed, or how to read and use the chrome profiler and benchmarking tools.

Claude isn't as good at optimisation work as someone who really knows what they're doing and goes deep on a problem. But I'm optimistic that it will help plug a capability gap in teams which don't have this sort of expertise on hand.

(That said, the chance that people actually learn this stuff is going to also go down if people get used to outsourcing this work to claude.)

Put what on paper? I don’t understand your comment.

I don’t expect every piece of software written to be proven correct like SeL4. But I don’t think we don’t need to do that to get big improvements in the security of a lot of systems. Honestly the biggest insight I take from sel4 is that we can get improvements in security by breaking up a large program into isolated pieces. Give each piece as few permissions as possible, so a compromise of one part doesn’t lead to a whole system compromise. And give them a way to talk. This has big benefits for reliability - since you can fail and restart individual processes. And it has benefits for security, since a system compromise should require an attack of multiple systems simultaneously. And it has benefits for debuggability, since you can add tracing at the comms layer or isolate modules for testing.

Wasm does this. Erlang does this. SeL4 does this. Chrome is built this way. The windows driver model is moving this way. And so on. You want a solid core to build around - which is what SeL4 and beam try to be. Then it’s up to us to use those primitives and build good software. Combine that with a memory safe language (rust, go, c#, etc) to protect against buffer overruns and use after frees. And a picture starts to form of how you can build software that is a lot more secure by default.

I don’t think perfect security is worth the cost for many companies. But so many security leaks happen because of amateur hour somewhere. Bugs happen - I get that. But a single bug in a C++ program shouldn’t immediately lead to RCE with system level privileges. This stuff isn’t rocket science.

If restaurants can't make sure their food is safe to eat, they shouldn't be allowed to be in business.

If builders can't build houses to code, and the buildings fall down, they shouldn't be allowed to stay in business.

If civil engineers build bridges that fail. Or doctors hurt patients. Or police officers shoot innocent people, they shouldn't keep their jobs.

Software engineers are no different. If you collect my user data and it's at high risk of leaking on the dark web, either clean up your act or close shop.

> Generally it also takes consulting with maths experts who have spent their life studying cryptography and as such command a decent wage.

It doesn't take a maths degree to look out for SQL injection attacks or to audit software & write up a risk assessment.

I'd love to see real stats on this.

We know about many famous cases of leaks - like the USSR stealing notes from the manhatten project. But I bet there are thousands of secrets which remain secret. We just don't actually know about them, because, y'know, they're kept secret.

What seems obvious to you doesn't seem obvious to me. I'm not a malicious or incompetent enemy. But you will need to explain your perspective for me to understand it.