@343max Bei uns gibt es fast alle Bücher auch online. Die Verlage bieten das ja schon lange an.
11.11.2025 20:39 — 👍 0 🔁 0 💬 0 📌 0
I would really like to do HTML templates using Elementary, but the iteration cycle is just too slow. I need that damn SwiftScript 🙃
11.11.2025 11:57 — 👍 0 🔁 0 💬 0 📌 0
RE: https://mastodon.social/@cmconseils/115527777269072386
Code amazing programs, what would you do during Smalltalk? 🙃
11.11.2025 01:51 — 👍 0 🔁 0 💬 0 📌 0
This one didn't age well "John Connor: Why attack Russia? Aren't they our friends now?"
11.11.2025 01:48 — 👍 0 🔁 0 💬 0 📌 0
Original post on mastodon.social
I think the appeal back then was primarily Web 2.0, and Prototype.js in particular. This was the fancy thing that turned heads. Having stuff update a web page w/o having to reload the whole page. Not the actual backend. You could do the same thing with PHP, Perl, Java or whatever, but Rails […]
10.11.2025 23:23 — 👍 0 🔁 0 💬 0 📌 0
Original post on mastodon.social
One reason (among many) why I never really liked Rails is that the experience literally starts with generating boilerplate code. You don't start to code, you start by _generating_ code.
Compare that to things like D2W (old at the time) where you get the whole app for free, and you only start to […]
10.11.2025 23:09 — 👍 0 🔁 0 💬 1 📌 0
I was considering to ask @PrototypeFund to sponsor a project to convert the ScalableOGo Objective-C core to Swift, but considering all, rebuilding something in a different language is probably not innovative enough 🙂
10.11.2025 22:48 — 👍 0 🔁 0 💬 1 📌 0
If Apple would have bought BeOS instead of NeXTstep, the whole Swift thing would have made *so* much more sense :zwinkersmiley:
10.11.2025 22:29 — 👍 0 🔁 0 💬 0 📌 0
BSky is a penny stock 😬
10.11.2025 01:50 — 👍 1 🔁 0 💬 0 📌 0
Screenshot of macOS notification panel telling me that the backup could not be completed because the backup disk is full.
Yes, so what now?
09.11.2025 18:26 — 👍 0 🔁 0 💬 0 📌 0
Original post on mastodon.social
@sjs Well, the `x?.y()` is automatic in ObjC. Imagine Swift just doing `thing?.frob()` by default, I think that would avoid a lot of crashes. In real code bases I've seen, people do use a lot of force unwraps. (as mentioned I don't usually, but also fell into that trap already)
Can you elaborate […]
09.11.2025 00:44 — 👍 0 🔁 0 💬 1 📌 0
Original post on mastodon.social
BTW: I'm not fighting the Safyness argument, it definitely feels good to have something as the input and not nothing and building stuff around that. But does it actually matter from an _ObjC_ perspective? I have doubts and guess that nil messaging is actually better for the larger experience […]
08.11.2025 23:55 — 👍 0 🔁 0 💬 0 📌 0
@monocularvision So you didn’t have tests before? 🧐
08.11.2025 23:31 — 👍 0 🔁 0 💬 0 📌 0
@monocularvision That wasn’t the statement though. You imply it is an insidious bug when it rarely is (I have no personal recollection of any bug due to nil messaging, but surely enough I might have just missed it 🙃)
08.11.2025 22:35 — 👍 0 🔁 0 💬 1 📌 0
If you've ever done protocol or storage format related work, the general rule is "be tolerant in what you consume, but strict in what you produce". That spirit is somewhat lost.
08.11.2025 21:46 — 👍 0 🔁 0 💬 1 📌 0
Original post on mastodon.social
I.e. something that was pretty tolerant before is now a hard crash. Are more crashes worth it, because consistency might be affected? Maybe. Though usually the eventual backing layer has a storage that enforces consistency (like your constraints in your SQLite DB will ensure everything is […]
08.11.2025 21:26 — 👍 0 🔁 0 💬 1 📌 0
Original post on mastodon.social
It's just a personal impression, but I actually do think that Swift nil handling has lead to many more app crashes due to force unwraps. And in a way that is _intentional_. Sending a message to nil may occasionally be unintended and not strictly the right behavior, but seems very rarely an […]
08.11.2025 21:22 — 👍 0 🔁 0 💬 2 📌 0
@krono They even have a `WAComponent` 🙈:
> WAComponent is the basic component provided by Seaside
06.11.2025 21:36 — 👍 0 🔁 0 💬 1 📌 0
A plate with some pepper cheese, two slices of bread and a cheese knife
Midnight snack (I really like that peppered cheese) #food
05.11.2025 22:14 — 👍 1 🔁 1 💬 0 📌 0
Original post on mastodon.social
@jjoelson I'm not sure it has been wasted, but the outcome is certainly not measurably better 🤷♀️
And it's not just dev tool efforts that have been wasted, but resources of the Apple ecosystem at large.
It would be nice PhD work to look at the actual numbers here, moving from ObjC to Swift 1, 2 […]
05.11.2025 18:27 — 👍 0 🔁 0 💬 0 📌 0
Original post on mastodon.social
@samdeane Another way to approach this would be from the app site. Ie instead of focusing on the OS/API itself, as a first step rebuild all the apps. Mail.app, Messages, Calendar, Addressbook, Terminal etc
Once those are sufficiently nice and usable, do what it takes to bring them to Linux […]
05.11.2025 09:40 — 👍 0 🔁 0 💬 1 📌 0
Original post on mastodon.social
@samdeane I’m thinking about this quite often as well. I think we do have the skill set available. I think one could even acquire money for that. But you’d need a good director of the effort.
Otherwise we end up with the current situation. I think KDE got furthest so far, maybe because it sits […]
05.11.2025 09:36 — 👍 0 🔁 0 💬 1 📌 0
SE-0431: `@isolated(any)` Function Types
Swift uses its type system to model concurrency. An integral part of that system is **functions**. Swift’s ability to model how functions can behave has expanded pretty dramatically lately. Except, there’s a substantial gap. We’ve seen many new facilities for expressing concurrency in function _declarations_.
This proposal adds a new capability to function _values_.
Index:
* SE-0401: Remove Actor Isolation Inference caused by Property Wrappers
* SE-0411: Isolated default value expressions
* SE-0414: Region based Isolation
* SE-0417: Task Executor Preference
* SE-0418: Inferring Sendable for methods and key path literals
* SE-0420: Inheritance of actor isolation
* SE-0421: Generalize effect polymorphism for AsyncSequence and AsyncIteratorProtocol
* SE-0423: Dynamic actor isolation enforcement from non-strict-concurrency contexts
* SE-0424: Custom isolation checking for SerialExecutor
* SE-0430: `sending` parameter and result values
* SE-0431: `@isolated(any)` Function Types
* SE-0434: Usability of global-actor-isolated types
# The Problem
Every declaration in Swift has some well-defined static isolation. You can **always** determine what the isolation is through code inspection. Closures, however, are special. Their isolation is influenced not just by _where_ they are defined, but also by _what_ they capture.
This sounds complicated. But, in practice you rarely need to understand or even think about these details. All you need to know is this:
The context of a closure definition matters, but that context is also **lost** when you pass it around.
func scheduleSomeWork(_ f: @escaping @Sendable () async -> Void) {
// We've lost all the static isolation information
// available where f was defined.
Task {
await f()
}
}
func defineClosure() {
scheduleSomeWork { @MainActor in
print("I'm on the main actor")
}
}
Here, we’re defining a closure which will run on the `@MainActor`. But, that isolation is only statically visible in `defineClosure`.
At this point, you may be thinking “okaay, but I don’t get why this is a problem”. And, I’m not surprised, because there aren’t too many situations where this will matter. There is, however, one really important place where it makes a big difference: the `Task` creation APIs.
These create a new top-level asynchronous task. But, which actor should that task run on? This information is encoded in the closure body. When looking at the function’s _type_ , it’s completely invisible.
But `Task` has to start somewhere, so it first begins with a global executor context. And then the very next thing that happens is the closure hops over to the correct actor. This double hop, aside from being inefficient, has a very significant programmer-visible effect: `Task` does not preserve order.
Task { print("a") }
Task { print("b") }
Task { print("c") }
The ordering here is not well-defined. I have, personally, found this to be extremely difficult to deal with. It makes it incredibly hard to introduce async contexts incrementally. And honestly it’s just really confusing.
# The Solution
This proposal makes it possible to inspect a function value’s isolation. A closure annotated with `@isolated(any)` can expose its captured isolation _at runtime_.
func scheduleSomeWork(_ f: @escaping @Sendable @isolated(any) () async -> Void) {
// closures have properties now!
let isolation = f.isolation
// do something with "isolation" I guess?
}
When I first saw this, my initial reaction was confusion. Closures have properties? That looks weird. And then I was like, yeah it’s just a type of course it can have properties. It’s actually kind of weird they **didn’t** have properties before. The type of the `isolation` property matches isolated parameters: `(any Actor)?`.
Aside from making this property available, this annotation has a small effect on semantics. Adding `@isolated(any)` to a closure means it **must** be called with an `await`. This is true even it does not cross an isolation boundary.
# The Implications
I think it was one of those problems that had a bunch of superficial solutions. But, to me, this looks like the exact opposite. This is a deep, fundamental extension to function types. **A lot** of thought went into this proposal. This could have easily been just `@isolated`. But, it is leaving the door open for a future revision that can capture not just the isolation value but also its **type**.
Undefined `Task` ordering has caused me **a lot** of issues. It took me a while to even realize it was happening. Thanks to this proposal, `Task` can now **synchronously** enqueue work onto executors.
However, I really do want to stress that “well-defined” ordering for `Task` creation is not the same as “FIFO”. A high priority task can still execute before more-recently-created lower-priority tasks.
# Will it Affect Me?
You definitely want to adopt this if you are passing a closure parameter directly into one of the standard library’s task creation APIs. Aside from that use-case, I still don’t have a great feel for when or why you would choose to annotate a parameter with `@isolated(any)`. I don’t think there are any _downsides_ if the closure is already `async`. And, it does buy you some future flexibility. But, I wouldn’t recommend it unless you have a clear idea of why it would be necessary.
Task { print("a") }
Task { print("b") }
Task { print("c") }
But, while we’re all thinking on that, let’s also take a moment to celebrate that when compiled with Swift 6, this now always prints:
“a” “b” “c”
🎉
(Update: I always forget that this ordering applies **exclusively** to isolated contexts. Without an actor, `Task` execution order remains undefined.)
* * *
Did you know that I do consulting for concurrency and Swift 6 migrations? If you think I could help, get in touch.
Maybe this one is actually `isolated(any)` https://www.massicotte.org/concurrency-swift-6-se-0431
04.11.2025 14:01 — 👍 0 🔁 0 💬 0 📌 0
Alternative timeline: SJ insists that 3rd party iPhone apps do not get a native framework but have to be written in HTML5 as originally intended.
04.11.2025 02:48 — 👍 0 🔁 0 💬 0 📌 0
Just in case this isn’t clear, this is not about how things are implemented, Apple obviously has incredibly smart people working on this, but why.
04.11.2025 02:40 — 👍 0 🔁 0 💬 0 📌 0
There is actually the usually long word for what Swift is in German: “Arbeitsbeschaffungsmaßnahme”. 🙃 Which is nice, kinda.
04.11.2025 02:30 — 👍 1 🔁 0 💬 1 📌 0
Original post on mastodon.social
Swift was introduced over 10 years ago. Promising better software quality due to the extensive static type checks, optional checking, etc over Objective-C.
Given the scope of the effort, surely the overall quality of the software in the Apple ecosystem should have improved significantly. Right? […]
04.11.2025 02:15 — 👍 1 🔁 1 💬 2 📌 0
Original post on mastodon.social
Every other hour I'm close to give up and just badge Sendable on a type, piece of mind. Maybe even adding Mutex's to make the compiler stop complaining, even though it is conceptually guaranteed to not be necessary. The most fun thing here is that a Mutex does NOT actually make a thing […]
03.11.2025 21:15 — 👍 0 🔁 0 💬 0 📌 0
Original post on mastodon.social
I'm really trying to keep my types non-sendable, as that seems like the best thing for most non-primitive stuff, but it is really, really hard and I may give up.
Originally I thought that for example one HTTP transaction (working the request, sending the response) should strictly stick to just […]
03.11.2025 21:10 — 👍 1 🔁 0 💬 1 📌 0
