Re: [Thought experiment] Bringing swift into an experimental branch?

On Tue, Jun 17, 2025 at 12:05 AM Jordan Hubbard
<jordan.hubbard@gmail.com> wrote:
> I know that the topic of “bringing additional languages” into OSes is controversial and, frankly, we made a bad call with macOS when we brought the kitchen sink in (everything from Tcl to Python) and regretted it afterwards, so this is just a thought experiment, as noted in the subject.
>
> All that said, I think a more modern language than C++ being readily available has a useful way of shifting development and generating some excitement, and a modern language that is also strongly supported by your existing clang / LLVM compiler toolchain represents an increment along the same evolutionary path.  It’s also a language that needs a number of components to be tightly in sync (libdispatch, clang, llvm, various compilation tools and libraries, etc) before any 3rd party developer can even compile it for FreeBSD, so saying “it’s a ports collection problem” may ultimately work, but not without considerable pain, as evidenced by the fact that ports/lang/swift does not exist.
>
> Why swift, if anything?
>
> Python changes too often in incompatible ways and Rust is still going through its Rust foundation stewardship changes (that didn’t form until 2021) plus if you bring Rust in, you’ll be immediately enmeshed in the “should we just rewrite the kernel in rust?!” topics that seem to plague Linux.   Swift, on the other hand, is an application and service development language and sits nicely on top of what FreeBSD already has - nobody’s going to push to rewrite the kernel or base utilities in Swift, but you do get access to a very active community and, of course, the backing of a major player like Apple and the open source swift ecosystem.
>
> I’m told that Swift also just announced support for FreeBSD, so if there is ever a time, this might be it?
> - Jordan

There is nothing wrong with resurrecting lang/swift in the ports [1],
this may bring Swift lovers to FreeBSD make it base for their servers
/ platforms / devices (maybe even porting macOS/iOS applications???),
just as it is with any other programming language already here (i.e.
Python), people will have choice whether use it or not with zero
impact on the kernel / base :-)

The problem was with "dump old bad C and rewrite everything in Swift
just to get modern" because we clearly do not want to rewrite kernel /
base in Swift :D :D

[1] https://www.freshports.org/lang/swift/

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info