llvm-pretty-bc-parser VS swift

Interestingly llvm-hs seems to have gotten a new maintainer which has ambitious ideas like using it for GHC and absorbing the bytecode parser llvm-pretty-bc-parser.

It's actually interesting how many independent implementations of bitcode writers there, given that there are almost no independent bitcode readers (mine is very preliminary, and then there's one from Galois[1]).

I believe Swift also does their own serialization in LLVM's bitstream format[2]. I also saw an implementation of the writer in Swift, but now I've lost it.

[1]: https://github.com/GaloisInc/llvm-pretty-bc-parser

[2]: https://github.com/apple/swift/blob/main/docs/Serialization....

Beyond the marketing view... here are the (incomplete) changes:

  https://github.com/swiftlang/swift/blob/main/CHANGELOG.md

But even if you set the optimisation level to -Osize or -O as far as I know there is no guarantee that tail calls will be optimised: they aren't mentioned at all in the Writing High-Performance Swift Code article of the Swift documentation, and I have only been able to find an ancient proposal in the Swift Forums regarding this (where they mention Scala's @tailrec by the way) that was apparently closed without being implemented.

Toady I used GLM 4.7 to port a C++ project of mine to Rust, so I could read and toy with it, to get into the language: https://codeberg.org/RickStanley/agatetepe-rs.

Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).

Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try, this time, without much of A. I. assistance, if I could help it.

I'm using an qcow2 Debian trixie arm image in UTM as playground. I found out that there is no packaging for Debian at the time of this writing: https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/

    curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \

Source code: https://github.com/swiftlang/swift/blob/256ff127c93d7e59a75f...

I'm not sure what the parent commenter meant when they claimed that "Result of yours is a Result (e, t) in Haskell." In Haskell, `(e, t)` would be the pair type (the binary product type).

Apple does provide a "permissive guardrail mode" as per:

https://developer.apple.com/documentation/foundationmodels/i...

This does end up allowing some texts to work. However, it still failed for some other ones. That's when I gave up on using Apple's foundation models and switched to the Qwen3 8b model which had no such issues. It's pretty sad how the Foundation Models have so much potential but Apple has severely neutered them.

I originally tried the apple foundation models on my newer mac with m4 chip and once I had the issue with their guardrails, I decided to just switch to Qwen model which runs on Intel and used my old Mac mini for it.

An issue I ran into was that my Swift app was intermittently crashing. Root cause were two issues:

1. First one had to do with accessing the SQLite database from multiple threads. Apparently, for multi-threading use, SQLite needed to be initialized with a `SQLITE_OPEN_FULLMUTEX` flag.

2. Second one was a "Bad file descriptor" error from the macOS operating system itself. Had to do with a possible bug in Process.run() which would cause it to crash after some time:

https://github.com/swiftlang/swift/issues/57827

Was able to fix it using the above workaround/solution of "fileHandleForReading.close()".

Lets see how long the site stays alive now without crashing :)

Feel free to ask questions.

And it's all open source! You can go wade into the swiftlang/swift repository if you're feeling brave. For a slightly less terrifying deep dive, check the official Swift compiler documentation.

Swift is mostly runtime-enforced now but there are a lot of cultural affinities (for lack of a better term) between Swift and Rust and there’s a proposal to add ownership https://github.com/swiftlang/swift/blob/main/docs/OwnershipM...

I had a very similar thought (which I removed from the final draft)

Yesterday without searching this prompt was able to speculate that my query about static vars on Swift actors was a sign of an underlying compiler bug.

Turns out, it WAS a compiler bug and fixed back in February. I have never found a compiler bug and I'm a Swift noob, but I was pretty impressed. (It's what led me to write this post) https://github.com/swiftlang/swift/issues/78435