I already have that with my Apple devices, kind of. I can drag my mouse from my MacBook Pro to my iPad, use my iPad (or Vision Pro) as a secondary monitor, or the same with my Mac mini, I can start a document on one platform and continue it on another…

All in all I love the ecosystem, it’s very convenient.

More about the Julia set [0]

[0] https://en.wikipedia.org/wiki/Julia_set

Xcode is also definitely absolutely not required for using Swift.

> obviously one of the most important things because it gives you back time to invest in other parts of your project

That is until you get so deep in code debt that you cannot move anymore.

There is an equilibrium to be found. Faster is not always better, and trying to have every single line perfect is not good either.

I did mention trade offs.

Yeah. Exactly the same as there should never be an “artisan era” for chairs, tables, buildings, etc.

Hell even art! Why should art even be a thing? We are machine driven by neurons, feelings do not exist.

Might be your life, it ain’t mine. I’m an artisan of code, and I’m proud to be one. I might finally use AI one of these days at work because I’ll have to, but I’ll never stop cherishing doing hand-crafted code.

>> Yeah. Exactly the same as there should never be an “artisan era” for chairs, tables, buildings, etc.

That's funny you bring up those examples, because they have all moved on to the mass manufacturing era. You can still get artisan quality stuff but it typically costs a lot more and there's a lot less of it. Which is why mass-manufacturing won. Same is going to happen with software. LLMs are just the beginning.

Did you get the Eames version of Windows, or a knockoff?

Windows was probably the worst example you could use in this context!

Oh no, but I know! And it is indeed terrible.

I live in a city where there are new houses being built. They are ugly. Meanwhile, the ones that exist since a long time ago have charm and feel homely.

I don’t know, I‘m probably just a regular old man yelling at clouds, but I still think we’re going in the wrong direction. For pretty much everything. And for what? Money. Yay!

Hugh.

You're continuing to make good arguments for why mass-production should exist _alongside_ artisanal craftsmanship. Broad availability of housing which is functional, albeit of questionable aesthetic appeal, is a good thing to improve housing availability[0]; and also it is a good thing for (fewer) well-built, charming, individual homes to be available for those who want to spend more and to get more.

[0] I'm extremely aware that there are other contributing factors to housing shortages. Tax Billionaires, etc. My metaphor still works despite not being total.

The difference is that end users don't interact with the code that the artisan created, and don't care what it "feels like". One type of code that I do agree should be artisanal is the interface end of libraries.

Yes, it's like artisanal plumbing or electrical wiring... all hidden behind walls. A plumber might take pride in the quality of his soldered joints, but artisanal? Who wants to pay for that?

Except I did and it was good. When did you last try?

It’s what I do, every day. You maybe in need of a broader horizon for comparison

I’m sorry but reading your comment, you have not understood much about Swift (and GCD).

In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.

> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.

If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).

> We never got the profiler to produce anything intelligible after days of trying

You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.

> The very worst part of Swift were the thread control

Already talked about that one, but Swift has async/await now, also.

Async/await is not a solution to poor thread models.

Async/await is cooperative multitasking and is no help at all for cpu bound problems.

For i/o intensive systems it makes non-blocking i/o look like blocking i/o, and people find that helpful.

I do real-time i/o so I need more control and Async/await is unhelpful.

It is a worthy adition to Swift I agree. But they sorely lack Rust's excellent design in this area

I use async/await for my CPU bound problems and it works fine

So long as you "await"

Not really concurrent

Not very well known, but Swift has two builtin concurrency systems (in addition to the very well known async/await for parallelism): async let (not very flexible) and task groups (much more so).

You don’t have to await immediately!

Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…

Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).

All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.

I don’t which Swift developers you are talking to, but let the record know I don’t and use enum quite a lot. And I don’t find it particularly painful though a bit verbose at times.

I think Swift enums are really well designed, but SwiftData doesn't really support them unfortunately and Observable has problems with reactivity and enums (works on iOS not macOS I've found).

So lots of optionals might well be the better path here.