Using swift on windows, expectations, reality

Using Swift
1

Let me preface this by saying that this is not really a criticism of Swift. I started experimenting with the language a few months ago and I absolutely loved most things about it.

However, I came across a few issues which made me lose interest in continuing my project in Swift, and went back to the previous language I was using. However, if there were workaround for these issues then I'd definitely reconsider using swift for that project.

For some background, I'm working on a somewhat low level (for now) - code first game framework. I'm implementing it in the Beef programming language.
I'm mostly satisfied with what Beef offers, but have some concerns. It's mostly developed by a single person. Having a bus factor of 1 is risky IMO. The ecosystem is also immature at the moment. I've had to create my own bindings for all the low level libraries that I wanted to use (win32, SDL, Vulkan, dx11/dx12, OpenGL, OpenGL, spirv stuff, glslang, detex, among others.

Reasons I looked at swift include the advertised C and C++ interoperability, recent improvements in windows support, and I don't think swift will be disappearing or that development will languish any time soon.

I tried porting the core parts of my existing work so far in Beef. Going in, I expected some productivity loss since I'm just learning the language. However, it was more than I bargained for.
The first problem is that compile times are bad... I mean really bad compared to what I was getting with Beef.
Now I don't know if this just happens with the tooling on Windows, or if there is a problem with my setup, or how I've configured my project (maybe someone could say? GitHub - jayrulez/sedulous-swift: Sedulous, but in Swift). Making small changes and watching the project take multiple seconds to compile is :triumph:. In Beef, I get near instant compilation for similar changes.
Is this normal?

Next problem is with bindings to C libraries. It's great that I can include a C header in my build pipeline... But I want to work in idiomatic Swift. Code made available from C headers is not that. There doesn't seem to be a way to declare a struct/enum/union in Swift that is C compatible. Beef has an annotation (CRepr) and I believe Rust has something similar that tells the compiler to treat the type like its C counterpart in memory. I'd like to build these external libs outside of my swift project build system, then just link a .lib or .DLL/.so/dylib, and declare the required types for Interop in Swift. There's a way to link to external functions but I was advised to not depend on it, because it's not part of the public API (@_extern IIRC).

Also, the tooling seems finicky when it comes to these bindings I've added for Swift so far (Vulkan, sdl2). Half the time, autocomplete for the Interop types doesn't work. When it does, it's mostly delayed. Sometimes I have to restart VSCODE to get it to work. Again, I don't know if I have a broken setup here.
Additionally, there aren't as many low level bindings (at least for the domain I'm working in) available as I thought there would be for a language as popular as Swift. I won't complain about that too much though, because at least I can provide my own.

Does anyone else have this kind of experience with Swift? Especially the slow compile times?

I'd love if there were solutions or alternative approaches that would allow me to continue working in swift without the productivity loss.

2 Likes
2

I think slow compile times are expected, due to compiler architecture - LLVM backend et al.

1 Like
3

Hi Robert, would love to know a bit more about your experience. As you've noted, we've done a lot over the last few months to improve Windows, so I'd like to make sure you're running on the latest toolchain. We'd love to keep you working and successful here! Can you give an example of some Windows APIs that you're struggling to bind to?

4

It's great that I can include a C header in my build pipeline... But I want to work in idiomatic Swift. Code made available from C headers is not that. There doesn't seem to be a way to declare a struct/enum/union in Swift that is C compatible.

While you can’t directly declare a type in Swift that can be used in C, you can still use a number of attributes in your headers to improve the declarations for Swift. Specifically, there are a number of attributes to improve enums that you can copy+paste+rename in your project, and there are several more for renaming declarations. There is some documentation on the Apple documentation site which is focused on the Objective-C use case but they work just as well with plain C: Objective-C and C Code Customization | Apple Developer Documentation

You can also write extensions in Swift directly if you don’t need to share functionality with other languages.

5

Don't bet on this horse.

6

Thank you. I will take a look at these links.

7

I'm assuming this is something that will just work once all the kinks are ironed out.

8

The issue is not windows APIs per se. The problem I have is that I can't work solely in Swift, as well as the tooling. I still don't know if my setup is just broken or if the tooling on windows is just finicky.

I was using the latest snapshot available at the time.
I will check if there's an update and try get things up and running again to see if anything changed.