Hacker News Reader

Comment by refulgentis | Hacker News Reader

Been using Swift since the pre-release announcement that it existed.

O'Leary's Law of Swift Comments on HN, much like Betteridge's Law of Headlines, says the answer to Swift speculation on HN is always no.

If there is any global aim, it is to migrate internal teams still working in ObjC/C++ to Swift.

If this sounds close-minded, it's worth talking with an iOS developer 1:1 and get info on the day-to-day experience of SwiftUI 5 years in, and concurrency/actors 3 years in. They have a lot of fires to fight to keep the house standing.

View on HN

> Apple is not trying to potentially attempt to aim for maybe replacing every other programming language with Swift

Apple's stated goal is to make Swift a viable language up and down the technology stack, which goes way beyond Objective-C. They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. IIRC they even referred to it as a C++ successor language at WWDC this year.

I agree that they're not trying to "replacing every other programming language," but they're investing in it becoming a viable language choice in most environments.

> they even referred to it as a C++ successor language

Nice!

I'd gently warn against parsing that too closely: having been in the community and the weeds starting in 2014(!).

ex. the cross platform Foundation was announced and open sourced in 2016.

I'm sure a lot of things were upgraded or more consistent and its better etc., but it's a painful to remember what was expected + communicated at the time, and how much later it is.

Which I think that makes sense for them to want it to be viable all over the stack. It also directly benefits them also. I am assuming a lot of the motivation for embedded swift is being able to use it in their own stacks. I think even the presentation for WWDC gave examples of it being used in some pieces of hardware like on the AppleTV?

> They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc.

I don’t think Swift has a place in these niches FWIW. Writing low-level Swift code is very verbose and unnatural. Personally I just don’t think it’s practical to have a single language excel across the stack.

I think the goal of Swift on the server, or embedded Swift, is mainly to offer Mac and iOS developers a way to write everything in the same language.

Right now, my Mac app depends on a few simple web services that are written in a different language. It would be neat if those services could be written in Swift, so that I could just use the language I already know instead of relearning how to do decode JSON in Python/Ruby/PHP.

Swift on the server doesn't have to become widely used. As long as there is a simple way to write basic web services, it is useful.

> It would be neat if those services could be written in Swift, so that I could just use the language I already know

Then somebody else would have to now learn Swift even thought they write in different language like: Android Developers (Kotlin/Java), React Native devs (JS/TS ), Windows Devs, Linux Devs etc. As long as Apple don't invest more in official cross-platform tooling Swift is not gonna be mainstream (even though I like Swift). They have to bless other competing platforms.

I was more thinking of smaller teams or individual developers that are Apple only.

If you have a bigger team, then it doesn't matter as much, because you have different people who do the iOS app, people who do the website, people who do the back end etc.

Swift on the server doesn't have to go mainstream to be useful. If you just need some basic web service that syncs highscores or verifies in-app purchases then it would be neat if you could write that in the same language as the app itself.

John McCall (Swift team) gave a talk on Swift replacing C++ earlier this year: https://www.youtube.com/watch?v=lgivCGdmFrw

Selfishly I wish mixed C targets were a priority before C++ but I get why this was more important to them

Huh?

Objective-C was in the kernel.

In NEXTSTEP, yes, but not macOS.

And they regretted the decision not to do it in macOS.

Was it?

Objective-C requires a runtime. I thought the kernel was always C/C++.

There is code in the kernel to enable treating types like `os_log_t` and Clang blocks as Objective-C objects higher up the stack, but the XNU kernel itself is almost entirely C and C++.

Yeah, on macOS.

On NeXTStep / OPENSTEP kernel drivers could be and were written in Objective-C.

https://www.nextcomputers.org/files/manuals/nd/OperatingSyst...

NeXTstep 3.3 supported Objective-C drivers in the kernel. Mac OS X's IOKit changed them to use a (poorly defined/maintained subset of) C++.

Wow that’s an interesting decision. I didn’t know they went that far.

At the time they thought it would be too slow. In retrospect it would've been fine, I think. IOKit is a pretty strange subset of C++, but at least it doesn't use all those templates.

That was my immediate thought, speed issues. MacOS isn’t exactly an I/O speed king as it is. I suspect if it had made it in it may have been removed by now.

Nope, the other way around.

It was in NeXTSTEP. It was taken out because of performance concerns that turned out to be entirely unfounded. Alas, when they figured out that this was the case it was too late.

A similar example is CoreFoundation. It was a C implementation of the OPENSTEP Foundation. To this day, even really smart, capable and knowledgeable engineers believe that CoreFoundation is faster than the pure Objective-C Foundation. It is not. It is significantly slower. Often several times slower.

(It is of course very slightly faster than the "new" Objective-C Foundation that was implemented on top of CoreFoundation).

Another example is Swift. People believe it to be generally faster than Objective-C. Again, this is not the case. Swift code tends to be significantly slower than comparable Objective-C code.

It was based on Embedded C++. Definitely inspired by Objective-C but I believe they wanted to avoid dynamic dispatch in the kernel.

"At the time" being when they turned NeXTSTEP into OS X / macOS (by way of Rhapsody / MacOS X Server).

Yes it was. I actually wrote a kernel driver in Objective-C for an EISA board on OPENSTEP.

The runtime support that's required for Objective-C is extremely minimal. In the end you need objc_msgSend() and some runtime structures so that function works.

The methods themselves are just C functions with slightly funky names.

Apple says a lot of things at WWDC. Not all of them are entirely honest.

Do you have any evidence they’re not targeting it as their main everywhere language?

It’s already been used in their libraries, their OSes, and even firmware on embedded processors.

I think this conversation has a lot of parallels to their public views on SwiftUI. Are they working on it? Yes. Will it maybe end up being what they consolidate around sometime in the future? Maybe. Does that mean you should believe them when they say it’s the biggest thing you should invest in right now? No.

They’re pretty clear on both. UIKit, AppKit, and Objective-C(++) aren’t getting new features except in rare cases.

This is the way forward. And they’re dogfooding it. Even in some of their embedded processors.

https://live.arstechnica.com/apples-wwdc-2014-keynote/images...

Reply on news.ycombinator.com