georgelyon

Yes, this is the correct behavior. If Alice and Bob disagree about whether or not that row should be in the table you aren't going to fix it with math. More often than not, the expected outcome will be obvious (i.e. spelling correction in a deleted cell can be ignored) and if it isn't obvious, there will need to be human interaction to determine the best path forward.

The best UX resolution to this kind of issue I have seen is to display “This table cell was added by Bob concurrently to Alice removing its row. How would you like to proceed: recover the row or ignore the change?”

This comment really needs a “yo dawg” meme.

For the record, you do have fairly fine grained control over what updates when with SwiftUI. The issue is that this isn’t obvious to new developers, nor is it easy to understand what tools to use to fix issues once you understand what is happening.

This could be taken to support my point. There is a MASSIVE amount of literature on the internet about how to do this, and it's reasonably straightforward to see what is happening with the DOM when you use these frameworks. Likewise, a novice developer can create something that causes scrolling to stutter or other performance problems pretty easily in this world.

Take on the other hand, some of SwiftUI's more advanced features, like PreferenceKey which are extremely under-documented (the generic sounding name doesn't help either). Of course folks are going to struggle to do more complex things.

I wonder how much the situation would be helped if the thing you searched for help allowed in-line SwiftUI examples, like you can do on the web. Playgrounds is kind of that thing but you aren't searching a repository of playgrounds for documentation.

I’m happy this worked for you. This in itself is an interesting anecdote about documentation quality. I knew this API existed but forgot the exact API and searches for “caching SwiftUI rasterized view” and similar queries did not return this API (which, for the record, isn’t exactly what it does…) . I eventually found it in a roundabout way but had I not been pretty sure it existed, I would probably have given up.

Other commenters have pointed to SwiftUI being declarative as a big part of this problem, but I take a more nuanced view: the problem is actually that SwiftUI is a complexity-hiding abstraction. Specifically it hides the complexity of when UI is refreshed and how it is refreshed. This results in a situation where engineers who don’t have a clear understanding of how it works resorting to essentially guesswork to try and fix performance issues. Now, there are certainly folks who do have a deep understanding of how SwiftUI works but that group is likely small and the situation isn’t helped by middling documentation and SwiftUI being closed source. An analogue to this can be seen in something like SQL, which is a (somewhat) declarative specification for queries that is also complexity-hiding. SQL, wielded by a novice, can be pretty slow (just one ill-advised join would likely do it), but would still “work”. The difference with SQL is that there is a plethora of literature about how to write it in a way that results in fast queries and many of the consumers of SQL are open source so enterprising engineers can dig down and figure out what a particular query is doing and why something is slow. We’ve also invested a ton of resources in creating engineers who can write good SQL. I’m interested to see how SwiftUI progresses in these regards.

Unrelated addendum: The author should look at the drawingGroup API. This could significantly speed up the drawing of the month grids on refresh by caching the resulting rasterized view instead of repeatedly redrawing it.

I can’t speak for the author, but I’ve had a similar feeling. Where (safe) Rust’s core principle is memory safety at all costs, I feel that Swift takes a more nuanced approach, prioritizing making good programming patterns easier while still being memory safe (though perhaps not as expressive as Rust).

Swift also is much more principled when it come to certain things like exceptions. Whereas Rust (if I remember correctly) allows arbitrary panic-ing and catching of panics, Swift forces you to acknowledge a possible panic at function call sites using “try”. Without “try” control flow can’t suddenly end.

Admittedly, I haven’t used Rust significantly in a couple years, but I wrote this a few years back and some of the points still have merit: https://gist.github.com/GeorgeLyon/c7b07923f7a800674bc9745ae...

> and (somewhat) work with multiple devices

I was hoping for AirPods which synthesize audio from all of your devices using spacial positioning... maybe next generation

If M2 Pro is similar to M1 Pro (two M1s duct-taped together with very fancy duct tape), this is interesting because usually chips need to be significantly reworked for a newer process and this implies an M2 core complex will be printable both at 5nm and 3nm. It would be interesting to know how much of this is fabrication becoming more standardized and how much is Apple's core designs being flexible. If this is the latter, then Apple has a significant advantage beyond just saturating the most recent process node.

MLIR (https://mlir.llvm.org/) is a quickly growing compiler toolkit which attempts to synthesize the learnings of LLVM and currently powers compilers for programming languages, machine learning and circuit design (https://github.com/llvm/circt). and there are a ton of companies with real employees working on it (including Microsoft) and MLIR is at the core of Chris Lattner’s new company, ModularAI. I’d recommend taking a look at it, there are a large number of ways to get involved and a number of paths from contributor to employee.

The one thing that has come of this is that products that do this have 0.5% less friction (they can auto-update quicker), achieved this faster and with less engineering effort (no need for a clever workaround, just use the biggest hammer), and have 0.5% less customer support burden (since everyone is on the latest version all the time). As a result, this can help a product dominate their competition the way Zoom has. I say this as a security conscious person who wishes this type of app would just go away, but has worked in the industry long enough to understand the economic realities.

Honestly, this is the number 1 confounding factor for me in terms of the “app stores should be more open” argument. Sure, Apple is stifling innovation in phone applications by disallowing this type of thing, but also the Zoom app is much better behaved on iPhone because it has to be. Personally I am happy trading off some convenience for security, but I am unsure if there is a “correct” answer here. My personal hope is that VMs will become useful enough that it will become viable to have a crude per-shitty-application sandbox for folks that are security conscious. I already have done this with tools like docker from time to time, which admittedly isn’t a great experience.

I tend to agree with much of the criticism of SwiftUI, namely that it and the underlying mechanism (result builders) is over-indexed on the UI-for-iPhone-apps use case. But I think Swift's greatest strength is what I mentioned in the parent comment: progressive disclosure. You don't need to use result builders and if you don't, the complexity of the language stays the same. I contrast that with C++ which has added some powerful, complex features that underpin most of the language, making it more necessary to understand the full scope of the feature set to get anything done.

The move function is not move semantics (though the latter is being discussed by the community). The main purpose of the move function is to explicitly document where performance sensitive code depends on a specific type of compiler optimization and providing diagnostics if those conditions change in a subsequent revision of the code.

Swift’s focus on progressive disclosure means most Swift users won’t need to worry about this.

They have been improving this steadily (I would argue it is rarely an issue nowadays, and there have always been simple workarounds), but there’s no reason a solution to the problem mentioned in the article should need to use ARC, and should use structs/protocols instead (which don’t use reference counting). I’ve seen a lot of Benchmarks that rate Swift poorly because of this.

Does anyone know why Apple doesn’t make this standard? I’ve been using this on and off for many years and only stop because I get frustrated after an OS update reverts it. Are there licensing/security/compatibility reasons this may be the case? Seems like an easy fix.

This reply hits the nail on the head, but I’ll just add that this isn’t only a benefit to small scale services. I’ve been at well funded startups and medium sized companies where we spent quite a bit of time and effort dealing with spam and bot activity, to the point of making trade offs in the product to lower the impact of bad actors. Even companies that are more or less successful at this spend a TON of money and engineering resources on this problem, and it still manages to detract from the UX (think Twitter bots). I wouldn’t be surprised if the economic benefit of a technical solution to this problem was on the order of tens of billions of $$.

This is an excellent write-up, and I genuinely hope that the brain-cycles the web3 world is spending on this eventually benefit the rest of society.

I’ve been musing about a similar but more simple problem: how can we prove we are an individual human in the context of a web service. Think of this like the ultimate CAPTCHA where not only can you prove you are human but every person can do so at most once or, more pragmatically, O(once).

The closest thing we have in society today is Sign in with Apple, where you have a delegated identity provided by a company which has effectively put up a large portion of its brand value as collateral that it won’t be shady, for some definition of the term “be shady”. This is suboptimal for a number of reasons, not least of which is that they can be compelled by a government to divulge this data while (mostly) protecting their brand-value-collateral, and they can be selective in what types of services are allowed to use this system.

I’m hopeful some of the non-charlatan web3 folks can come up with some sort of scheme where a trusted entity (a government or a civil rights oriented NGO) can participate in a cryptographic handshake with an end user and a service where at the end the service receives a unique identifier for that user which can not be used to associate that user across services, or divulge to the trusted entity which services a particular individual is using. This wouldn’t fully solve the “can I give this person a loan” problem, but would make many things on the web much better (most bots pretending to be human would become cost prohibitive). I also feel like trustworthiness attestation can be incrementally built on such a system (if such a system is possible).

My personal favorite concept is the Toyota Setsuna: https://www.topgear.com/car-news/concept/concepts-time-forgo...

I'm constantly surprised more folks don't use FoundationDB, I'm pretty sure the Jepsen folks said something to the tune of the way FoundationDB is tested is far beyond what Jepsen does (Good talk on FDB testing: https://www.youtube.com/watch?v=4fFDFbi3toc).

My read is that most use cases just need something that works _enough_ at scale that the product doesn't fall over and any issues introduced by such bugs can be addressed manually (i.e. through customer support, or just sufficient ad-hoc error handling). Couple that with the investment some of these databases have put into onboarding and developer-acquisition, and you have something that can be quite compelling even compared to something which is fundamentally more correct.

If anyone needs to generate cryptographically safe passwords that are easy to remember, I recommend this cool app that runs on dice:

https://en.wikipedia.org/wiki/Diceware

Looks like Samsung decided to copy work from Ive’s new company: https://www.wallpaper.com/design/terra-carta-seal-design-lov...

There's some dust on it, but I made a proof-of-concept OPAQUE implementation some years back (disclaimer: this was done for educational, not security, purposes). The README has some good discussion of the various components of OPAQUE, and I'd argue the code (mostly C) is quite readable. If folks are interested, I'd encourage them to take a look: https://github.com/GeorgeLyon/Opaque.

FDB is an awesome and unique piece of software (I attribute quite a bit of Snowflake's success to FDB). I've also had the pleasure of meeting some folks from the original team and they are true engineers. Does anyone know if/when Redwood (the new storage engine) has landed / will land?

This sounds cool, I would be very interested if you had any public code. It’s _very_ early days but I’m working on a similar project in Swift: https://github.com/circt/Edith

https://github.com/apple/swift-evolution/blob/main/proposals..., if accepted, should make most of this type of ceremony unnecessary.

I’m really hoping this kind of technology can be used to make waveguide ceilings illuminated by lasers: https://qz.com/146761/forget-led-bulbs-the-future-of-interio...

I very much agree with this sentiment, but it is difficult to endorse this line of reasoning without offering a better alternative. As folks have pointed out in other comments, there are other values to tests in the broad sense that the author doesn’t address. That said, if you are interested in improving the state of testing, I would encourage you to listen to Will Wilson’s excellent talk on the subject of Autonomous Testing: https://www.youtube.com/watch?v=fFSPwJFXVlw Indeed, FoundationDB (which Wilson worked on) has a very unique and sophisticated approach to testing that seems to have served them very well.

It is a bit newer than many of these suggestions, but the Broken Earth trilogy (https://en.wikipedia.org/wiki/N._K._Jemisin) is a really compelling fantasy and tells a really human story amidst an inspired though familiar world. If you’ve felt like you’re reading the same fantasy story over and over, I highly recommend giving this one a try.

Another interesting tack would be to include trivial functions like strlen, memcpy and friends with LLVM (excluding, at least initially, things like sockets). This would help a ton with WebAssembly as we wait for all browsers to support WASI!