Hello 
I recently stumbled upon the CodeCrafters platform and have really enjoyed my time with it so far - really fun and engaging way to learn interesting technologies!
I’ve got an extensive background in Swift and noticed that Swift isn’t enabled anywhere on the site at the moment. From digging around the language support dashboard, frontend challenge language release status, and some other links I can’t provide because I’m a new user, I can see a couple of the challenges have the code and resource files necessary to support the language, but are not presented to the user due to it being flagged as an Alpha status (instead of Beta or Live).
What is still needed to move these out of an Alpha status for general availability when choosing challenges? If there’s anything I can do to help with the ones already in an Alpha status to move them forward, I would be happy to. @rohitpaulk, I saw that you were in quite a few conversations surrounding language support on the forums - perhaps you know?
Secondly, are there any general guidelines or recommendations for the language versions we should be using? The dashboard I linked above seems to suggest it’s preferred to be on the latest release version where possible.
Otherwise, it seems like I could help by providing the necessary code files and resources for some of the other projects if I’d like to see Swift availability. So I can focus some of my free time there in the meantime.
Thanks for any clarifications that can be provided.
1 Like
I opened a couple PRs to help get the ball rolling and to make things easier for adding Swift to other challenges as they begin to support the new build system overhaul.
3 Likes
Hey @JWShroyer – thanks so much for these! The language-templates repo has zero documentation so I can imagine this’d have been a pain to figure out 
The last time we looked at Swift, we ran into issues with caching dependencies (Swift language added to Redis Course by bobvoorneveld · Pull Request #148 · codecrafters-io/build-your-own-redis · GitHub). I’d like to figure this out before shipping starter code that makes it look like users can add dependencies.
Could you try adding a sample dependency (swift-nio maybe, since it’s large) and see if you can get caching working? The Redis challenge could be a good place to test this since swift-nio will be required to pass the first stage. Once we’ve got dependencies working on at least one challenge, should be straightforward to add support to all - only the code file needs to change, language-templates should automate the rest.
1 Like
@rohitpaulk, got it. I’ll take a look sometime today or tomorrow to see if I can’t get that working well. Thanks for the callout.
2 Likes
@rohitpaulk, I updated the language-templates repo to address the dependency caching and used this to test the build-your-own-redis repo with Swift support. I opened a PR for it (for some reason the forum is blocking me from linking to it - PR #261 in that repo)
With swift-nio as a dependency, I was able to run the starter program and the solution program in 12 seconds combined when invoked from the course-sdk test swift command.
I also went ahead and updated the BYO interpreter PR linked in a previous message to use the script changes I made to the language-templates PR.
Let me know if there’s anything else I can help with so we can easily bring Swift to the other challenges.
2 Likes
Thanks so much for the PRs @JWShroyer! I’ve merged both in alpha status and added you as a tester so you should be able to start using them.
I’m still running into long build times with Redis when testing on production, I’ll look into this in more detail tomorrow. I think we might be running into the inodes changing issue described here: Incremental builds with Swift Package Manager and Linux / Docker - Using Swift - Swift Forums.
1 Like
@rohitpaulk - Hmm. I saw that yesterday, but when digging into the problem, I saw mention that the issue should be resolved in Swift 5.10+.
Even so, perhaps the right approach is to mount a volume with the cached build data like shown in your link.
The mounting volume thing actually might not be feasible for us (we use firecracker VMs, so the whole image gets stuffed into a rootfs before executing). I’m sure there’s some way out here though.
Got a minimal repro setup to start with: Trigger swift cache bust by rohitpaulk · Pull Request #263 · codecrafters-io/build-your-own-redis · GitHub. Will dig deeper tomo!
2 Likes
Appreciate it, @rohitpaulk!
In the meantime, what else would be needed to help bring Swift officially to CodeCrafters? Sounds like you’ll be looking into the existing caching issue soon when in a production environment.
I could potentially help with bringing swift to some of the other challenges using what we have in the meantime.
What’s still unclear to me, is what would be needed to get any of these alpha status Swift challenges promoted to Beta for general availability. Do we just need to solve the caching problem or are there other criteria you look for?
1 Like
Just caching! Nothing else I can think of that’d be a blocker.
There’s no strict criteria, it’s just that we don’t want to falsely advertise that something works (people often make purchase decisions based on language availability) when we aren’t sure it does 
1 Like
Okay, no luck so far with caching - will look at this again next week with a clear head!
1 Like
Stumbled upon a bug that might be related to this… When copying over assets from /app-cached, our production test runners end up changing the file modification times, but CI doesn’t. We ran into this with builds for C using vcpkg, and just deployed an update to fix this.
In my minimal repro too, I was able to replicate this: adding -p to cp doesn’t trigger the bug: Trigger swift cache bust by rohitpaulk · Pull Request #263 · codecrafters-io/build-your-own-redis · GitHub.
Will give this a go on our test runners soon!
Argh, that didn’t turn out to be the fix. Looks like we aren’t using /app-cached at all here, hmm. Must be something else going on!
Just noting some observations for later:
- Edit the
.codecrafters/compile.sh script to add ls -lah /tmp/codecrafters-build-redis-swift and we can see the files that were modified:
build.db has changedrelease.yaml has changed
- Diffing these files might yield more insight into why this happens
- If we run swift build twice within
compile.sh, the second step is cached. So this definitely implies some kind of difference between the docker build environment and the final runtime env.
- Within
compile.sh, using mv /tmp/codecrafters-build-redis-swift /tmp/old && cp -R /tmp/old /tmp/codecrafters-build-redis-swift triggers a rebuild
- Within
compile.sh, using mv /tmp/codecrafters-build-redis-swift /tmp/old && cp -p -R /tmp/old /tmp/codecrafters-build-redis-swift does NOT trigger a rebuild
Additionally, doesn’t look like any permissions have changed for the root files at least:
Hey, sorry. Just wanted to give an update that I started a new job so I’ve been a bit busy getting ramped up. Will try to find some time this weekend to help out if possible.
