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".
- `?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.
Language explorers looking for lower level languages like this may also want to take a peek at the V language. https://vlang.io/
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. :)
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 :)
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...
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)?
Warpforge -- project website: http://warpforge.io / https://github.com/warptools/warpforge -- is a project I work on that's heading a bit in this direction. Hashes in + build instruction = hashes out. It's really a powerful primitive indeed.
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!
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.
That fund affects day to day life a lot less than you might expect, FWIW. It's not like we get to just... spend that; it's somewhat comparable to saying "the New York Stock Exchange contains over $foobar dollars per citizen" (although of course the fund isn't managed at all like a stock exchange, either).
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).
Layout is sort of the center of questions I have about it too.
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.
I really like Mural and am definitely cheering for them.
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!)
Computationally? Think something like "NP hard", except the "verifier" function isn't even plausibly cheap either.
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.
Sure, but grep the fine original article for the word "privacy".
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.
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.