[ChrisMarshallNY]

> aimed at app developers

I'm a native Swift app developer, for Apple platforms, so I assume that I'm the target audience.

Apps aren't major-league toolsets. My projects tend to be fairly big, for apps, but the compile time is pretty much irrelevant, to me. The linking and deployment times seem to be bigger than the compile times, especially in debug mode, which is where I spend most of my time.

When it comes time to ship, I just do an optimized archive, and get myself a cup of coffee. It doesn't happen that often, and is not unbearable.

If I was writing a full-fat server or toolset, with hundreds of files, and tens of thousands of lines of code, I might have a different outlook, but I really appreciate the language, so it's worth it, for me.

Of course, I'm one of those oldtimers that used to have to start the machine, by clocking in the bootloader, so there's that...

[josephg]

I tried to fix a bug in Signal a few years ago. One part of the code took so long to do type inference on my poor old Intel MacBook that the Swift compiler errored out. I suppose waiting was out of the question, and I needed a faster computer to be able to compile the program.

That was pretty horrifying. I’ve never seen a compiler that errors nondeterministically based on how fast your cpu is. Whatever design choices in the compiler team led to that moment were terrible.

[ChrisMarshallNY]

That sounds like Web sites, designed by designers with massive monitors.

The tools team probably had ultra-fast Macs, and never encountered that.

It definitely sounds like a bug in the toolset. I hope that it was reported.