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

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

161–170 of 332 posts

Re: Closing this as we are no longer pursuing Swift adoption

#161

Post by miffy900 »

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#?

And this was me trying to use Swift for a data access layer + backend web API. There's barely any guidance or existing knowledge on using Swift for backend APIs, let alone a web browser of all projects.

There's no precedent or existing implementation you can look at for reference; known best practices in Swift are geared almost entirely towards using it with Apple platform APIs, so tons of knowledge about using the language itself simply cannot be applied outside the domain of building client-running apps for Apple hardware.

To use swift outside its usual domain is to become a pioneer, and try something truly untested. It was always a longshot.

Re: Closing this as we are no longer pursuing Swift adoption

#162

Post by bunderbunder »

LeFantome wrote: post #153
hippo22 wrote: post #86

Earlier quoted context omitted.

Many of the built-in types in Objective C all have names beginning with “NS” like “NSString”. The NS stands for NeXTSTEP. I always found it insane that so many years later, every iPhone on Earth was running software written in a language released in the 80s. It’s definitely a weird language, but really quite pleasant once you get used to it, especially compared to other languages from the same time period. It’s truly…

>It’s truly remarkable they made something with such staying power What has had the staying power is the API because that API is for an operating system that has had that staying power. As you hint, the macOS of today is simply the evolution of NeXTSTEP (released in 1989). And iOS is just a light version of it. But 1989 is not all that remarkable. The Linux API (POSIX) was introduced in 1988 but started in 1984 and b…

In some ways ObjC’s and the NEXTSTEP API’s staying power is more impressive because they survived the failure of their relatively small patron organization. POSIX and C++ were developed at and supported by tech titans - the 1970s and 1980s equivalents of FAANG. Meanwhile back at the turn of the century we had all witnessed the demise of NeXT and many of us were anticipating the demise of Apple, and there was no particularly strong reason to believe that a union of the two would fare any better, let alone grow to become one of the A’s in FAANG.

I actually suspect that ObjC and the NeXT APIs played a big part in that success. I know they’ve fallen out of favor now, and for reasons I have to assume are good. But back in the early 2000s, the difference in how quickly I could develop a good GUI for OS X compared to what I was used to on Windows and GNOME was life changing. It attracted a bunch of developers to the platform, not just me, which spurred an accumulation of applications with noticeably better UX that, in turn, helped fuel Apple’s consumer sentiment revival.

Re: Closing this as we are no longer pursuing Swift adoption

#163

Post by zrobotics »

8cvor6j844qw_d6 wrote: post #140
WD-42 wrote: post #118

Earlier quoted context omitted.

I talked to an apple engineer at a bar years ago and he said they aren’t allowed to work on _anything_ including side projects without getting approval first. Seemed like a total wtf moment to me.

This is interesting, I knew a workplace where open source contributions are fine as long as its not on company PC and network.

Every programming job I've ever had, I've been required at certain points to make open source contributions. Granted, that was always "we have an issue with this OSS library/software we use, your task this sprint is to get that fixed".

I won't say never, but it would take an exceedingly large comp plan for me to sign paperwork forbidding me from working on hobby projects. That's pretty orwellian. I'm not allowed to work on hobby projects on company time, but that seems fair, since I also can't spend work hours doing non-programming hobbies either.

Re: Closing this as we are no longer pursuing Swift adoption

#164

Post by bunderbunder »

satvikpendem wrote: post #116
hippo22 wrote: post #86

Earlier quoted context omitted.

Many of the built-in types in Objective C all have names beginning with “NS” like “NSString”. The NS stands for NeXTSTEP. I always found it insane that so many years later, every iPhone on Earth was running software written in a language released in the 80s. It’s definitely a weird language, but really quite pleasant once you get used to it, especially compared to other languages from the same time period. It’s truly…

Well, there are many more devices running on a language written in the 70s.

Assuming you mean C (C++ is an 80s child), that’s trivially true because devices with an ObjC SDK are a strict subset of devices that are running on C.

Re: Closing this as we are no longer pursuing Swift adoption

#165

Post by satvikpendem »

bunderbunder wrote: post #164
satvikpendem wrote: post #116

Earlier quoted context omitted.

Well, there are many more devices running on a language written in the 70s.

Assuming you mean C (C++ is an 80s child), that’s trivially true because devices with an ObjC SDK are a strict subset of devices that are running on C.

Yes, that is why I don't find it "insane" like the grandparent does, like yeah, devices run old languages because those languages work well for their intended purpose.

Re: Closing this as we are no longer pursuing Swift adoption

#166

Post by iLemming »

8cvor6j844qw_d6 wrote: post #140
WD-42 wrote: post #118

Earlier quoted context omitted.

I talked to an apple engineer at a bar years ago and he said they aren’t allowed to work on _anything_ including side projects without getting approval first. Seemed like a total wtf moment to me.

This is interesting, I knew a workplace where open source contributions are fine as long as its not on company PC and network.

No, as far as I know, at Apple, this is strict - you cannot contribute to OSS, period. Not from your own equipment nor your friend's, not even during a vacation. It may cost you your job. Of course, it's not universal for every team, but on teams I know a few people - that's what I heard. Some companies just don't give a single fuck of what you want or need, or where your ideals lie.

I suspect it's not just Apple, I have "lost" so many good GitHub friends - incredible artisans and contributors, they've gotten well-payed jobs and then suddenly... not a single green dot on the wall since. That's sad. I hope they're getting paid more than enough.

Re: Closing this as we are no longer pursuing Swift adoption

#167

Post by PaulDavisThe1st »

bunderbunder wrote: post #156
PaulDavisThe1st wrote: post #82

Earlier quoted context omitted.

I've never written whole applications in ObjC but have had to dabble with it as part of Ardour (ardour.org) implementation details for macOS. I think it's a great language! As long as you can tolerate dynamic dispatch, you really do get the best of C/C++ combined with its run-time manipulable object type system. I have no reason to use it for more code than I have to, but I never grimace if I know I'm going to have t…

It is, and that’s part of what I loved about it. But it’s also the kind of trick that can quickly become a source of chaos on a project with many contributors and a lot of contributor churn, like we tend to get nowadays. Because - and this was the real point of Dijkstra’s famous paper; GOTO was just the most salient concrete example at the time - control flow mechanisms tend to be inscrutable in proportion to their p…

I don't really want to defend method swizzling (it's grotesque from some entirely reasonable perspectives). However, it does work on external/3rd party code (e.g. audio plugins) even when you don't have control over their source code. I'm not sure you can pull that off with "better" approaches ...

Re: Closing this as we are no longer pursuing Swift adoption

#168

Post by LeFantome »

stephc_int13 wrote: post #75
WaldoDude wrote: post #64

Earlier quoted context omitted.

Swift has it's problems, and I certainly wouldn't use it for anything outside of development for Apple platforms, but saying they had no experts on the team is a stretch. Most Swift leads were highly regarded members of the C++ world, even if you discount Chris Lattner.

I meant no Swift experts in the Ladybird team. Their expertise is C++, you may think the transition is easy, and it can be pretty painless at first, but true language expertise means knowing how to work around its flaws, and adapting your patterns to its strenghts. Cool for a hobby, but switching language in the middle of an herculean work is suicide.

> switching language in the middle of an herculean work is suicide

My read is that that this is the main thing that happened here.

The Ladybird team is quite pragmatic. Or, at least their founder is. I think they understood the scale of buidling a browser. They understood that it was a massive undertaking. They also understood the security challenge of building an application so big that processes untrusted input as its main job. So, they thought that perhaps they needed a better language than C++ for these reasons. They evaluated a few options and came away thinking that Swift was the best, so they announced that they expected to move towards Swift in the future.

But the other side of being pragamatic is that, as time passed, they also realized how hard it would be to chagne horses. And they are quite productivity driven. They produce a YouTube video every month detailing their progress including charts and numbers.

Making no progress on the "real" job of building a browser to make progress on the somewhat artificial job of moving to a new programming language just never made sense I guess.

And the final part of being pragmatic is that, after months of not really making any progress on the switch, the founder posted this patch essentially admitting the reality and suggesting they just formalize the lack of progress and move on.

The lack of progress on Swift that is. Their progress on making a browser has been absolutely mind-blowing. This comment is being written in Ladybird.

Re: Closing this as we are no longer pursuing Swift adoption

#169

Post by ulyssys »

roughly wrote: post #149
diath wrote: post #131

Earlier quoted context omitted.

> If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. Personally I wouldn't mind either but my point is that they probably want to cater to the average person, and not just security conscious tech savvy people, and if that's the case, then you really can't exclude FB/IG/YT and others from working properly in your browser.

> they probably want to cater to the average person, and not just security conscious tech savvy people Why? The average person is well served by large existing players, whereas security conscious tech people are extremely underserved and often actually willing to pay.

Specific numbers aside, one possible reason is they want to increase adoption to gain user volume, in order to have an effect on the larger ecosystem.

Once you have non-trivial network effects, you could continue to influence the ecosystem (see: MSIE, Firefox in its early days, and Google Chrome). There are probably multiple paths to this. This is one.

Re: Closing this as we are no longer pursuing Swift adoption

#170

Post by 9rx »

zozbot234 wrote: post #61
refulgentis wrote: post #55

Earlier quoted context omitted.

> Swift is strictly better in OO support and C++ interop Fascinating. They've shown the idea it is better on C++ interop is wrong. I don't know enough to say Rust has same OO support as Swift, but I'm pretty sure it does. (my guess as a former Swift dev: "protocol oriented programming" was a buzzy thing that would have sounded novel, but amounted to "use traits" in rust parlance) EDIT: Happy to hear a reply re: why d…

Rust has straightforward support for every part of OOP other than implementation inheritance, and even implementation inheritance can be rephrased elegantly as the generic typestate pattern. (The two are effectively one and the same; if anything, generic typestate is likely more general.)

> Rust has straightforward support for every part of OOP other than implementation inheritance

Except the only thing that makes OOP OOP: Message passing.

Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try.

Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby are really the only OOP languages in existence (some esoteric language nobody has ever heard of notwithstanding).

Post reply on HN