Considering the existence of a hypothetical “SwiftLED”.
I detest C++ with the waste heat of a thousand WS28xx pixel array running full-white. But Arduinos are great, FastLED is awesome and Apple’s new Swift programming language is pretty nice.
So, just spitballing, what conditions would be necessary for a hypothetical SwiftLED to exist?
• Swift itself would have to be open sourced. That’s apparently on track for the end of the year.
• There would have to be LLVM back ends for Arduino processors. https://github.com/avr-llvm/llvm exists and appears to be maintained and I don’t think ARM support is a problem for llvm 
(Although maybe on the low end? How different is an M0-M4 to arm64 in ways that matter in this context?)
• There would need to be Swift/Arduino libraries. I suppose what you do is (re-)write all the pinMode/analogRead/interrupt related stuff in Swift (math is already there from the Swift stdlib.) How hard could it be?
• Then there’s a toolchain/dev environment. I suppose make would (have to) do short-term, or maybe you could pervert Xcode to your cause.
• Finally, FastLED. You can call C and asm from Swift easily (google “Objective-C bridging header”), but not C++. I know FastLED relies on C++'s templating features pretty heavily, so I’m guessing that unless Swift eventually supports calling C++ directly it’s going to be a re-write (possibly borrowing FastLED’s asm implementations) rather than a simple wrapper library on top of the C++. In truth a Swift LED manipulation API would probably look different to a C++ one, so you’d want to re-implement the top layer anyhow. Is the separation of the high- and low-level parts of FastLED such that this is feasible?
Am I missing anything/totally nuts?
-
arm64 is a completely different architecture and instruction set from arm m0-m4. Also, 8-bit AVR - I have a hard time believing swift and 8-bit avr will ever get along, at least in any way that would be even marginally efficient.
-
In order to re-write all the pinMode/analogRead/interrupt stuff, swift would need to allow for direct memory access, as that’s how you talk to hardware registers. As for how hard to rewrite the existing low level support/libraries, there’s only a couple hundred thousands lines of code there 
-
toolchain is probably the least of your problems
-
FastLED is pretty close to all low level all the time, so there’s not much in the way of separation between high and low level.
So, in short, yes, you are totally nuts, and missing quite a bit as far as what FastLED is doing on the low level. It’s unclear to me that swift allows for the types of direct memory access that’s important for a large portion of how FastLED does its talking to LED hardware.
FastLED makes pretty heavy use of C++ templates to collapse down a number of thins at compile time to keep i/o access as fast as possible, I don’t think swift really has any such mechanism that would be useful to me here.
Finally, the swift/objective-c runtimes have some pretty intense overheads both on flash and memory that make me skeptical of how well they’d run on devices where you are measuring available memory in KB, not MB.
What Dan said.
What you wants is a swift wrapper around FastLED’s C++. You code in your language of choice, but the work underneath get done using the tools that are needed to make it work.
My crystal ball says “swift ain’t gonna happen on ATmega”.
Maybe what you want is swift code on a raspberry pi, piping data to a microcontroller that’s driving the LEDs.
It’s interesting that Swift is generating a lot of noise in the micro space. The Photon community at http://particle.io put this on the product development wish list, and there’s a moderate debate about whether it’s a good idea or not. I think Mark and Daniel are right about FastLED though. C++ isn’t really a problem in this case, and it supports all the platforms that this group cares about very cleanly. Swift doesn’t solve a specific problem (say memory or resource management) for this type of environment. I have to assume Swift is being reference just because it’s the hip new thing.
My question is why Swift for micro programming? What advantage does it have? There seems to be a lot of interest, but not a lot of reasons given for that interest?
I won’t be surprised to see someone port Python or Perl to at least the m-core chips. Not sure how that might work, but people are clever when presented with tough problems. Maybe it works and can be used? I also think Swift will be ported eventually, for the same reasons. Pry to later generations of micros with MB’s of memory running at 600 Mhz cause things get bigger and faster all the time.
The problem that Swift solves (for me—and I don’t expect everyone to share this view) is that I think C++ is awful and I’m not particularly productive in it.
It is intended to be a systems programming language though—if you believe Objective-C is one, Swift is one too. Moreso than Objective-C even, as it’s runtime doesn’t do Obj-C’s dynamic dispatch tricks.
A Swift wrapper around FastLED’s C++ would satisfy me, but can’t exist yet as it’s not currently possible to call C++ from Swift. Objective-C (and therefore C and inline asm) yes, but C++ no—and I can’t see that feature ever being prioritized if it’s not necessary for Apple to do what they need to do.
And I didn’t realise that the Arduino libs are a couple of thousand lines of code, yipe!
Right - but FastLED lives below the “systems programming” language layer, even - because I have to talk to arbitrary memory addresses (also, because there are places where I am cycle counting, but I do that in asm code that’s pretty heavily affected by C++ templates). I don’t believe swift has a way for me to directly access arbitrary memory locations. A bit of wrapper to get at FastLED from swift might be interesting, at least as a thought experiment. However, I’m not even going to think about touching it until it’s got some level of stability in both toolchain and backend. Even then, a wrapper is the most I’d be inclined to do for Swift, I’m certainly not going to re-write the library and make it dependent on swift
There are a bunch of tweaks I’m planning on making to FastLED over the next few months to take more advantage of things offered up in C++11/14. Not sure whether or not they’ll help you, though.
Oh hell, I wasn’t suggesting this as a you-project Dan, this was something I was thinking I’d like to tinker with if it was at all in the realm of the possible.
And of course as you say, a wrapper would be the preferred way to do it if it were possible; but I think it might be the C++ templating that kills me.