Another good way to think about this is that it does change the output, but in a way that is equally likely to make it "better" as it is to make it "worse".
839 karma · joined February 22, 2018
https://www.outofrage.net/post/review-henge-journey-to-voltu...
This creates a foldable with no durability issues and no “crease” problems. Also the two halves of the display could be on the outside when folded, avoiding the need for a third display and getting a rear display for free. I would buy 3 of these.
I’m a little curious to try and build an API where parsing must be exact, and changes always result in a new version of the API. I don’t actually think it would be too difficult, but perhaps some extra tooling around downgrading responses and deprecating old versions may need to be built.
I think the fundamental difference between advertising to discoverers vs advertising to consumers is that currently “discoverers” (platforms, content creators, billboard owners, etc.) make money directly from advertisers. Success as a “discoverer” is at least somewhat correlated to income (with more money, platforms can be more successful; content creators can create more compelling content; landowners can buy more billboards). If that money is coming from advertisers, you are biasing the market to prefer discoverers that can secure the most advertiser funding, which in turn preferences advertisers that can spend the most on advertising. This isn’t fundamentally bad, since a compelling product can make a lot of money that can then be spend on advertising, but it also creates anti-consumer incentives (like marketing something that is just good enough not to return as the next best thing). On the other hand, if discoverers are paid directly by consumers, that biases the market to prefer discoverers who identify products that bring the most value to consumers for their money.
There is an alternative model where we simply pay professional product discoverers. Think influencers, but whose customer is the fan not the sponsor. It would be a massive cultural shift, but doesn’t seem so crazy to me.
He does a bunch of awesome stuff with PVC and 3D printed parts.
Moving to our own multicast hardware not only greatly improved performance, but also greatly simplified the design of the system. We required specialized expertise, but the overall project was reasonably straightforward. The biggest issue was that now we had a really efficient packet-machine-gun which we could accidentally point at ourselves, or worse, can be pointed at a target by a malicious attacker.
This 1-N behavior of multicast is both a benefit and a significant risk. I really think there is opportunity for cloud providers to step in and provide a packaged solution which mitigates the downsides (i.e. makes it very difficult to misconfigure where the packet-machine-gun is pointing). My guess is that this hasn't happened yet because there aren't enough use-cases for this to be a priority (the aforementioned video use case might be better served by a more specialized offering), but exchanges could be a really interesting market for such a product.
It would be pretty efficient to multi-cast market state in an unreliable way, and have a fallback mechanism to "fill in" gaps where packets are dropped that is out-of-band (and potentially distributed, i.e. asking your neighbors if they got that packet)
VSCode works pretty well with the sswg extension (powered by sourcekit-lsp). Devcontainers are particularly nice if you are into that sort of thing (I develop in a Linux container on a macOS host). I actually find it easier to experiment with new toolchains (for example, the nightlies) in the Linux container than on my host machine (which requires more manual setup).
That said, Swift's implementation of borrowing seems significantly more user-friendly than Rust's. While this is very much an advanced feature, I'd expect it to be actually used in many cases where in Rust folks would resort to working around the borrow checking (via things like indexing into arrays and such). As a result I expect it to be significantly more useful.
UI is a different matter. Xcode is still miles ahead in performance tooling.
For production use-cases at this moment in time, I'd probably lean towards using Swift's pretty-good C++ interop functionality to thinly wrap a more battle-tested C++ library.
I agree that this is a must-have for idiomatic Swift. It is really hard to write the long-named-functions and get all the variable names correct without reasonable autocomplete.
One addition: Swift WASM support has recently become stable enough to be [included in CI](https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm...). The folks working on that have done a great job and I’m very excited for that to get more fleshed out!
I’m not a working with them, but am cheering from the sidelines. One of the founders gives a great talk here: https://m.youtube.com/watch?v=fFSPwJFXVlw
There are a number of other proposals linked to this issue that can be referenced from that thread. I hope there is a next generation async model for future languages that is truly simple, because this all makes me think footguns are endemic to the current approach (which is broadly the same in Rust and Swift).
I actually interviewed with them when they were just starting, and outside of being very technically proficient, they are also a great group of folks. They flew my wife and I out to DC on what happened to be the coldest day of the year that year (we are from California) so we didn’t end up following through but I’d like to think there is an alternative me out there in the multiverse hacking away on this stuff.
I highly recommend Will’s talks (which I believe he links in the blog post):