I don't think top-level code should be exempt from concurrency checking; I'd rather explore ways to make the code naturally free of data-races, such as by inferring that everything written in top-level code is main-actor isolated. The program starts on the main actor, so until you explicitly introduce concurrency, everything you write happens on the main actor. If everything is in the same isolation domain, there's no risk of data races, and the concurrency checks will never be surfaced. There are interactions with other language features that I mentioned upthread that would prevent this (such as conforming main-actor-isolated types to nonisolated protocols), but those are restrictions that I believe we can lift.
29 Likes
My answer was for discussion that veered off course. To be exact, question was:
and it's actually interesting, was looking for answers. Can't answer myself atm, as I don't have any experience teaching Swift to kids or opinion on that, but I'm wondering how people view new language features. Or to rephrase—why do people consider some features hard to understand? Guess assumption that kids won't understand comes from here.
3 Likes
I think this is exactly the right mindset. Thank you!
I'm very into these kinds of ideas!
I have worked with a fair number of beginners on programming exercises using Swift. Playgrounds is pretty commonly-used, but I think globals and the single-file workflow are also really important. Anything that could be done to make this smoother would be very welcome.
15 Likes
Both excellent points! I like the approach you suggest for top level code.
2 Likes
What do you include in "everything" here, is it just variables, or functions too, or everything-everything, i.e. structs/classes/enums/protocols as well?
If it's only say vars (also non-sendable lets?), seems like it might work. I think it will get trickier with global functions: you may want to have pure global functions that can be called from anywhere so confining them to MainActor would seem like an unnecessary limitation. On the other hand, newcomers writing code in "tutorial mode" and referring global vars will get confused by the error messages. Which would make the whole idea of "MainActor by default" kind of useless.
The consequence of calling the function from anywhere is introducing concurrency to a program and the initial inference wouldn’t apply anymore. Which also might have the same overwhelming effect of getting a lot of errors once you reach this point — yet this also matches better to progressive disclosure.
2 Likes
For my part, I really like @hborla's take on this issue.
Strict concurrency is a valuable feature, but it would be helpful if it remained largely implicit in simple programs.
1 Like
A C background certainly helps getting started with Swift but a coding experience in any language may do because it teaches to think in a certain way.
The learning curve with Swift is steep. But why not taking the challenge? How fast and how well one gets familiar with the language very much depends on the quality of the material used for learning. That’s my experience. And there is a lot of great Swift tutorials and other stuff available.
1 Like
In my opinion, Swift is becoming better and better for a first choice of language, because it is more versatile than ever.
My take on "a good first programming language" largely depends on what you can do with it. Of course it has to be easy to understand and also has to help you gain useful knowledge in the long run, but if you are gonna learn a thing and can't do anything with it it would be so boring.
Swift has all of the following:
- Native UI Framework for Apple platforms (SwiftUI)
- Game engine support (SwiftGodot)
- Good scripting and REPL support (Playgrounds,
swift repl, and an excellent community project swift-sh which lets you use Swift as a powerful scripting language.) - Production-ready Server framework (Vapor, Hummingbird)
- Not yet easily usable, but hopefully will be more accessible in the near future - DIY hardware projects via Embedded Swift
- Now platform-agnostic standard library that is bootstrapped in Swift so you can actually read it and learn advanced Swift - the new Foundation
- All that and also every C and C++ libraries you can imagine.
- Skia via SkiaKit
- raylib via Raylib for Swift
- miniaudio by my package Lullaby, although it's not a direct wrapper.
- and also you can use almost any library that has C/C++ interface.
It does lack in certain parts - especially GUI programming for non-Apple platforms - but if you are an Apple user you will certainly have fun time.
Regarding comp-sci concepts like pointers and data races, I think when you are comfortable enough in Swift language, you can check out WWDC talks where the engineers who worked on the language and the compiler talks about how Swift handles actual data and instructions under the hood.
- An almost-lost knowledge, "Protocol-Oriented Programming in Swift" from WWDC15 (it might go down in the future. It's not available on the official Apple Developer website.)
- An oldie but a goodie, "Understanding Swift Performance" from WWDC16
- "Unsafe Swift" from WWDC20
- "Explore structured concurrency in Swift" from WWDC21
Those and more WWDC sessions helped me learn about computer science more than any other sources. But I recommend anyone first learning Swift to not watch anything but the very recent sessions, since old WWDC sessions tend to have outdated Swift syntaxes. (like let something: Protocol instead of let something: any Protocol)
8 Likes
Brilliant solution to the top level code been dreaming about it since swift concurrency was introduced! How we can make it happen?
1 Like
I'd say yes.
Especially if you limit yourself to a small subset of the language (YMMV what should be in that subset).
@Jae - You've listed a bunch of stuff that sounds impressive, but I'm not sure how familiar you are with the items on the list.
SwiftGodot is a work in progress. There are no books on how to use it (the project is way too small), and it would substantially complicate learning Swift. It's not beginner friendly.
The Raylib for Swift bindings are not actively maintained. There are longstanding issues (like the bindings break if you await stuff) that nobody ever responded to.
I don't want to criticize someone for being enthusiastic about Swift in the Swift Forum. I just have to push back a bit, having tried some of the items on the list. Any project that lacks extensive documentation and an active community isn't great for beginners.
1 Like
Yeah that's fair. I should've mentioned that a lot of Swift projects are unmaintained.
But In case of SwiftGodot, even though it's fairly new and a WIP, it's still very usable - I've used on my project and it was a fun experience.
Also, like you said about SwiftGodot, not everything on my list is beginner-friendly. I was just pointing out that learning Swift can take you far in the long run. If you are just starting out, I'd definitely recommend learning it for Apple-platform specific dev since it has the most learning resource.
2 Likes
@Jae - That's interesting.
I'm fairly experienced (15 years programming, though only a couple with Swift), but I have a kid that wants to make games and learn coding. That was what led me to ask about Swift 6.
I was looking into Raylib bindings, but maybe we should try SwiftGodot. It may be possible for me to set things up, so my son doesn't need to worry about how it all works too much. It would definitely be nice to have a GUI, so he can directly edit the levels.
Maybe we can make it work. I look into it some more. Thanks.
If you are just starting out, I'd definitely recommend learning it for Apple-platform specific dev since it has the most learning resource.
I wanted to use Metal and Swift and target macOS, but he wants something his family and friends can play, and not many of them own a Mac. He likes the Web, but I don't want to go back to Web development if I can avoid it, so I'm trying to find a compromise.
2 Likes
If SceneKit is considered top-level, then this would be a big step forward in making SceneKit workable with Swift 6 concurrency. Currently, it appears that SceneKit cannot be used with Swift 6.
While SceneView is decorated with @MainActor @preconcurrency, its delegate, which conforms to the SCNSceneRendererDelegate protocol, as well as the classes SCNScene and SCNnode, to name a few, are not.
Anything done to improve in this case SceneKit’s use in Swift 6 would be very, very welcome.
2 Likes
Anything done to improve in this case SceneKit’s use in Swift
6 would be very, very welcome.
Have you tried this with the latest Xcode 16.2 beta seed (16.2b3 currently). I took a very quick look there and it seems to be fixed, but I’m not a SceneKit expert so I’d love to get your confirmation.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
3 Likes
I don't think this would be considered top-level code. But I'm not familiar with SceneKit at all, so possibly.
But if not, it could be this is a specific case of more general problems that are covered in the migration guide, such as protocol isolation mismatches (which is super common)
(It also sounds like this has possibly been addressed, which is great! And if not please file bugs!)
2 Likes
Quinn, I'll do so. Thank you for your response both on the Apple Dev. forum and here.
1 Like
Mattie, thank you for the link.
Instead of boring everyone by turning this thread into a display of me learning how to use concurrency and actor isolation with SceneKit, I'm going create a new post that will put that on full display elsewhere.
Thank you again.
2 Likes