Yes, though the API of having a write-only value that is a monotonically increasing counter is much simpler than having to think about causality or logical clocks.
Unfortunate that the author doesn’t bring up FoundationDB version stamps, which to me feel like the right solution to the problem. Essentially, you can write a value you can’t read until after the transaction is committed and the synchronization infrastructure guarantees that value ends up being monotonically increasing per transaction. They use similar “write only” operations for atomic operations like increment.
Unless Apple comes up with a way to have the crease still physically be there, but visually seem like it isn’t. Perhaps using a waveguide or something similar.
I betting $10 Apple’s foldable will be two iPhone Airs where one side has 0 bezel hinged together with extreme mechanical precision and maybe some fairy dust to make the gap when unfolded unnoticeable.
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.
Gaudi is among the best engineers and artists who ever lived, and I won’t belabor his greatness. It is cool though that Rhino (https://www.rhino3d.com/) got a shout out in this article, it is a similar blend of engineering and artistic excellence that I’ve only dabbled in briefly, but repeatedly pops up in the toolkits of the most interesting engineer-artists. One of my personal favorites is John Edmark who among other cool things made these shutter-synced 3D sculptures that are absolutely amazing: https://www.johnedmark.com/phifib/#itemId=572301305559869e24...
While this is a common view, recently I’ve begun to wonder if it may be secretly an antipattern. I’ve run into a number of cases over the years where additional fields don’t break parsing, or even necessarily the main functionality of a program, but result in subtle incorrect behavior in edge cases. Things like values that are actually distinct being treated as equal because the fields that differ are ignored. More recently, I’ve seen LLMs get confused because they hallucinated tool input fields that were ignored during the invocation of a tool.
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.
One thing is the graphics are a generation behind what you would usually expect from a game of this quality. I’ve been playing it and I can confirm it is wonderful, and the graphics just makes me impressed with the amount of focus the tiny team (33 people, I think?) put into making what matters great (though I’d be excited for a remaster in the future).
For the record, I’m not saying this is the perfect model and we should move to it immediately. My only claim is that it isn’t crazy.
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.
The idea of product discovery has value. Advertising funds product discovery by taking some of the funds that you pay for goods, and funneling that money to platforms and creators that are willing to help others discover that product.
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.
I’m genuinely surprised it took this long for Apple to do this. Having a full contacts list has long been one of the most valuable pieces of information for ad targeting. It’s why you can not be on Facebook but they still know everything they need to know about you because enough of your contacts are on their platforms.
If I’m not mistaken, the embedded swift mode aims to make ICU (the 27mb file for Unicode support) optional (and thus easily removed where it isn’t needed)
I ran into this problem a while back working at a company that was working to distribute video streams with low latency (lower than Low-Latency HLS) to a large number of viewers. Initially a prototype was built on top of AWS with fan-out/copying and it was terrible. This was partially due to inefficiency, but also due to each link being a reliable stream, meaning dropped packets were re-broadcast even though that isn't really useful to live video.
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)
I have in several capacities over the past few years.
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).
One thing I’ve noticed in my career is that it is often quite difficult to distinguish “good” technical infrastructure improvements (meaning ones that will actually help a company achieve its goals) from “bad” ones (stuff that is unnecessary, risky or simply not worth the investment). I've seen these decisions made more using the political capital of high level engineers than by anything data-driven. That’s not to say this isn’t a problem, just maybe more of an art than a science.
For the record, borrowed references are only going to be really usable in Swift 6 which isn't released yet.
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.
It wasn't too bad to switch for me, but the problem is going back and forth. I don't love over-customizing my IDE but I've created my own keybindings for the commands I mis-type most (Command-R to run being the main culprit). Both Xcode and VSCode support custom key bindings and this isn't something that the LSP is responsible.
UI is a different matter. Xcode is still miles ahead in performance tooling.
This is spot-on. Though I think the interesting thing here is just demonstrating that you _can_ build this kind of thing at all and a cross-platform-SwiftUI-like framework isn't a pipe dream.
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.
https://www.outofrage.net/post/review-henge-journey-to-voltu...