Linux kernel, X server, web browsers all seriously violate the Unix philosophy.

And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.

I've noticed a trend that the same people who complain systemd does too much also have a strong affinity for the X server... with it's built in print server!

Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.

That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.

That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.

My point wasn't that pulseaudio is flawless, it's just that it has a much worse name than it deserves.

Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code.

* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.

So one audio server managed to provide a shim for another audio server, great.

But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.

My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.

latency and throughput (when with Java the system is crying for more memory while it's chilling in the Rust case)

You can tune java runtime in many ways, achieving impressive throughput/latency for your type of workload.

Next to none of them will get you nearly as good cold start times as of native app, if using free java.

There was GraalVM and its ecosystem which included Java Native Image - first thing I’d evaluate if thought about non-server side, performant Java application.

But it all had been sadly swept away by Oracle from free tier.

I use GraalVM and Native Image now and while the project --a small CLI tool-- is tiny (2kLOC with mainly AWS-SDK deps) the compile times are huge (~3 minutes), the OS-dependencies many (so much I use a build container to ease the burden of installing all) and the resulting binary is huge (~60MB).

But then it distributes as one binary and starts in milliseconds.

Rust would have been a better fit (cargo-and-done, smaller binary, quicker to compile); but I wanted to use Kotlin as we use in all other projects.

It hasn't been swept away by Oracle, far from it. It's development is just no longer coupled to the OpenJDK release cycle, which benefits both projects.

What's the latency difference between a long running process issuing a network call in Java vs rust? This is such a short time that it is completely overshadowed by noise (OS doing something else, what other software is running etc)

As for throughput: you have 1-2 requests going at a time, the next one waiting for the reply. What throughput are we talking about?

That's like speeding to the post office and expecting your letter to get to the recipient faster.

you seem to specifically aim at the current example, but mine wasn't

Anyways, consider how higher memory usage can affect the systems performance dramatically once the system needs to start swapping memory to disk signficantly

If you cannot write a simple Java agent without consuming so much RAM that your system is swapping then that really says more about the developer than anything.

Java is used in plenty of embedded systems and other memory constrained environments. Yes, it’s not going to perform well compared with Rust, but that doesn’t mean it’s an Electron-equivalent bloated clusterfuck of an ecosystem that’s going to eat all your system resources.

> so much

1) the agent is probably not the only thing running on the system, so more is just worse generally

2) I am fine if a developer needs Rust or similar to write a resource efficient app. I wonder what the developer could achieve when he put the optimization effort into the Rust app instead.

My point is that Java isn’t going to be the application that sends your machine into swap hell.

People are so narrow minded about programming on this forum. They talk as if only Rust fills the void between unsafe C and node.js behemoths. But the reality is there are a plethora of other good languages out there too.

I can't put Java into good languages category at least for how it allows null to be everywhere.

Of course, what would be a point of talking about an overly specific statement that has no relevance here?

> That's like speeding to the post office and expecting your letter to get to the recipient faster.

I mean, the post office is not a magic box. Actual people will take your letter somewhere, sometimes batching sends. So running to the post office might actually get your letter in an earlier batch, same as ordering on amazon or your online supermarket in the morning or in the evening might change the delivery time.

Pedantic, I know, but interesting example.

> let me add a div so I have a place for my CSS class

As opposed to what exactly? HTML doesn't let you lay out stuff properly without at least some structural divs that have no meaning.

If we have the proper aria properties for example, why does it really matter if I have extra divs (which is, again, irrespective of tailwind)

I can do a lot of layout without divs. Adding aria to divs is an anti-pattern and likely a worse experience than semantic elements.

You might need some extra divs for layout sure. But I guarantee less than most people are using if they markup their content first.

Remember divs mean nothing. So the opening example on the Tailwind website is the accessible equivalent of “blah blah blah”.

Even the root comment mentions the exact same failure mode:

> If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first).

This is IMO not worse than vanilla CSS, and it's simply the only way to have customizable layouting in HTML.

What are the cases when you have to use divs or spans solely for design? When I did such things, it’s only because I was sloppy, or didn’t know back then how to do it without it. But maybe, there are cases, I’ve just never encountered them yet.

"Solving" is one thing, adaption is another.

> look and feel exactly the same as every other widget in the system

Which is what? Windows natively has like 4 official looks. You can click around the 2 (!) settings programs and pop open windows for basically every framework windows has created (and deprecated) in the last 2 decades.

I don't think that's a useful mental model for software in general.

There are software that works like this (e.g. a website's unrelated pages and their logic), but in general composing simple functions can result in vastly non-proportional complexity. (The usual example is having a simple loop, and a simple conditional, where you can easily encode Goldbach or Collatz)

E.g. you write a runtime with a garbage collector and a JIT compiler. What is your map? You can't really zoom in on the district for the GC, because on every other street there you have a portal opening to another street on the JIT district, which have portals to the ISS where you don't even have gravity.

And if you think this might be a contrived example and not everyone is writing JIT-ted runtimes, something like a banking app with special logging requirements (cross cutting concerns) sits somewhere between these two extremes.

The GC shouldn't care about all the code it is collecting. I collects garbage, it doesn't care if the garbage is a intermediate value from your tax calculations, or the the previous state image from your UI - either way it is garbage and it is gone. Now in a few cases details of garbage collection matter by enough that it is worth something more invasive for some reason, but the vast majority of code shouldn't care about the other areas.

When on a tiny project it doesn't matter. However when you have millions of lines of code you have to trust that your code works in isolation without knowing the details.

I don't get your comment. The GC is part of the runtime, to it user code is data. But the JIT compiler and other internal details of the runtime are its code, and there are very real cross-cutting concerns, like the JIT compilers output should take into account what memory representation the GC expects, where are barriers, when one is run etc. So I'm talking about a project such as the JVM.

> have millions of lines of code you have to trust that your code works in isolation without knowing the details.

More like hope. This is where good design and architecture helps, as well as strong invariants held up by the language. But given that most applications can't really escape global state (not even internally, let alone external state like the file system), you can never really know that your code will work the way you expect it to - that is, it's not trivially composable to any depth.

I don't work in that area, but I strongly suspect that they do their best to confine the interactions to small places if that is possible. Maybe not though.

They absolutely do their best, but this is not possible in the general case. And as I said, it's also true to a smaller degree for banking and other software as well, but is not even software-specific. A plane also can't be engineered layer-by-layer, component-by-component - there has to be an oversight of the whole, otherwise it won't fly.