- georgelyon parentYes, 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.
- Then you probably have already heard of this guy: https://www.youtube.com/channel/UCqzB9Ks5H939XLuSuVLuPVw
He does a bunch of awesome stuff with PVC and 3D printed parts.
- I’ve been wrestling with Swift’s region isolation checker recently and had a similar experience.
- 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.
- sourcekit-lsp works really well, VSCode integration is solid[1]. I've been using VSCode+dev-containers+sourcekit-lsp for a couple years now for Linux development on macOS and it has been really nice.
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.
- For the record "No macros", is one of the things that is out-of-date. There is some discussion about it in the comments... maybe I'll be forced to actually update it :)
- It is a little out of date but a few years back I wrote up a few key differences: https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...
- Great summary!
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!
- Really unique product with a super-strong founding team!
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
- I’ve been following a similar issue in Swift (which is informed by some learnings from the Rust side of things). Here is a link to the latest language complexity resulting from this: https://forums.swift.org/t/sub-pitch-task-local-values-in-is...
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).
- Additionally, such an investment effectively makes it cheaper to acquire the company down the line (since they already own some percentage of it). In such a scenario their investment would both flow back as revenue and reduce to the eventual cost of acquiring such a company.
- Congratulations to the Antithesis team!
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):
- They have built their own storage engine named Redwood, which has some very FoundationDB-specific optimizations (like prefix compression). Check out the "Storage Servers" section in this doc: https://apple.github.io/foundationdb/architecture.html
- Docker already uses many of these frameworks on macOS (look in Docker settings to confirm).
- Sure, “very infrequently recurring” may be a more accurate label than “one time”