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

241–250 of 332 posts

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

#241

Post by ChrisMarshallNY »

alper wrote: post #229
ChrisMarshallNY wrote: post #211

Earlier quoted context omitted.

I think Swift was developed to keep a number of constituencies happy. You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do). A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me. Been using it since 2014 (the day it was announced). I enjoy it.

No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.

I suspect that it was developed, in order to make native development more accessible. SwiftUI is also doing that.

They want native, partly as a “moat,” but also as a driver for hardware and services sales. They don’t want folks shrugging and saying “It doesn’t matter what you buy; they’re all the same.”

I hear exactly that, with regard to many hybrid apps.

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

#242

Post by cztomsik »

satvikpendem wrote: post #121
rvz wrote: post #69

Earlier quoted context omitted.

I think we have seen enough since the best example of a Rust browser that is Servo, has taken them 14 years to reach v0.0.1. So the approach of having a new language that requires a full rewrite (even with an LLM) is still a bad approach. Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++. Job done. EDIT: The authors of Ladybird have already dismissed using Rust, and with Servo p…

Servo was essentially integrated into Firefox. It was not a browser in itself until it was put into a foundation on its own.

Only few isolated parts were integrated into Firefox, everything else was simply thrown away and abandoned, and IMO it was for a good reason.

I've been programming in Rust for 5 years and I could barely understand the code in their repo. Not because it was somehow advanced but because it didn't make any sense. It felt like that with every decision they could make, they always chose the hardest way.

On the other hand, I have never done any C++ (besides few tutorials) in my life and yet I found both Serenity/Ladybird and also WebKit to be very readable and understandable.

BTW: If anyone wants to reply that Rust is different then yes, of course it is - but that's the point, if there is a language that maps nicely to your problem domain, it's also very fast, and well-understood then why the hell you'd use a language that is well-known to NOT map to OOP?

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

#243

Post by nottorp »

hippo22 wrote: post #86
bunderbunder wrote: post #52

Earlier quoted context omitted.

For what it’s worth, ObjC is not Apple’s brainchild. It just came along for the ride when they chose NEXTSTEP as the basis for Mac OS X. I haven’t used it in a couple decades, but I do remember it fondly. I also suspect I’d hate it nowadays. Its roots are in a language that seemed revolutionary in the 80s and 90s - Smalltalk - and the melding of it with C also seemed revolutionary at the time. But the very same featu…

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…

> 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.

The constantly moving target fetish coming from the javascript camp may be misguided, you know...

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

#244

Post by nottorp »

ifwinterco wrote: post #223
saagarjha wrote: post #219

Earlier quoted context omitted.

Bringing up Rust as an obvious alternative is not toxic.

There's already a stereotype that Rust people will just carpet bomb any discussion with aggressively promoting Rust, people expect it to happen at this point and it just annoys people. So I think it probably meets the threshold of "toxic", but more importantly - it's not effective. Everyone and their dog has already heard of Rust, aggressive proselytising is not going to help drive Rust adoption, it's just pissing pe…

It's probably the same people who were proselitysing blockchain and now are proselytising "AI"?

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

#245

Post by ozgrakkurt »

meisel wrote: post #46

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

I remember watching the project lead say something like “the developers just don’t enjoy rust”

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

#246

Post by jason_oster »

zadikian wrote: post #159
josephg wrote: post #111

Earlier quoted context omitted.

Oh? They tried rust? Lots of people seem really committed to OOP. Rust is definitely a bad fit if you can't imagine writing code without classes and objects. I don't think this makes rust is a bad language for the problem. Its just, perhaps, makes rust a bad language for some programmers.

It doesn't seem uncommon for someone to generally like Rust but still want to use something OO for UI. I'm in that boat. Never liked OOP much, but it makes sense sometimes.

Every "OO for UI" approach I've seen breaks most of the rules of object-oriented design.

GTK, Qt, DOM, WinUI 3, Swing, Jetpack Compose, and GWT (to name a few) all provide getters and setters or public properties for GUI state, violating the encapsulation principle [1]. The TextBox/EditBox/Entry control is the perfect example.

The impedance mismatch is that a GUI control is not an object [2]. And yet, all of the object-orient GUI examples listed implement their controls as objects. The objects are not being used for the strengths of OO, it's just an implementation detail for a procedural API. The reason these GUIs don't provide an API like shown in [1] is because it's an impractical design.

"How are you supposed to design an OO TextEdit GUI control if it can't provide a getter/setter for the text that it owns?" Exactly. You're not supposed to. OOP is not the right model for GUIs.

Ironically, SwiftUI doesn't have this problem because it uses the Elm Architecture [3] like React and iced.

[1]: https://www.infoworld.com/article/2163972/building-user-inte...

[2]: From [1], "All the rules in the rule-of-thumb list above essentially say the same thing — that the inner state of an object must be hidden. In fact, the last rule in the list (“All objects must provide their own UI”) really just follows from the others. If access to the inner state of an object is impossible, then the UI, which by necessity must access the state information, must be created by the object whose state is being displayed."

[3]: https://guide.elm-lang.org/architecture/

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

#247

Post by i_am_a_peasant »

miffy900 wrote: post #161

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 S…

same. i thought it would have been as quick to pick up as rust. nowhere near. i spent weeks trying to go through every feature of the language at least once. time in which i could’ve read several rust books and already start hacking up some interesting projects. so much in swift is pointless syntax sugar. why do i need 50 ways to do exactly the same thing, it’s just nonsense. then i have to look up the language reference whenever i read a new codebase

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

#248

Post by trflynn89 »

WoodenChair wrote: post #154

Their Mac UI is a thin layer of AppKit. Even there they're currently using Objective-C++ it looks like, not Swift: https://github.com/LadybirdBrowser/ladybird/tree/master/UI/A...

Hi, I'm the one who originally wrote Ladybird's AppKit UI. Just FYI, it was written long before Ladybird split from SerenityOS, and even longer before Swift was on the table. I only chose Objective-C++ because it was the language I was familiar with at the time :)

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

#249

Post by generalpf »

meisel wrote: post #46

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

Swift doesn't use a garbage collector.

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

#250

Post by amomchilov »

sumuyuda wrote: post #221
VerifiedReports wrote: post #180

Earlier quoted context omitted.

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement. But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes." But then: "Have one source of truth."…

> when every data structure is COPIED on every function call Swift structs use copy on write, so they aren’t actually copied on every function call.

They don’t, by default. That’s something you have to implement yourself.

It’s a common misconception that comes from the standard library data structures, which almost all do implement CoW

Post reply on HN