Hacker News new | ask | show | jobs
by grenran 478 days ago
> Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.

Sounds quite slow

4 comments

My guess is 30k is their code, but their dependencies are much larger and 10 mins includes a clean build.

I also wonder if that's developer machine time, or CI build job duration.

Hopefully developer incremental builds are much faster.

Yea, sounds painful. That’s only 50 lines of code per second.

Swift is the slowest on the compilation benchmarks at https://github.com/nordlow/compiler-benchmark.

They should re-write that in Go and get a <10s compile time. And a binary size less than half of that.
And lose the type system, same language as their client apps, the ability to write nice abstractions, etc.

Go is a set of trade offs like every language, and clearly the wrong set for this team.

The trade off for build time here is horrendous and meme worthy. It just shows Swift is not ready for server side. 10m for 30,000 lines of code just causes health issues like high BP for developers.
I have a codebase of a similar size, using the same web framework, and my codebase does a full clean build on my Macbook Air in less than 2 mins. A re-compilation dev build is ~5 seconds.

I'd guess the 10 mins is a few things... Vapor, and in particular its ORM Fluent, are noticeably slow to compile. It's common for a single function doing an ORM query to take 200ms to compile. I use warnings for >100ms compilation to spot these and adding a few types or extracting a piece into a utility function solves it. I'd guess they also have a ton of dependencies. I have ~20 or so, most aren't very big.

At work I use Go, and while builds are fast, on a medium sized codebase with a bunch of codegen, the difference for dev builds doesn't affect my workflow.

There's a debate to be had around whether Swift is ready for the server (I'm a strong advocate for yes, but it's not a done deal), but honestly compilation time isn't a factor. Rust is noticeably slower in my experience and I don't see people questioning whether it's ready for server development because of it.

Modula-2, Delphi and Turbo Pascal were already doing circles around Go compile times with hardware running at a fraction of today's hardware, in much more feature rich programming languages.

Swift has definitely a problem, a toolchain problem, not a language one.

It is a slow to compile language, and that's my primary complaint about it. If you have basic errors they come back very fast, and code that compiles often works the first time, but still. If not for this quality it would be my clear favorite language.
Luckily, compile speed is something that can be mostly solved by throwing money (and faster hardware) at the problem.