I've been spending the last couple weekends porting Thorsten Ball's Monkey language (from the texts Writing an Interpreter in Go and Writing a Compiler in Go) t

I've been spending the last couple weekends porting Thorsten Ball's Monkey language (from the texts Writing an Interpreter in Go and Writing a Compiler in Go) to Swift. A year ago I spent a few weeks playing with Swift on the server but never really made anything happen with it, so this has been my real nuts and bolts introduction to the language. I found it to be pretty neat, but it's very difficult to determine whats allowed to use outside the Apple ecosystem. The documentation is sporadic and there is only a reference manual. It makes me long for the Rust Book, with its tutorial style introductions. There are of course plenty of Swift tutorials out there, but they expect 1) you want to write an iOS App, and 2) you've never programmed a day in your life before. The "standard library ecosystem" is very confusing. There's the actual language standard library, which is much like "core" in Rust. Then there's Apple's "Foundation" library, which is the more "batteries included" type standard library most people look for in a language. But "Foundation" isn't... straightfoward to understand. First of all, there's two completely separate implementations. On Apple platforms, you get the real Foundation, implemented in Objective-C with no source code available. On Linux, you get "swift-corelibs-foundation", which is fully open source and written entirely in Swift (really nice to look up what it is actually doing). But swift-corelibs-foundation has a lot of missing features. To figure out if you're allowed to use something, you better be ready to look up the source code and see if its actually implemented on the Linux version. Or study a very long complicated markdown table in the github repo where they track what they've ported. Want to develop on your MacBook but deploy to Linux? Better set up a complicated Docker environment so that you can actually see how your code will run with swift-corelibs-foundation. You _can't_ import or build against it on Apple platforms. A lot of people learn a programming language by spending a lot of time reading the standard library. Well, it's nice that swift-corelibs-foundation is open source and publicly accessible and written in Swift. Unfortunately, it's not a great place to learn swift. Since it's a reimplementation of Foundation, which is itself a port of the Objective-C "Foundation Kit" library, its full of non-swifty concepts and ideas. There are, MOSTLY, more Swifty method implementations hanging off of the Foundation types, but there are also countless bits of API that take unsafe pointers or are fully deprecated and you must learn to ignore (looking at you, NSZone). Learning Foundation is no easy task either. You can read the swift-corelibs-foundation source, of course. But since it's Swift, types are frequently re-opened and extended in other files so there's no one place to view the entirety of a type. There are the Apple developer docs, but theres no location where they list all the types in Foundation, or all the methods/properties on a type. The docs are handwritten, not generated from comments in the code. Apple recently released "DocC" to generate docs from swift libraries, so I'm hoping this one changes soon. There's the venerable swiftdoc.org which has generated documentation, but it only covers that "core" standard library. Also, certain symbols constantly 404 on it. Thankfully, implementing a simple bytecode compiler doesn't require much beyond the standard library types. I still occasionally have to import Foundation, but its mostly just to get a single method here or there on a stdlib type, not to use some complicated NSObject based "class cluster". I'm hopeful that good interop frameworks drive more folks to use the language outside Apple platforms, and real investment gets put into these issues. Don't get me started on XCTest on linux...