heavenlyhash
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<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.
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 <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.
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.
The nicest outcomes are with coroutines, though, and that begins to be another matter.
The article is about anti-trust regulation.
These are different things.
Regardless of what you might think about the privacy of any particular option today, the point of this change is to make sure more choice is available and visible to users. In the long run, it's worth remembering that such choice might be a prerequisite for more privacy-oriented services to have a chance to grow. This is the case even if you don't regard any of the current options highly.
Well, then, there you go: that's the meaning of the word, then. Or at least it certainly is to a lot of people.
I think we again don't much disagree, other than in a very surface level about the words. I go out for a beer with some Norwegians, and they self-describe to me as having ideals they call "socialist", because they're ideals around being social and building a society together, and that's what the word means to them. I accept this definition. Maybe you've got a different one in mind; words are tricky like that.
I similarly don't know what to tell you about the utility of taking the precise wording of websites as the ultimate truth of anything. Did every person in every klimastreik around the world read those two websites and sign off total agreement on every detail they proclaimed? Probably not.
I offered anecdata that many people on the ground, even around those causes, are very positive to carbon taxes or other forms of market-aware schemes to make a difference. It is, of course, anecdata. You can take it as a note of hope, perhaps? Or, not. Up to you.
Almost everything else in the comment after that seems a bit off-kilter to me:
> The Green New Deal has turned into a jobs program
"turned into"? Are you familiar with the "New Deal" of historical note that it's deriving the very name from? It's always been a jobs program. That's part of the point.
> Soviet Union
As sibling commenters have already pointed out, I don't see how this comparison was particularly well-connected or topical.
> Increasing middle class prosperity is inherently incompatible with reducing carbon output.
No?
> The Green New Deal, together with the climate strikes have become vehicles for socialist ideology.
I don't disagree with that; what's your point, though? Are you trying to run with the association that "socialism=bad"?
I'm writing you from fairly-darn-Socialist (and fairly-darn-functional) Norway, so I'm not picking up.
> despite experts broadly agreeing that we need things like carbon taxes, the Global Climate Strike platform categorically rejects market mechanisms to address climate change.
Almost every single person I've talked to who has participated in or associated with the climate strikes has been an advocate for carbon taxes.
So, no. Those people and platforms do not categorically reject market mechanisms. In fact those that I've talked to seem to be essentially _on your side_.
> we can do it without world government
I'm sure that's true, but also, I'm not sure where there's been a suggestion of "world government" that you seem to be responding negatively to. Everything you've mentioned in your own comment is single-government internal proposals, or, groups of people advocating for general directions within their own local governments.
So in total: while I think you and I would agree in many many details about how to plan reactions to climate change, can I council you to polish your message to _focus on that_ and skip the world-socialist-government-conspiracy tinge? It's just not necessary. It seems to be making you believe you disagree with a bunch of people who... by and large agree with you, and are in fact interested in (and pursuing) market-oriented solution paths.
For example, one of the questions I generally ask in a meeting room that's considering this topic, and has for example microservices in flight, is: "Are you willing to put in the work to make Service A support more than one version at a time in Service B?", and if not, then that's a very (very) strong indicator that the level of coupling and lack of organizational boundaries will result in pain from anything but a monorepo.
I prefer to split things up when possible. When it does fit, there's many benefits. There's also the concern that building too much culture and tooling that presumes a lack of splitting of repos can become its own form of trap which becomes increasingly hard to navigate out of, even if you later want to, as the situation self-iterates. But I agree that splitting things out needs justification, and the "default" stance should include that.
Google has a lot of tooling and some very thoroughly-considered and reinforced policies and cultures around their use of a monorepo. Trying to use a monorepo without those tools and ingrained policies may not be very likely to lead to similar results.
This is a very outstandingly interesting line out the whole writeup.
I like the writeup in its entirety for being very balanced and thoughtful, but this line in particular really stands out to me as worth more thought for anyone interested in language and type system design.
Inference is great.
Except... when it's not. When it's "too much". When it starts making breaking changes appear "too distantly".
It's an interesting topic to reflect upon, because the inference isn't making a breakage; just shifting around where the breakage appears. (And this makes it hard to ever direct criticism at an inference mechanism!) But this kind of shifting-around of the breakage appearance can be a drastic impact on the ergonomics of handling it: how early it's detected, how close to the important change site tooling will be able to point the coder, etc. That's important. And almost everything about it involves the word "too" -- which means the area is incredibly subjective, and requires some kind of norm-building... while not necessarily providing any clear place for that norm-building to center around.
I don't have a point here other than to say this is interesting to reflect on. I suspect the last chapter on type inference systems has not yet been written. Can an inference system be designed such that it naturally restrains "too" much use of it?
What would it take to make that a reality, though -- without, like secure's sibling comment says, blowing up the text matrix?
Which things would you make standardized (or conventional) to make switching easier?
What things would you strip out of consideration to make switching easier?
One of the things I like about Distri is that by questioning whether a bunch of inter-package interactions are necessary (and finding out that, often, the answer is "no"), it gets closer to a model of packaging where things are less prone to create either conflicts or sprawling dependency trees. That feels like a step in a good direction, at least, to me.