There are some sources for that, like engaget for example.
There are also a few shortcuts on the desktop if you install it with the gui... But yeah, it's ultimately a Debian deviate, so anyone with any experience will be able to use it however he wants
> Raspbian comes preloaded with Python, the official programming language of the Raspberry Pi and IDLE 3, a Python Integrated Development Environment.
It's mostly just the best supported language out of the box on the "default" distro. It comes with the Python REPL Thonny, Python libraries to control the GPIO, a version of Minecraft scriptable with Python, and a bunch of example games with Python source.
It also ships with Mathematica, Ruby (via SonicPi), and Scratch.
Originally, the Pi was going to run Python directly, with a minimal OS underneath, much as early home computers ran embedded BASIC. But as development continued, it became clear that being a full Linux system was desirable. Since it was originally meant as a cheap computer for students, it was felt that Python would be a good choice for a beginner's language. So even though the Pi supports many programming languages, the emphasis on Python remains.
The nominal purpose of the Raspberry Pi is education. The Raspberry Pi Foundation (RPF) sells Pi's commercially and they fold the profits back into their education program. They present Python as a good language to use on the Pi (for their educational uses), just as they recommend using Raspbian (their Debian variant) as the OS, but neither of those are required. They certainly don't discourage people from running other languages on them.
Having said that, a Raspberry Pi running Python under Raspbian is a great little machine for special purpose tasks. I have half a dozen at home, with 15k lines of Python running in my living room (weather station, home automation, etc.).
I don't want to be negative about this article, but reading over it left me with a little bit of disappointment.
I was hoping for an in depth dive into how Swift performed on a RPi compared to other languages (say, C relative to Swift on x86, then the same for ARM), and a little on how well Swift interacts with the Pi's hardware. But it was just a quick guide on setting up a Pi, installing Swift, and making a quick 'Hello, World' program. The only lines of interest came at the very end:
> Now that Swift is installed, there’s so much more that you can do. To control hardware — like LEDs, motors, and relays — you can use the help of a library for hardware projects on Linux/ARM boards called SwiftyGPIO. Have fun experimenting with Swift on the Raspberry Pi!
That said, SwiftyGPIO looks like a fun little library that I think I'm going to look into more and play around with.
"In-depth" wasn't mentioned anywhere in the title though. The author also defines hardware vs software... Clearly an introduction, and props to him for trying.
This is a decent guide, but if you are interested in Swift on ARM in general, the crux is uraimo's Swift on ARM project [0], which is a huge resource for the community.
> ...but if you are interested in Swift on ARM in general...
I kind of was expecting this to be bare-metal Swift running on ARM with a Raspberry Pi, when I read both the OP's title and your comment. But I was disappointed to see that this was running on Linux. From the README.md...
> Scripts to clone, configure, patch and build Swift 5.0.2 on Linux ARM devices.
Hopefully in the future, Swift would support bare-metal environments just like how Rust and Zig does.
Bare metal is almost entirely unnecessary in 2019, because you can configure Linux to only occupy one core for all of its processes and threads. The other cores you can assign to your own apps and they will never be schedule off of that core—zero context switching overhead.
And you can still SSH into your "bare metal" box, run gdb, etc. Best of both worlds.
> Bare metal is almost entirely unnecessary in 2019, because you can configure Linux to only occupy one core for all of its processes and threads.
Configuring the Linux kernel just to meet the requirements for bare-metal applications might work for some use-cases but not for security and safety-critical applications.
For instance, the IoT industry still suffers from typical security issues in the drivers and firmware due to these Linux/Busybox vulnerabilities in the system. There are alternatives that use safer languages or formal verification that are more secure than configuring Linux for IoT or bare metal development, like TockOS [0] (using Rust) or seL4 microkernel (a formally verified microkernel).
So, is bare metal almost entirely unnecessary in 2019? Security wise, I'd much rather use safer languages like Rust for bare metal in 2019, than to use Linux/Busybox for this use-case.
Swift is built on top of LLVM, the same way C,C++ and Rust are. Also note that the language was created by the original creator of LLVM.
So you can use any backend LLVM does.. theres a little runtime friction in porting a small Swift runtime to the target (but you would only need to worry about that, if its not a popular LLVM backend).
But given Apple is a first class consumer of Swift, arm is definetely a strategic backend for Swift, given it needs to run on iOS.
(its a little alpha i guess, but you can even compile your Swift code to run on WASM nowadays)
I don't think it's that simple. AVR was merged into LLVM, but I think you'd be hard pressed to get either rust or swift running on it right now.
> So you can use any backend LLVM does.. theres a little runtime friction in porting a small Swift runtime to the target
More than a little friction, I would think.
I actually 'trust' the support if the language declares that they are going to support it. For example, Rust has said they will support the wasm target as first class.
It's a lot easier to support Linux than Windows since it's so similar to macOS, and they're already supporting ARM, so it really just comes down to OS features they need to support. Windows is just so different from everything else.
That being said, I'm sure it already works through WSL (Windows Subsystem for Linux), so if Windows is your only platform, you can still probably play with it.
Yup, but unfortunately, it's the most relatable way to explain it. Yes, package managers were around long before any of these "app stores", but most people are unaware of that fact. It's the main feature that attracted me to Linux when I started using it, and the main pain point when trying to use something else.
26 comments
[ 1.2 ms ] story [ 21.3 ms ] threadHuh? In what way exactly?
There are also a few shortcuts on the desktop if you install it with the gui... But yeah, it's ultimately a Debian deviate, so anyone with any experience will be able to use it however he wants
> Raspbian comes preloaded with Python, the official programming language of the Raspberry Pi and IDLE 3, a Python Integrated Development Environment.
It also ships with Mathematica, Ruby (via SonicPi), and Scratch.
Source: I think Eben told me himself a while back.
Having said that, a Raspberry Pi running Python under Raspbian is a great little machine for special purpose tasks. I have half a dozen at home, with 15k lines of Python running in my living room (weather station, home automation, etc.).
I was hoping for an in depth dive into how Swift performed on a RPi compared to other languages (say, C relative to Swift on x86, then the same for ARM), and a little on how well Swift interacts with the Pi's hardware. But it was just a quick guide on setting up a Pi, installing Swift, and making a quick 'Hello, World' program. The only lines of interest came at the very end:
> Now that Swift is installed, there’s so much more that you can do. To control hardware — like LEDs, motors, and relays — you can use the help of a library for hardware projects on Linux/ARM boards called SwiftyGPIO. Have fun experimenting with Swift on the Raspberry Pi!
That said, SwiftyGPIO looks like a fun little library that I think I'm going to look into more and play around with.
[0] - https://github.com/uraimo/buildSwiftOnARM
I kind of was expecting this to be bare-metal Swift running on ARM with a Raspberry Pi, when I read both the OP's title and your comment. But I was disappointed to see that this was running on Linux. From the README.md...
> Scripts to clone, configure, patch and build Swift 5.0.2 on Linux ARM devices.
Hopefully in the future, Swift would support bare-metal environments just like how Rust and Zig does.
And you can still SSH into your "bare metal" box, run gdb, etc. Best of both worlds.
Configuring the Linux kernel just to meet the requirements for bare-metal applications might work for some use-cases but not for security and safety-critical applications.
For instance, the IoT industry still suffers from typical security issues in the drivers and firmware due to these Linux/Busybox vulnerabilities in the system. There are alternatives that use safer languages or formal verification that are more secure than configuring Linux for IoT or bare metal development, like TockOS [0] (using Rust) or seL4 microkernel (a formally verified microkernel).
So, is bare metal almost entirely unnecessary in 2019? Security wise, I'd much rather use safer languages like Rust for bare metal in 2019, than to use Linux/Busybox for this use-case.
[0] - https://www.tockos.org/
So you can use any backend LLVM does.. theres a little runtime friction in porting a small Swift runtime to the target (but you would only need to worry about that, if its not a popular LLVM backend).
But given Apple is a first class consumer of Swift, arm is definetely a strategic backend for Swift, given it needs to run on iOS.
(its a little alpha i guess, but you can even compile your Swift code to run on WASM nowadays)
> So you can use any backend LLVM does.. theres a little runtime friction in porting a small Swift runtime to the target
More than a little friction, I would think.
I actually 'trust' the support if the language declares that they are going to support it. For example, Rust has said they will support the wasm target as first class.
You can also use apt.
That being said, I'm sure it already works through WSL (Windows Subsystem for Linux), so if Windows is your only platform, you can still probably play with it.
i died a little inside