heavenlyhash

I've come to realize (I think) that this actually does have a lot to do with waterproofness ratings -- a legibility trap.

I notice that Fairphone excludes headphones from their latest devices, and attributes it to the necessary of doing so in order to get an "IP55" rating.

I'm not sure if that ultimately makes sense (and suspect that it... doesn't), but the legibility trap of that ratings system might actually be part of the cause of the current market absence of a feature so many people still talk about after years of its unavailability.

I want to like this, and it's directionally good work...

But it's hard to see this as very useful unless we also start to see some increases in legibility, and ways to make sure these optimizations are being used (and that textually minor changes don't cause non-obvious performance regressions).

I've written a lot of golang code that was benchmarked to shreds, and in which we absolutely cared about stack-vs-heap allocations because they were crucial to overall performance. I've spent a lot of time pouring over assembler dumps, because grepping those for indications of new object creation was sometimes clearer (and certainly more definitive) than trying to infer it from the source code level. The one thing I've learned from this?

It's very, very easy for all those efforts to come to naught if the rules change slightly.

And it's very, very, VERY easy for a co-maintainer on a project to stroll in and make seemingly textually trivial changes that have outsized impacts. (I'm looking at inliner thresholds, specifically. Hoo boy.)

The best balm we have for this right now is writing benchmarks and making sure they report zero allocs. (Or unit tests using the runtime memstats harness; potato potato.) But that is a very fragile balm, and relatively complex to maintain, and (if DX is considered) is not textually local to the code in question -- which means someone changing the code can easily miss the criticality of a section (until the tests yell at them, at least).

I really yearn for some markup that can say "I expect this code to contain zero heap allocations; please flunk the compile if that is not the case".

I'm an advocate for "both".

- `Option<T>` and `Result<T,E>` at core;

- `?T` and `T!E` as type declaration syntax that desugars to them;

- and `.?` and `.!` operators so chains like `foo()?.bar()!.baz()` can be written and all the relevant possible return branches are inserted without a fuss.

Having `Option` and `Result` be simply normal types (and not special-casing "nullable") has benefits that are... obvious, I'd say. They're just _normal_. Not being special cases is great. Then, having syntactic sugars to make the very, _very_ common cases be easy to describe is just a huge win that makes correct typing more accessible to many more people by simply minimizing keystrokes.

The type declaration sugar is perhaps merely nice to have, but I think it really does change the way the average programmer is willing to write. The chaining operators, though... I would say I borderline can't live without those, anymore.

Chaining operators can change the SLOC count of some functions by as much as... say, 75%, if we consider a language like Go with it's infamous "if err not nil" clause that is mandated to spread across three lines.

This is a delight to read. I've been doing a survey of languages over the last several days, and Odin is one of the more interesting ones... but looking at the OS and FS related parts of the standard library made me back away at high velocity. They seemed like litanies of generated code that simply describe every quirk of every platform: not an abstraction at all. And while I do want those levels to be _available_, I also don't want to be dragged down there in every program.

Delighted to see more work will be focused there in the future.

That is roughly the number of new requests per second, but these are not just light web requests.

The git transport protocol is "smart" in a way that is, in some ways, arguably rather dumb. It's certainly expensive on the server side. All of the smartness of it is aimed at reducing the amount of transfer and number of connections. But to do that, it shifts a considerable amount of work onto the server in choosing which objects to provide you.

If you benchmark the resource loads of this, you probably won't be saying a single server is such an easy win :)

Really depends on where you're from.

OP already mentioned in his area it's phonetically mostly "ew".

I'd say a lot of germanic areas also do something I'd describe as "oi". That'd also make one inclined to use an "an" when speaking.

Ah, yes, the KDE people are definitely the people I trust most to deliver a reliable system and not go crazy chasing incongruent rewrites of things while abandoning what works...

/s

My 2c (opinions may vary, etc, etc): I think that doing percent-encoding shenanigans is going to be widely perceived as "ugly" and will severely hamper adoption. I'd reconsider.

I think it's quite likely that people are going to care a lot (lot) less about the semantic distinction between <namespace> and <name> (which is a semantic, handwavey, somewhat indistinct subject to begin with) than they are going to be turned off by percent encoding.

There's two broad categories of possible outcome for that kind of friction:

- Either people-in-the-wild do implement and obey the percent encoding rule, despite the friction (and adoption gets a debuff);

- Or, people-in-the-wild will just quietly ignore the percent encoding rule. And I think this is significantly likely, considering that (iiuc) the only consequence is that the parts with slashes end up considered <name> and never <namespace>.

Neither of those outcomes is totally bad, but they're both unfortunate. For the first one, an adoption debuff is never great. For the the second one (e.g. rule mostly ignored), there's other potential negative outcomes: the community might be fractured; and also, that figuring out what to do when writing a good renderer and some people followed the percent-encoding rule and some didn't... is going to be very, very ugly.

On the other hand, if the spec doesn't recommend (or support) percent encoding at all... yes, it loses the ability to express some <namespace> values. But is that actually something that's truly load-bearing? Maybe dropping that expressability is actually a viable trade.

soo..... what's the guidance for when package names include a slash?

such as approximately everything in golang, which very often matches e.g. "github.com/*" as a package name?

Do would PURL suggest that "github.com/foobar/go-whatnot" should be parsed as namespace="github.com" (odd) and package name "foobar/go-whatnot" (since there aren't any more slashes in the blessed separators)?

I want to see more things like this emerge too.

I think one of the bigger barriers is that terminals don't really have a component reuse boundary.

What I mean by that is: in the browser, you can always put more HTML inside a div tag, and generally speaking, it's gonna stay within the boundaries of that div tag, and things will compose and it won't be a fuss. In the terminal: what's the equivalent of that?

It's possible, and yet not actually remotely pleasant, to make a new PTY/TTY for each component (or each small application that you want to embed within another), and then grab the state of that PTY and replicate it into a rectangular region in another PTY that's bigger. There's so, so, SO much friction in this, though. It also only solves the view bounding: it doesn't solve, for example, the ability to have a copy/paste operation that works on the interior content in a standard way (instead each terminal application solves that itself, usually with some unique bespoke shortcut sequence, because you need _application logic_ to find text ranges since what's rendered to a terminal vs what the logical text state is are usually different).

I think if someone created some very basic component-oriented UI system to solve the composition problem -- then kept most of the components as roughly PTY/TTY and TUI concepts! -- it could lead to interesting places that PTY stuff will have difficulty getting to alone.

> Crev is an actual _code review system_ as opposed to typically practiced _code-change review system_.

You have my attention!