After reading

https://hypermedia.systems/

I came to the conclusion that the best frontend is no frontend.

Building UI in HTMX is such a breath of fresh air. I hope it kills the "React" style big complicated SPAs. Its so easy to develop in, its so fast to run, so fast to load.

That's basically the meme, right: You rail against corporations and yet you work for one. Curious.

Anyway in general, corporations are sticky. They save resources through scale and collaboration. Famously this is a problem for free market true believers because if you believe that the market is the most efficient mean of organizing people then you would expect firms to operate internally as free markets (or disappear). There is a whole body of work about it,

https://en.wikipedia.org/wiki/Theory_of_the_firm

In practice you can't just become your own boss and compete against firms.

Most people in fact do not work for corporations. But small companies rarely get into the news do they?

I don't have the link to the US census bureau in front of me, but I think as of 2018 more than 50% of employees worked for firms with >500 employees.

And, of course, there's nothing preventing a small/medium business from incorporating, either. "Corporation means big, small business is a different thing" is common shorthand but not actually how it goes.

The vast majority of people working for small companies do not earn much. A few doctor firms, and high end legal/engineering firms maybe, but most employees of smaller businesses lose out on total comp to big businesses, and government.

You tell Claude to review it and if it breaks something you blame Claude. No one can get mad at you for it because they don't want to look like luddites.

It's the style of "blazing fast library made with :heart: in rust :crab:" that was popular in github README.md. My guess is that because the models are told to use md they overfit to the style of md documents too.

True but that requires another vulnerability.

It's security in depth. You build your server in a way that it doesn't allow remote code execution, and then you run it with an unprivileged user so that if it does allow it, the consequences are limited. And if running arbitrary code is a feature (you are github or whatever) you use VMs.

Java has Security Managers. I've never seen anyone use it in practice though, so it probably doesn't work very well.

I think it would be hard to get any kind of usable capability system without algebraic effects like those of Koka or Scala libraries.

EDIT: Apparently Security Managers are deprecated and slated for removal.

From a purely aesthetic point of view, this is what I enjoy so much about C and Fortran. You look up a Rust crate and it hasn't been touched in 5 years. That means it's unmaintained and unusable, don't add it to your project or you will have a bad time.

You find a C or fortran library that hasn't been touched in 20 years and (sometimes) it's just because it's complete and there hasn't been any reason to update any parts of it. You can just add it to your project and it will build and be usable immediately. I wish we had more of those.

Clojure and Go are similar to this from my experience.

JVM is fast for certain use cases but not for all use cases. It loads slowly, takes a while to warm up, generally needs a lot of memory and the runtime is large and idiosyncratic. You don't see lots of shared libraries, terminal applications or embedded programs written in Java, even though they are all technically possible.

You don't even need to go all V8, you could just build something like LuaJIT and get most of the way there. LuaJIT is like 10k LOCs and V8 is 3M LOC.

The real reason is that it is a deliberate choice by the CPython project to prefer extensibility and maintainability to performance. The result is that python is a much more hackable language, with much better C interop than V8 or JVM.

It's interesting that branches, which is a marquee feature of git, became less important at the same time as git ate all the other vcs. Outside of OS projects, almost all development is trunk based with continuous releases.

Maybe branching was an important reason to adopt git but now we'd probably be ok with a vcs that doesn't even support them.

Trunk based development is still a hotly debated topic. I personally prefer branches at this point in time, trunk based development has caused me more trouble than it's claimed worth in the past, BUT that could be a me limitation rather than a limitation of the style

Not sure if it's true. I mean, I do agree with the core of it, but how do you even do PRs and resolve conflicts, if there are no branches and a developer cannot efficiently update his code against the last (remote) version of master branch?

Trunk based development has every developer in the company committing straight to main - no PRs, supposedly no merge conflicts (but reality is that main moves fast and if someone else is working in the same files as someone else, there will be merge conflicts)

A middle ground is small PRs where people are constantly rebasing to the tip of main to keep conflicts to a minimum