Maybe if swift had something like rustup, people would consider it more when developing for Linux. Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems, while Swift does not even properly support Windows or FreeBSD. It always felt to me that Apple doesn't really care that much about making the language popular outside of the Darwin family.
Swift is not even in the default repositories of most distributions, for instance.
> Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems
As someone working on porting “everything” to a decidedly not weird architecture and a very well known operating system, I chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported.
(Swift works perfectly, but it would be unfair to compare it because it had a strong investment made in it to work…)
I've been running production grade Go apps[1] on aarch64 servers for ~ a year, written on macOS(x86_64), tested on aarch64 before deployment and never faced a single instance where something didn't work because of the architecture.
These are the benchmarks for different ARM platforms[2], where I had submitted one for Jetson Nano a year back and now it seems there's one for Apple Silicon.
I'm not telling, no one would ever find cross platform issues with Go; I'm just curious to know what issues you have faced and whether it's because of Apple's extension of ARM instructions.
The comment wasn’t really an attack on the languages being unportable itself but more that their toolchains are complicated and not very flexible, requiring a decent amount of additional work for new architectures, whereas a lot of the “./configure && make” style projects already work.
Apple’s proprietary extensions don’t really affect porting efforts except in one specific case when writing high-performance JITs for language runtimes. (And there is a fairly simple patch to disable this entirely.)
>chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported.
I'm not sure what's preventing you from giving a direct & specific answer. As it would be useful to know where Rust/Go's toolchains fail for using the code for cross - platform applications.
Rust is blocked on libffi, as are most things using Python (which includes cmake, and that precludes all of LLVM). I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. It's also looking for a file called defs_darwin_arm.h which I don't have. Some warnings that will probably be problematic at the future related to the ABI defining char to be signed.
>I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64.
Go team was already working on getting the toolchain to work on darwin/macOS before Apple announcement[1] because GOOS=darwin meant iOS(gomobile) and there are instructions available now[2] to build it successfully before the official patches. Your test results there would be a valuable contribution.
>Some warnings that will probably be problematic at the future related to the ABI defining char to be signed
You mean unsigned char? that's a common hurdle while porting x86 code to ARM.
> “./configure && make” style projects already work
This is because Apple has a massive investment in LLVM, Xcode is completely based on it. When they unvealed Apple Silicon, the development toolkit and the new Xcode, Clang was already ready for macOS 11 on AArch64, a luxury the Go developers definitely didn't have.
macOS works, ARM has support for years; for many projects all you need to do is pass in the flags requesting support for both and they work pretty much out of the box. Some get a little confused about how such a thing could possibly exist, but I can’t really fault them for that :)
The problem about assumptions is that we can't live with them, but we can't also live without them.
Many so-called "cross platform" projects have had big surprises when it actually came time them to be ported to other platforms.
It's extremely rare for a project which has never been compiled and launched on another platform to actually require 0 porting effort for that platform once actually required to run there.
Yes, for all but the simplest or most abstracted projects sticking steadfastly to standardized features this is fairly hard to do. But the closer you stay stick to that, the more platforms your projects has been through, the more foundational (and less dependency-heavy) your project is, the more likely it will port with few or any changes. My preferred shell and text editor, for example, required zero changes; as did many core tools such as ncurses or make or autoconf. And on top of those it was easy to get things like perl or ninja up with perhaps a small tweak to their configure script or something.
The lowest common denominator leads to working with Stone Age tools. I'm not surprised that not everyone goes that route.
And regarding your porting, Perl, sure, was easy to port. What about CPAN? Want to bet how many Perl libraries will keel over? Same thing for Ruby/gems, Python/pip, etc.
Don't get me wrong, your work is nice, but the people that build on top of your work outnumber you by 2-3-5 orders of magnitude and not all of their porting efforts will be trivial.
This was the extent of the changes necessary to get Meson working on the system-provided Python: https://github.com/mesonbuild/meson/commit/85686e21d78a587de.... Surely that is not a "Stone Age tool"? The people doing the work right now to get foundational stuff working are doing that precisely to aid the porting efforts of the many, many developers that will depend on those things working in a few months when they have to port their own codebases.
In that case the comment makes no sense - the details of AArch64-based Macs have been made public just a few weeks ago. It takes a while to do port and test for a new platform, even if iOS was already supported.
Yup, that’s what I’m doing. Just offering my comments on how difficult some projects are to port: some require no new code and some will require quite a bit, and some will be blocked on their dependencies being in the latter camp :)
No, I learned of it the same time you did, although I had a fairly good idea about when this was coming for a few years ;) And while I have a bit of additional information now, it's nothing that would really be useful for porting.
That is just a tiny step, when the majority of available libraries only have the Apple eco-system in mind.
Swift is a very nice language, but one is better served with it if their main market is Apple platforms.
Just like .NET Core, regardless of how much commitment Microsoft is putting into it, remains a subset of the .NET community at large, the so called dark matter developers.
Google's interest on Swift isn't that much reflected outside when Tensorflow 2020 conference did not spend 1 second on Swift, not even to write a tiny status update blog post.
Yet they had enough C++, Android, Python and JavaScript to talk about.
C++, Python, Julia, R own Machine Learning.
I don't miss Swift on Windows, the JVM and .NET stacks offer plenty of choice, including better GPGPU support across multiple OSes.
>The nature of Open Source means that any interested party contributes to the project the features it is interested in
Yes, but the reality of Open Source is that unless money are paid, it often goes nowhere for big projects (that need lots of work to port/create libs/etc).
The "but" is that a million developers somewhat interested in the language but for the lack of platform support wouldn't sum to a relevant interest. I think that's a shame, but still truth.
"The nature of Open Source means that any interested party contributes to the project the features it is interested in"
And my comment essentially means:
Yeah, BUT this "nature of Open Source" is just a mere potentiality.
The fact that FOSS allows "any interested party can contribute" means nothing if there's no interested party with deep pockets (or time/skill to contribute).
I wasn't trying to say that FOSS _allows_ for anyone to contribute but that it _relies_ on that.
I was trying to make the point that Swift will be good for the things that the parties who are interested in it need it for. And these interested parties are the deep pockets you are talking about.
Why is the relative size of the apple-oriented community relevant?
I'm not saying it's the current status quo, but if the server-side Swift community reaches a critical mass where it's easy to get support, and there are plenty of libraries available, it doesn't matter one bit if the iPhone developer community is still 10x larger.
This would be like saying coconut is unsuitable for use in pina colladas because it's much more prevalent as an ingredient in curry.
Because a language is not an island and the competition is tough.
Anyone betting their money on Server side Swift better have a solid story to sell to upper management, why they did not went with Go, Java, .NET, C++20, Rust, OCaml, .....
Right now the only solid story is for Apple shops to share their client code with the server.
Not just to share code, but developers and other parts of the language ecosystem as well.
From my perspective Swift is in a trailing group with Go and Rust, chasing C# and Java for new server/service development. Swift is behind, IMO, in supporting server-side development, but ahead in language adoption. That's why the SSWG makes sense.
(Probably C/C++ is used for a lot of new server development too, but I feel that's mostly unassailable, at least directly -- I think that's mostly on-going development in systems with heavy ties to existing C/C++ projects where they've already very seriously considered alternatives and rejected them.)
ROR made Ruby into a mainstream language from a single success story and a usable tool. Swift already has a much bigger developer base, there's no reason it couldn't succeed in other markets as well given the right catalyst.
I don't follow your argument. Ruby is a single-use-case language so therefore Swift must also be? I can point to many languages which have achieved adoption in more than one domain as counter-examples.
That is just libobjc, which is basically useless except if you actually plan to reimplement everything Foundation does. ObjC IS de-facto Foundation, without NSString, NSArray, etc no library will ever work. GNUStep is more likely to be considered a decent multi-platform implementation of an Objective-C runtime, or WinObjC from Microsoft.
Apple has a bigger developer base but they are captive users. I'm not saying swift isn't good, but nobody actually chooses to use it. They use because it is the language for making iDevice apps.
The problem is that if people are only using a language because they have to, then they are not as incentivised to create the open source projects that swift needs. Ruby had a large number of very enthusiastic users, that's what made the difference.
I think you're describing a chicken-and-egg problem, and you're overstating the extent to which a gap exists in terms of library support.
Swift has a very capable standard library, a high-quality, officially supported networking library, and fantastic C and Python interop which can fill a lot of the gaps to the extent they exist.
Even in its current state, I can imagine Swift being productive in something like server-less development, where it would offer a nice strongly typed alternative to scripting languages which currently dominate the space.
Swift has a lot of intrinsic features which would make it nice to use for server-side development, and I'm sure it would find plenty of users if there were a strong success story to point to.
Given the number of users, I'm not convinced the absolute number of Ruby users in 2009 was larger than the number of "swift enthusiasts" today.
Have you used the Python interop? I went looking to try it a few months ago and it was MIA as far as I could tell. It seems to be exclusively baked into Tensorflow's fork of the compiler. I would love a pointer if I missed something!
The captive bit isn't entirely true, as the language has had Objective-C for competition.
I suspect that instead of an enthusiasm gap the greater negative impact on FOSS libraries comes from the Apple-platform dev community being strongly oriented around making consumer-focused programs for money.
Objective-C is neither easy nor something most people liked. I did actually like it because I always thought it was really cool, but most people I talked with hate it with a passion. For the average Java developer, choosing between Swift and Objective-C is like choosing between cake and a tomato for dessert. Some people might pick Objective-C, but it's definitely not the majority.
Funny, when Mac OS X was released, it had two programming languages in equal footing Java and Objective-C, because Apple wasn't sure if developers would be keen in using Objective-C, like on NeXTSTEP.
They created their own Java implementation, had Sun on stage at WWDC, additional runtime features for integration with OS X frameworks, ported WebObjects to Java.
Then the crowd assembled around Objective-C tooling and the rest is history.
Swift, Rust nor Go provide support for exotic targets. If you want code to work in actually "weird architectures and little known operating systems", then your only option is C (or weird dialects of "C" in some cases).
At least that was how things were around >10 years ago, not sure about the current state of things. Anyone can chime in? Do embedded vendors etc. provide proper forks of newish, modern compilers?
Even excluding extremely exotic targets, the list of platforms supported by Rust and Go is vastly larger than Swift. For instance, there's no official support on FreeBSD, and FreeBSD 1. uses LLVM for everything 2. has a userland really similar to Darwin, so there are very few excuses to not allocate even a small amount of man power to port it.
If you add third-party ports and implementations, the list of platforms supported by Go and Rust increases exponentially; see for instance Tiny Go and the ongoing port of Rust to the Xtensa-based ESP32.
> Anyone can chime in?
I work in embedded and as far as my experience goes nowadays unless you go on extremely limited environments, the embedded chips I mostly see or develop for are either ARM (v7, like stuff from Nordic or the STM), or ESP32 (Xtensa). Every once in a while I have to work on some older projects which were based on Atmel or PIC, or very very very rarely MIPS.
It's certainly not like it was before; nowadays you can buy chips like the ESP32-WROVER which have relatively lots of RAM and storage for an absurdly cheap price. They run pretty well even if you opt for using C++17 and complex libraries.
I like Swift a lot but Apple seems to be focusing on cross-platform within their ecosystem only, the fact that it runs elsewhere almost feels like a side effect. If your goal is sharing some cross platform code then I feel like you're better served by Rust / Go / Kotlin Native / C++ as these languages are making / have made and effort in that space.
Swift is not even in the default repositories of most distributions, for instance.