If it were easy to use Swift on Arduino, I would replace a ton of python code today.
16 Likes
I echo this sentiment. I think that Swift support for things like Arduino is incredibly important, especially in formal education. Upon starting an engineering at the start of high school, I was initially introduced to Arduino. Arduino is an easy gateway for students to dive in to engineering and build something for themselves at a relatively low cost. In my grade 9 engineering course, I recall actively avoiding programming in Arduino because of the clunky C/C++ (I think that is what it is) I had to write it in, which was especially hard considering I knew nothing about programming at the time.
I think that adding Swift support for Arduino would allows students to try their hand at programming at an earlier stage in their education. Swift is also, IMHO, a much easier programming language to learn for a beginner than something like C/C++ (which I found to be really intimidating at the time). Moreover, being able to be a part of a more standard engineering curriculum (
) like Arduino would really benefit Swift as a language as it would introduce it to people outside of the world of primarily iOS, macOS, etc. and would also serve to be an easy gateway for students interested in and being introduced to programming for the first time.
15 Likes
This is music to my ears. I’ve spent two years writing swift for Arduino with a couple of awesome volunteers. I’m just curious, when you guys talk about swift on Arduino being easy. Do you know about our product? It’s swift compiled to native Arduino code, bare metal, with a full class library for all the usual things (I2C, uart, ADC etc). No tricks. It’s the real thing! I don’t think I’ve been very good at promoting it. 
10 Likes
Hey that sounds really cool! Any public links for what you're doing?
Absolutely! Here's my website which goes over the basics, where you can buy the IDE or download a free trial: https://www.swiftforarduino.com. Here is the community github site where you can see lots of examples of how to write swift code for the Arduino UNO and anyone can (and should!) contribute open source swift code: GitHub - swiftforarduino/community: Here are some sample swift files to be used in the Swift for Arduino IDE.. Finally here's my YouTube channel where I've done some fun demo videos: https://www.youtube.com/channel/UCOZOilfSMWip62a-mw-9LmQ. That is probably a great place to take a quick look and see what it's like. Social media wise, we've got a Twitter account, Instagram and Facebook, or email us on swiftforarduino@gmail.com and we will invite you to our Slack channel so you can hop on and chat to us all about it. We would love to tell you all about it (and anyone else reading this is invited to all the above too!) Carl
23 Likes
What about Swift Evolution? Do you sometimes look over there? It is a nice overview of what is being worked on and what's being evaluated. It is much more high level and user friendly to read than pull requests on Github.
2 Likes
Swift Evolution is all about user facing language features rather than about advances in the language underpinnings. Swift evolution is great, but it doesn’t show things like the advances in error diagnostics etc. See @Douglas_Gregor’s latest post on advances in the function builders space to see what kind of stuff I’m on about.
In the spirit of enabling wider adoption via more C interop, can we please support importing incomplete structs as named and typed opaque pointer?
typedef struct Foo Foo;
Foo* CreateFoo();
void DeleteFoo(Foo* inFoo);
let f: Foo = CreateFoo()
DeleteFoo(f)
7 Likes
On the subject of tooling, there are 2 things I would really like:
- Ship
swift-formatwith the official toolchain.
There was a huge discussion about this last time, but @tkremenek's last post indicates that it's still considered important for the project to offer a formatting tool. swift-format is already kind-of part of the toolchain, because it drives SourceKit-LSP's formatting functionality. Unfortunately, the executable tool itself is not available (at least on Apple's toolchains).
Even if we have different formatting preferences, it's really nice to have a tool that is available everywhere. It really helps when collaborating on open-source projects, where every project has its own style, and everybody uses different IDEs with different levels of support for Swift.
- Documentation lookup/generation.
I can't tell you how useful this would be. I don't feel that we do enough with our documentation comments, and the level of information that can be obtained by integrating this with the compiler is really great. @owenv posted a demo here, and I would love to see it also become part of the toolchain eventually. If it had a markdown renderer, this would be a really nice way to generate documentation pages for your packages. Again, not everybody uses IDEs with great Swift support built-in.
12 Likes
This is desired, but not currently available in sourcekit-lsp in the toolchain. There is a PR https://github.com/apple/sourcekit-lsp/pull/220 in review, and some things to sort out first.
2 Likes
In the meantime, SwiftFormat is fully functional as a package and can be easily used like any packaged tool as described here:
I agree with this but it would be more than amazing if the official Twitter account of the language posted regular bits about technical things. Many of us follow the compiler developers on Twitter and get a lot of joy when you post interesting technical bits.
Maybe having more presence in the social sphere would be good for the language. I always liked how the Rust account does this.
21 Likes
I agree with @Alejandro_Martinez, using the @SwiftLang Twitter account to provide tips, tricks, and tell people about community projects and all the new functionality available in Swift, would be really neat and relatively low-friction. And I swear I'm not just saying this because I work for Twitter, but it is a place where a lot of the Swift community congregates in public.
THESE COMMENTS DO NOT REPRESENT THE VIEWPOINTS OF MY EMPLOYER. RETWEETS ARE DEFINITELY ENDORSEMENTS THOUGH.
9 Likes
Dream for Swift 6 will bring the ideas of Channel and Select in Golang into it 
.
3 Likes
Oh wow, Swift and low-level programming, that sounds fantastic... not, that I personally could use that as a hobby developer, but I love the dream, that there will be someday a SwiftOS 
And maybe the ownership way will bring some nice performance improvements in some cases.
Bringing Swift to other platforms (especially Windows) is one of the main missing feature I'm waiting for since the first version of Swift. Why? I don't use Windows, but I think a lot of other developers do. No one of them will ever learn Swift or will ever produce any products or at least libraries, when Swift is only available for macOS and Linux. Can't wait for the day to surf on the main swift website and download the compiler (not just for Windows, maybe also for a Raspberry PI). I hope, Swift will then maybe replace Node.js (I don't like Javascript ;))
2 Likes
Short answer is you can't. It would be nice to see this for some optimizations, but until ownership is really figured out I think we would normally fall back to C to write the bits of code that need to be high performance. When Swift is ready to be a systems programming language (I think that is a goal), this will probably be prioritized. Right now you need to create the type in C and use unsafe operations on it. However, I can normally get away with just dynamically allocating an array, storing it, and reusing the array many times for decent performance or c interop:
var curlErrorBuffer = [CChar](repeating: 0, count: Int(CURL_ERROR_SIZE))
Technically it can already replace node.js and JavaScript in the browser GitHub - swiftwasm/swift: WebAssembly support for the Swift programming language
You will certainly be swimming against the current, but it is important to have these projects so as the ecosystem grows Swift eventually starts becoming the easy platform to develop for outside of iOS.
You should already be able to use those concepts already. There are libraries available and reactive programming is similar. The difference is that golang makes it much more lightweight using tiny stacks for each operation that automatically grow if they overflow. That allows the technique to scale much further to use in busy servers, etc. The problem is there are a lot of compromises in the language and compiler that need to be made to add resizable stacks. Rust tried to do that and later gave up and moved to a C# style async. The advantage with the C# method is it works with larger fixed size stacks since concurrency allows operations to share stacks and threads. It is also compatible with the C calling convention. If Swift built this like Golang, it wouldn't be able to call C or Objective-C code without jumping to a normal thread and doing a ton of other work. In Golang they have cgo for this, but it is rarely used because it would slow everything down so much that they would be better off not using lightweight stacks. The C# async method schedules operations using M:N threading which is optimized for lots of operations that share a small number of stacks (1 for each thread). The Golang method uses M:N threading as well but gives each operation their own tiny stack. I'm pretty sure Swift would get something closer to C# async methods but taking it a step further with an actor model built on top of it to safely share state while using M:N threading for scheduling with one stack per thread. To explain in one sentance. This is still a very cool concurrency system. The Golang style of concurrency works well for them and meshes well with their philosophy of not using any operating system features (except for syscalls) for super easy deployment, but it has also made the language only good at building micro services and nothing else.
The manifesto goes in to some details:
1 Like
Tuples have been close to it for years. All that we really need for now is
- making it a single type collection that can be iterated
- syntax that avoids typing
Int32 times.
Other more advanced (low-level / ownership / etc.) features would be welcome of course, but I'd be thankful if we did not delay this thing for another 3 years.
2 Likes
As an early adopter I've enjoyed the ride from Swift's first release to its current robust state, and have grown with it. One important architectural area I think swift has not managed to provide for is the uniflow architectures that are central to modern program design. I ended up, having iterated too many times, choosing RxFeedback as core library for coding reactive state machines. This contained enough boiler plate that Sourcery templates were coded to take simple state machine specs into an extensible model. And still, at the heart of every Presenter, Service, Use Case etc. was a switchyard.
Recently my day job moved to using Kotlin and Javascript. The scales have fallen from my eyes, and I now see that coroutines are an elegant, and expressive solution to coding async state machines, generators, transformers and consumers.
I urge the community to investigate structured concurrency in Kotlin, and the simpler, but remarkable effective async function generators in javascript. Bringing state-of-the-art concurrency in time for Swift 6 would allow uniflow architectures, event sequence grammars and async state machines to have a natural expression in the language, and I believe this would benefit both the specification, performance and stability of all applications using the Swift language.
9 Likes