Yeah, 30kloc really isn’t very big… I regularly work with a ~14 kloc C++ code base which builds in 15 seconds on my 3.5 year old laptop, and a ~20 kloc code base (+ vendored catch2, + auto generated protobuf code) which builds in just under a minute on the same laptop. And C++ isn’t exactly known for its fast compile times either. 10 minutes is an eternity, and I imagine Apple gives its developer significantly more powerful machines than my 2021 M1 Pro.
I want to add: the auto generated protobuf code is 39kloc across 24 source files. I didn’t know it was that much code. So in total it’s 59 kloc, twice as much as the Swift code base in the article.
I can’t find build time benchmarks but both communities are of the opinion compile times are not good enough. In this project’s case I suspect the ten minutes includes pulling their dependencies and building them too, which is the norm with SwiftPM.
I’m a bit surprised by the “predictable memory management” part. Is that something that important if you don’t have precise hot loops and latency requirements ? I was under the impression that GCs were good enough for low latency pauses now ?
They tell me modern GC is damn good enough, so I would think you’re right.
But this team made the leap from Python 2, so maybe their point of comparison is not a current one.
Xcode’s tooling for finding and fixing leaks is also excellent; it matured when it was really necessary before ARC existed. I would be confident that if your metrics showed undue growth you could locate and solve it.
I guess you’re right, I just find it a bit odd as if they didn’t test other programming languages on that account. That being said, I understand the part where using a single language on the “front” and back helps.
10 minutes of just build time would be too much for me…
Yeah, 30kloc really isn’t very big… I regularly work with a ~14 kloc C++ code base which builds in 15 seconds on my 3.5 year old laptop, and a ~20 kloc code base (+ vendored catch2, + auto generated protobuf code) which builds in just under a minute on the same laptop. And C++ isn’t exactly known for its fast compile times either. 10 minutes is an eternity, and I imagine Apple gives its developer significantly more powerful machines than my 2021 M1 Pro.
Yeah, 50 lines per second.
Swift has ridiculous compile times.
60 MB binary also seems excessive for 30KLOC.
Only 4x faster than (interpreted) Python 2 also seems a bit on the slow side for the a compiled language. Unless it’s all DB access or other I/O.
I want to add: the auto generated protobuf code is 39kloc across 24 source files. I didn’t know it was that much code. So in total it’s 59 kloc, twice as much as the Swift code base in the article.
That is kind of long! But I assume that’s a clean build; hopefully incremental builds are a lot quicker.
Compile times are my main complaint. If not for that it would be my clear favorite language.
Is this worse than Rust?
I’m compiling 12,000 lines in five seconds on an ancient Mac Mini. No dependencies outside the standard library though.
I can’t find build time benchmarks but both communities are of the opinion compile times are not good enough. In this project’s case I suspect the ten minutes includes pulling their dependencies and building them too, which is the norm with SwiftPM.
I’m a bit surprised by the “predictable memory management” part. Is that something that important if you don’t have precise hot loops and latency requirements ? I was under the impression that GCs were good enough for low latency pauses now ?
They tell me modern GC is damn good enough, so I would think you’re right.
But this team made the leap from Python 2, so maybe their point of comparison is not a current one.
Xcode’s tooling for finding and fixing leaks is also excellent; it matured when it was really necessary before ARC existed. I would be confident that if your metrics showed undue growth you could locate and solve it.
I guess you’re right, I just find it a bit odd as if they didn’t test other programming languages on that account. That being said, I understand the part where using a single language on the “front” and back helps.