vacuity

> Has anyone proposed an actual better way of solving these kinds of problems? No.

This is the heart of the matter. Nothing is good or bad in a vacuum, but when two things (say, outcomes) can be compared, distintions can be drawn. Noticing flaws in the present can't be contrasted with simple models of "the better solution"; this is comparing apples to oranges. Address both the good and the bad of the present, including the days where nothing noteworthy happens and therefore below the awareness of most people, and the good and the bad of an elaborated counterpart.

I did say that simple doesn't mean easy. I don't know how to judge whether something is many or few without a fixed norm, nor how to measure it without reference to the environment it exists within. Simplicity does not mean having so little to the point of unease.

"Everything should be as simple as possible, but not simpler"

- Einstein (probably[0])

Brainfuck is a simple language. A Brainfuck program written to parity with an existing non-Brainfuck program is likely complex. A musical note is simple, but a musical score may be highly complex.

I think your objections are misplaced.

[0] https://quoteinvestigator.com/2011/05/13/einstein-simple/

From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).

Never religiously cling to statements such as "strictly separate presentation and content". These are all just guidelines to suggest simpler solutions, not hard rules that guarantee simplicity. They will sometimes be excepted.

There are such things as components, which compose strictly by interfaces and externalize separate details, but it is up to the programmers to realize them in their programs. Also, simplicity is a global property of a system. Nothing can be judged on simplicity in a vacuum.

All that being said, I don't have experience in web or UI in particular. Seems like logic is moreso a local thing, whereas presentation is moreso global (but may consider locally defined advice). State can be local or global.

I believe we can do fairly well in addressing people in groups. People are irrational, but the probability distribution of "things we say" against "what people will think and do" can be modulated for the better. The bigger issue, I think, is that the authorities can't be trusted. In what world will you find even 100 people who will agree to hold truth, justice, blah blah in high regard, and actually execute on those words? Corruption in the leaders exacerbates the illness of irrationality in the people.

Absolutely agree. I think of children as "people who don't know a lot right now". But really, we're all children to some extent. Children are always honed to look for inconsistencies, and if those inconsistencies aren't addressed, distrust builds up. "You said I can't be on my phone too long, so how come you're doing it?" Distrust leads to irrational judgements, often in a broad-brush pendulum swing towards the opposite position. Trust is built up painstakingly and organically. Distrust tears it all down instantly. As long as "the masses" (to which all of us, to some extent, belong) exhibit this asymmetry between trust and distrust, for the people who want to speak truly, the key is consistency. Never be (perceived as) the boy who cried wolf.

Thanks for sharing. Aside from what the other replies to you have shared, I admittedly have less experience, and I'm mainly interested in the OS perspective. Balancing global and local optimizations is hard, so the OS deserves some leeway, but as I see it, mainstream OSes tend to be awkward no matter what. It's long past time for OS schedulers to consider high-level metadata to get a rough idea of the idiosyncrasies of the workload. In the extreme case, designing the OS from the ground up to minimize cross-core contention[0] gives the most control, maximizing potential performance. As jandrewrogers says in a sibling reply, this requires a commitment to rigor, treacherous and nonportable as it is. In any case, with improved infrastructure ("with sufficiently smart compilers"...), thread-per-core gains power.

[0] https://news.ycombinator.com/item?id=45651183

The trend of multicore and NUMA means that hardware increasingly looks like a traditional network of many separate computers. The natural conclusions of single-core scaled up to, say, 4 cores, shift when there are 8+ cores. Locality becomes crucial; just as you wouldn't split up data-path dependencies across LANs, you shouldn't split them up across NUMA sockets either. Ignoring arguments about locking, message passing, cache management, and whatever, the most pressing argument for multikernels (or at least, far increased per-core state and reduced shared state) is that locality is essential for performance.

Haven't read that before, but nicely read. I've had related thoughts on this, and I agree. I like the quote "keep an open mind, but not so open that your brain falls out". Alternatively, change always comes, so be adaptable to change and face it head on. It's not clear how to divorce what I like from my identity, because I'm not a perfect automaton, but I try to minimize its influence and appreciate that we're all the same, standing in different places.

> Sometimes you can prove mathematically that two different approaches are equivalent, but differ only in name or some parameter, and that's a unification of sorts, without proliferation of standards.

Certainly, but that would already be supposing most of the work to unify at the source level is done, unless an extremely strong normalization is possible.

> Untyped lambda calculus (and its sibling combinatory logic) is just language for expressing logic, nothing more. And it already exists (arguably it's one of the first programming languages, predates Forth and Lisp by at least two decades) and is among the simplest ones we know. I actually became interested in LC so much recently because, believe it or not, expressing things in classical logic is often more complicated than expressing things in LC.

(Personally, I prefer combinators slightly more)

I don't deny the power of LC for some uses, but taking one program, reducing it down to an LC equivalent, and then resurfacing as another program (in a different language, but otherwise equivalent), or some other program transformations you may desire, would certainly be elegant in some sense, but very complex. It's like programming in Brainfuck; the language itself is very simple, and making mechanistic tooling for it is very simple, but I don't think the tooling we could invent in 50 years would be sufficient to make Brainfuck simple to read or write. Moreover, formalizations of, say, "button" are not a problem, but scaling to different screens, devices, use cases, and so on will greatly increase the scope. This OS represents input events this way, this hardware provides that sort of data. I think this is the same problem as to why people, everyday, don't bother to make formal arguments almost all of the time. It's not that a formal argument along the lines of "you didn't take out the trash today, so I have reason to be frustrated with you" can't be formulated or proven, but rather that the level of rigor is generally considered both fatiguing and unnecessary.

Any time someone suggests something that should make things much simpler, I'm skeptical. There are things that have essential complexity too great to be made simple, and then humans maybe have an inherent overhead of accidental complexity, above and beyond the accidental complexity we accidentally add. I'm still interested to see where your efforts lead, but I'm not expecting to see cheap nuclear fusion for another 10 years at least, so.

The thing is, the most fundamental obstacle to unification, is that unification is a very hard feature to obtain. Even in an LC formalization, do you expect that two "text editor" programs would be interchangeable? Would only a canonical text editor be allowed? Does the LC facilitate arbitrary extensions, that perhaps follow some rules at the interface/boundary? While I also lament what is, on the whole, wasted work and interest, I think the alternative is not some much simpler solution, but rather to offer something that is better. https://xkcd.com/927 is a warning, as true as it is annoying. We gravitate towards variety because it is simpler and natural to how we act; how will your proposal fundamentally improve on this? You call out misguided "defenders", and again I note the same problem, but you seem to be calling for One True Way with no significant realizable improvement.

There are no hard rules; use principles flexibly.

That being said, there are some things that are generally true for the long term: use a pinned thread per core, maximize locality (of data and code, wherever relevant), use asynchronous programming if performance is necessary. To incorporate the OP, give control where it's due to each entity (here, the scheduler). Cross-core data movement was never the enemy, but unprincipled cross-core data movement can be. If even distribution of work is important, work-stealing is excellent, as long as it's done carefully. Details like how concurrency is implemented (shared-state, here) or who controls the data are specific to the circumstances.

Yeah, I don't think "surely no one seriously believes this" is viable now, if it was before. Of course, what you choose to do with that conclusion is still up to you.

See also Barrelfish for a multikernel research implementation. I think fos also qualifies.

> Personally, I would never agree to give up SMP CPU coherency. Multiprocessor systems are hard enough to debug with hardware cache coherency that adding in entirely new unpredictable non-deterministic behaviour would lead to more developers losing the rest of their hair prematurely. And it would likely introduce an entirely new class of security issues that nobody ever imagined that would require even worse performance draining software workarounds.

What are you envisioning is the alternative hardware (or is it software?), and why? I assume this is referring to some mechanism for multikernel support that doesn't rely on cache coherence. It seems like there are probably alternatives to full cache coherence that would be neutral, or better, after experience. You didn't provide substantive evidence, but on the other hand, at least multikernels on unmodified hardware seem promising.

Sounds interesting; I would like to see more OSes built out of passion. Just curious about design choices (I don't mean to come off as aggressive below):

> from basing off of Plan 9 to building a new exokernel in a language like Rust

This seems like a big change. Won't the driver support and infrastructure be even more of a hassle? And why an exokernel in particular?

> using a single-address space design similar to Opal

Why?

I like the emphasis on composability and user control. I think, more and more, people are realizing the necessity to seek out OS designs different than the mainstream offerings'. Can't let Linux be the final stage of OS evolution!

Probably a lot of overlap with the links upthread, but [0] also goes over Unix and Smalltalk (and I only just realized is also by Stephen Kell).

[0] https://dl.acm.org/doi/10.1145/2525528.2525534

Rust isn't perfect, but it's basically the most viable language currently to be used in software such as Linux. It's definitely more of a C++ contender than anything else, but manages to be very usable in most other cases too. Rust 1.0 got a lot of things right with its compile-time features, and the utility of these features for "low-level" code has been demonstrated repeatedly. If a language is to replace Rust in the future, I expect it will take on many of the strengths of Rust. Moreover, Rust is impressive at becoming better. The work for Rust-for-Linux, alongside various other improvements (e.g. next trait solver, Polonius and place-based borrowing, parallel rustc frontend) show that Rust can evolve significantly without a huge addition in complexity. Actually, most changes should reduce its complexity. Yes, Rust has fumbled some areas, such as the async ecosystem, the macro ecosystem, and pointer-width integers, but its mistakes are also considered for improvement. The only unfortunate thing is the lack of manpower to drive some of these improvements, but I'm in it for the long run. Frankly, I'd say that if the industry had to use only one language tomorrow, Rust is the best extant choice. Really, I'm open to

And, it's really funny that GP criticizes Rust but doesn't acknowledge that of course blood, sweat, and tears have already gone into less drastic variants for C or C++. Rust itself is one of the outputs of the solution space! Sure, hype is always a thing, but Rust has quite demonstrated its utility in the free market of programming languages. If Rust was not as promising as it is, I don't see why all of these companies and Linus Torvalds would seriously consider it after all these years of experience. I can accept if C had a valid "worse is better" merit to it. I think C++, if anything, has the worst value-to-hype ratio of any programming language. But Rust has never been a one-trick pony for memory safety, or a bag of old tricks. Like any good language, it offers its own way of doing things, and for many people, its way is a net improvement.

Contrasting the sibling reply from umanwizard, I'll say Rust is 75, but 95% of the time, it's 40 or under. There's a pretty obvious cliff, so you can avoid or detect it unless you need to do something advanced. Unlike C++, you don't just "run into" the complexity unknowingly, as if it's hiding around every corner. Normal Rust is very well crafted such that all the gears turn together, but there are many rough edges (async, traits, lifetimes) that still need a lot of refinement. As the sibling reply says, I doubt you'll like Rust. I don't like Rust when it's in 75-complexity mode either, but I think Rust is a great example of an evolving language, and the complexity should decrease gradually. Moreover, Rust has/will inspire other languages that may be more palatable.

I also encourage reading [0], for another perspective on languages and formal guarantees (and a slightly different perspective than Rust's). It also talks about concurrency, which has many open problems for programming languages and software in general cough async cough.

[0] https://gavinhoward.com/2024/05/what-rust-got-wrong-on-forma... (linked in a previous thread for OP)

> In many ways, I'd say the socialists mostly need to work on their branding and spin.

Don't they always? As much as I despise the modern Republican party and Trump in particular, I think they're much better at messaging and group consensus. Considering Bernie Sanders' electoral performance, there were (are?) definitely opportunities.

I don't think what you're describing is not "security by obscurity" so much as it is "security by not being the target". And "security by obscurity", if not used standalone, is basically just "security by good practices".

Especially in the case of GP, I'd say Rust is not the main recommendation, although it is one. I would concur that Rust is only one of many decent languages (for memory safety or otherwise).

Still, there are languages with guardrails, and then there are languages with guardrails, and the order for memory safety is probably something like C < C++ < Zig < Rust < managed (GC) languages.

Considering how big Linux is and how many different use cases it supports, this could well be an undue maintenance burden for Linux where it wouldn't be for other operating systems. Though, I'll grant that I don't know the details here, and of course Linus is...opinionated.

I trust science; I trust scientists less, and science journalism and its readers even less. Science as a human practice has never been a shining beacon of the truth. Even ignoring results that suit politics, I don't take much stock in psychology findings nowadays. And as someone interested in learning more about psychology, it's unfortunate. Science is valuable, but it should never obscure the truth. Even perfect science is not the sole arbiter of truth.

I think most people would claim that they support the truth. Even a troll might publicly claim to speak the truth, let alone someone who has an ideological motivation to believe likely falsehoods. Flat Earthers don't typically say "I know the Earth isn't flat". The best lies come with a grain of truth. And all appealing claims build on the listener's beliefs of how the world truly is. The truth is a great hook.

Although this is somewhat true, I think the bigger issue is expecting Linux to support all these use cases. Even if Linus accepted all use cases, it's a different story to maintain a kernel/OS that supports them all. The story from an engineering standpoint is just too unwieldy. A general-purpose OS can only go so far to optimize countless special-purpose uses.

In my own experience, I think I am not "match[ing] the hive mind", nor do I try to, and as such my karma growth is slow but not painfully so. I think that I've been treated more or less fairly.

I think your downvotes mainly come on some of your political comments. Political threads are not great to begin with, and I think you're giving yourself some undue credit as to your participation to them. I commonly hear that HN leans liberal and whatnot, and that's probably true, but I wouldn't say that non-liberal (for severe lack of a better term) comments are necessarily dogpiled. I think many non-liberal comments that are downvoted here are done so for being in bad faith, because they may have a point but overextend their argument to other targets. I make it a point to not take sides and be critical of all opinions (of course I don't implement it perfectly), and I think I have been treated more or less fairly. I linked some political threads I participated in to demonstrate non-downvoted non-liberal comments. If some of my opinions are "liberal" and others are "conservative", I'll just say that I try to be fair and reasonable.

  https://news.ycombinator.com/item?id=36523600
  https://news.ycombinator.com/item?id=36653284
  https://news.ycombinator.com/item?id=45573777

I only downvote people who I think are degrading the conversation who seem outlandishly wrong or off-topic. If I just disagree with someone, I may reply or not. It's reasonable to disagree on the basis of holding different values or beliefs.

That's why I like to read most of the comments on a post, because typically I'll find some useful information scattered throughout. After I'm done, I can roughly get a sense for "excellent comments", "comments that probably have a good point", "medium-quality arguing", and "probably just wrong comments". Then I may seek out other submissions of the same topics to get more data. Over time, I refine which points I think are probably valid. HN has its gems, just perhaps not as often or obvious as advertised.

I generally agree with you. I have a bad habit of simplifying my statements and losing nuance. If an error occurs, it should be handled reasonably and soon. If the cause or solution to an error is unclear, restarting at the task boundary is valid. Blowing away the whole task in one stroke is an instance of handling the error promptly. If the solution is in-task, it should be expediently reached through the call structure. Returning through many functions, performing cleanup all the while, in order to reach the handler is the pattern of deeply-nested error bubbling that I dislike.

Of course, this is still a cursory description. I think various strategies by domain agree on general principles. There is likely a class of errors that is too likely and/or unsolvable, in which case whole-task-restarts are advisable. Within the task, there may be other kinds of errors that can and should reasonably be resolved. User interactivity is also relevant (e.g. is a user directly interacting with a task in the error state). Overall, this comes down to a few factors for each error, roughly: likelihood, severity, solvability. Errors should always be reported when possible and brought to the attention, if not fixed, of a capable supervisor, which eventually culimante at a person (e.g. user or sysadmin).

I guess I don't understand how much the spec dictates the architecture of Tritium, or the motivation for the Option return type specifically. In any case, it seems like future development will improve upon this. Have fun and good luck!

This approach is brittle to upstream code changes, and I don't think it should be used, but at least there is an effort to avoid catastrophic behavior (unlike Linus's philosophy for Linux). Both panicking and arbitrarily-nested error bubbling are more standard and recommended, but I think they are still suboptimal, mainly for code quality/maintainability, and should be phased out gradually. I think the viable methods for robust software are promptly handling errors or making errors unrepresentable. To promptly handle errors, the program should be structured such that error bubbling nests shallowly. Unrepresentable errors work within type systems or formal verification, such as the classic advice of "parse, don't validate"[0], giving no way to speak of an error state (so hopefully a cosmic ray never causes it!). These latter approaches are more ideal, but can be a pain to implement.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...