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.

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".

- `Option` and `Result` 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.

I won't say with confidence either is better than the other; but I think both are worth a look.

Odin (iiuc) always makes you manage memory; Vlang permits you to, but does also have linking to the Boehm GC that it will generate for you in most cases.

Vlang and Odin in terms of syntax and legibility goals... well. I suggest if you're interested, just quick look will say more than I can. :)

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

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 :)

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.

/s

I think it's quite likely that people are going to care a lot (lot) less about the semantic distinction between and (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 and never .

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 values. But is that actually something that's truly load-bearing? Maybe dropping that expressability is actually a viable trade.

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)?

Building big sharable package systems is indeed a second half of the problem. Figuring out how to make the system have the hashy goodness AND be usefully collaborative with async swarms of people working independently and yet sharing work: tricky. We're trying to do it, though!

We have our first few packages now published, here: https://catalog.warpsys.org/

You can also see _how_ we build things, because we publish the full rebuild instructions with each release: for example, here's how we packaged our bash: https://catalog.warpsys.org/warpsys.org/bash/_replays/zM5K3V...

I'm in #warpforge on matrix with some collaborators if anyone's interested in joining us for a chat and some hacking :)

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.

It's heading in exactly that direction. In fact we specifically want to start using Starlark for module declaration (mind -- optionally. It's still all declarative JSON API at the bottom! APIs FTW!).

We're also going full hermetic and aiming for reproducible-by-default. Those should be "duh" things in modern world. The comparisons with the good parts of Nix should be obvious.

The starlark-adjacent parts are still (very) early, but you'll find some notes about the intention in our Notion already: https://www.notion.so/warpforge/Data-Execution-and-Formulas-...

Get in touch if you'd like to collaborate, we'd be thrilled to have more company working on it, or starting to package things!

It's not SemVer(tm).

That's it. That's the whole pitch.

There's also a section specific to golang, which indeed advocates for sticking with version 0.x.x for a very long time: https://gist.github.com/warpfork/98d2f4060c68a565e8ad18ea481...

You have my attention!

The most direct influence I've seen of the oil fund is that it provides capital behind some investments systems that are aimed to drive business creation in _non_-oil sectors (including technology).

There's a few built-in layout options: https://godoc.org/fyne.io/fyne/layout ... but not many; I think it'd be a stretch to say it's going to provide equivalents to many of the things one can very quickly and easily do in the web with a handful of divs and spans and (don't hit me) tables.

Most of the examples in https://github.com/fyne-io/examples/ don't shed further light on what complex applications might need: everything there appears to be things implemented with very simple and strict grids. Nothing looks like it proves out a feature like tables that are resizable or can automatically choose reasonable sizes based on content, which would be a huge boon for making development as rapid as web platforms can be.

The key interface for making your own layout logic appears to be https://godoc.org/fyne.io/fyne#Layout . The good news: it's definitely something you can implement without forking the core of the library. It looks a little... sparse, though.

Let's say I wanted to implement a system where each object I'm laying out can have collapsible margins, and it's the layout engine's responsibly to figure out the collective resolution of that. Is this interface enough? How would I proceed?

...

Maybe I just need more time with it to see the potential, but it's definitely something I find important to watch out for. I've been burned enough lately by investing time in systems (I'm looking at you, nuklear) just to find their layout primitives are so far off the mark that they're in "start over" territory. And I think we can also look to more ancient history like the Java Swing era to see that "layoutManager" objects that don't have _enough_ interface information to work with are pretty doomed, because they result in whole divergent non-compatible layout suites that the whole application has to opt into, which is just a nightmare for growing a community with reusable code.

Layout is hard. And important.

They really get UX. It's hard to explain how fluid and useful their product is until you try it. Nothing else I've experienced comes close for:

- quickly and meaningfully getting ideas on a screen

- freely organizing information in nonlinear space

- understanding where other viewers attention is at, and marshalling it to where it needs to be, in a group setting.

I use it both for personal brainstorming and in meetings, and it's great.

One wish -- if anyone from Mural is reading this -- would be better export tools. The current situation where I ask for an export, I get an email with a link later (which expires!), etc, is super silly. I'd much rather you make my browser hang for a few seconds, honestly -- taking me out of flow is super irritating. (If this is intentional, to make exporting harder and build a walled garden -- stop it / don't bother! Your product is already good; I'm exporting PDFs to attach to emails for (vigorous handwaving) Reasons; I will tell people to come back to your product to edit and collab in the second email to them!)

Experimentally from the real thing? I'm not even sure we know how many new pieces of technology we'd need.

It's not even clear that "the weights" are the only variable we're still needing. Even in the pure-computer-science conceptualization of neural networks, things like the activation functions matter; so, it's not unreasonable to suppose there are similar important features to track in biological systems... and whatever those are, we probably aren't getting them captured in a purely geographic connectivity scan.

It's not present.

HN is discussing HN's tangentially-related feelings more than HN is discussing the article. I'm not surprised, but I'm certainly frustrated: in addition to being navel-gazing, in this situation it's also substantially missing the main reasons this is good: a regulatory agency is actually doing Reasonable Things -- things any privacy advocate should probably be pleased with -- but not just are they doing Reasonable Things, they're them in a relatively subtle, non-prescriptive way that actually keeps the options open for further future improvement. This is great; DDG is an incidental detail.