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 firstname.lastname@example.org 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
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.
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)
On the subject of tooling, there are 2 things I would really like:
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.
This is desired, but not currently available in sourcekit-lsp in the toolchain. There is a PR Implement document formatting using swift-format by Trzyipolkostkicukru · Pull Request #220 · apple/sourcekit-lsp · GitHub in review, and some things to sort out first.
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.
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.
Swift 6 will bring the ideas of
Golang into it .
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.
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))
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:
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
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.
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.
As a flippant reply to a heartfelt paean, @tkremenek any chance of hiring this guy?
@esummers: I know, that in theory you can already replace Node.js, not only with wasm, but also at the server-side. In my opinion, the people just don't write any libraries or stuff with Swift, as long as it isn't available in a simple way like Node.js. My hope is, that a compiler for Windows, all other Linux distributions then Ubutunu will really bring the chance, that there will be more Swift on the servers.
I agree that broad platform support is very important to build a community interested in Swift on the server. Linux support is probably good enough since it supports Docker, but certainly supporting more distributions would be nice. Tracking this, it appears that Windows support is getting there. It will probably be useable in about a year. Swift 6 will add some important features for server-side swift. I think in 3 years the language will be ready to be a real contender in this space and not just us Swift fans that might use it even if it is more difficult.
The big milestone that was just hit was that SPM wasn't up to the challenge until recently. That affected the community for both server and in general. With Xcode integration and support for artifacts coming soon, I think things are finally to the point where it will take off. Stable ABI means that the operating system will start embracing Swift more. I'm starting to see many more Swift packages since Xcode 11. NIO was also a big step toward creating a server side ecosystem.
TensorFlow has been both embracing Swift and working on adding C++ interop to Swift. This could also be interesting. If Swift ends up being good at both a web server and machine learning and systems programming (including existing C++ libraries) this could make it good for niches that no other web server platform can do easily. Particularly when it comes to micro-services. In fact I think it will be micro-services that will see the most interest initially.
EDIT: In fact it wouldn't be surprising to me if Google uses Swift for micro-services. I believe they currently use mostly C++ and Golang. If Swift can interop with C++ well enough, it may make sense for them to use it in places that Golang isn't a good fit. There obviously is precedent for this at Google with Tensorflow adopting Swift with it's decent performance and the fact the language was built with interop in mind for the Objective-C transition which is now being expanded to Python and C++. ARC also makes interop easier with other languages.