Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple is open sourcing Swift Build

swift.org

Post reply on HN
Print view View original

21–30 of 300 posts

Re: Apple is open sourcing Swift Build

#21

Post by sgt »

timsneath wrote: post #3
sgt wrote: post #2

Is Swift actually serious about embedded?

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4 More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw... (Disclosure: I work at Apple.)

Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?

Re: Apple is open sourcing Swift Build

#22

Post by o11c »

jitl wrote: post #14
o11c wrote: post #7

Earlier quoted context omitted.

And until packages are actually shipped for all mainstream distros, the stigma is completely accurate. No, neither "just install a tarball" nor "just install this docker image" count.

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger. Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

I disagree vehemently. For any active language, distro packages should be at most 3 years old.

And for any language that's stable enough to be worth using, "3 years old" is good enough.

Re: Apple is open sourcing Swift Build

#23

Post by isodev »

picafrost wrote: post #9

Swift is a nice language. I'm glad to see it being released from the clutches of Apple. I can only imagine how large of a task this is. I hope some day to be able to use it. The last time I tried a cross-platform project with it I switched languages due to `URLSession.shared.data` (a network request) being unable to compile on Linux.

Is it really being released? Although some parts of the language and build chains are technically open source (as in, you can see the code), the project is still completely controlled by Apple at the top.

Re: Apple is open sourcing Swift Build

#25

Post by cvwright »

isodev wrote: post #23
picafrost wrote: post #9

Swift is a nice language. I'm glad to see it being released from the clutches of Apple. I can only imagine how large of a task this is. I hope some day to be able to use it. The last time I tried a cross-platform project with it I switched languages due to `URLSession.shared.data` (a network request) being unable to compile on Linux.

Is it really being released? Although some parts of the language and build chains are technically open source (as in, you can see the code), the project is still completely controlled by Apple at the top.

They have also been working on a completely open source version of the Foundation library for use on Linux and other platforms. (IIRC the URLSession type is part of Foundation, as are many core building blocks that you need for making a real application.)

Re: Apple is open sourcing Swift Build

#27

Post by cvwright »

jitl wrote: post #14
o11c wrote: post #7

Earlier quoted context omitted.

And until packages are actually shipped for all mainstream distros, the stigma is completely accurate. No, neither "just install a tarball" nor "just install this docker image" count.

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger. Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

Or containers. The Swift project is pretty good about keeping their Docker images up to date.

Re: Apple is open sourcing Swift Build

#28

Post by pjmlp »

sgt wrote: post #21
timsneath wrote: post #3

Earlier quoted context omitted.

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4 More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw... (Disclosure: I work at Apple.)

Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?

Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.

Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.

Re: Apple is open sourcing Swift Build

#29

Post by aseipp »

sgt wrote: post #21
timsneath wrote: post #3

Earlier quoted context omitted.

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4 More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw... (Disclosure: I work at Apple.)

Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?

For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.

Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.

Re: Apple is open sourcing Swift Build

#30

Post by jitl »

o11c wrote: post #22
jitl wrote: post #14

Earlier quoted context omitted.

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger. Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

I disagree vehemently. For any active language, distro packages should be at most 3 years old. And for any language that's stable enough to be worth using, "3 years old" is good enough.

Python, Java, C#, JavaScript, Go, Ruby all improve so substantially in 3 years time, I can’t square the advantages of using a distro package for any of them versus using at least the latest LTS from upstream. What is so great about the distro package versus upstream, that it is worth being 2-3 years behind?

Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.

Python is by some measures the most popular programming language, its first release was in 1991, and over the last 3 years performance improved significantly, see https://lost.co.nz/articles/sixteen-years-of-python-performa...

I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.

Post reply on HN