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

181–190 of 332 posts

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

#181

Post by robryan »

bbkane wrote: post #125
refulgentis wrote: post #39

Earlier quoted context omitted.

For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term. It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.

Maybe I misunderstand, but I thought Jakt was part of SerenityOS, not Ladybird. From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).

Yeah, Serenityos was build everything from scratch for fun. Ladybird is build where an alternative implementation is going to add value. No need to get sidetracked reinventing SSL or ffmpeg.

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

#182

Post by LeFantome »

elcritch wrote: post #110
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.

Also I believe one of the core LadyBird devs was an ex Apple employee on WebKit which has been using Swift as well.

The Ladybird founder was one of the original KHTML devs and worked on Safari at Apple.

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

#183

Post by steveklabnik »

stingraycharles wrote: post #91
jll29 wrote: post #87

Earlier quoted context omitted.

Andreas Kling said Rust lacks OO, which he says is useful for GUI coding. He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.

But wasn’t Rust designed specifically for being a language for developing a rendering engine / web browser?

As someone who was on that team for a long time, we took that into consideration, but it was never specifically for that. There was some stuff the Servo team would have liked us to have implemented that we didn’t.

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

#184

Post by LeFantome »

bbkane wrote: post #125
refulgentis wrote: post #39

Earlier quoted context omitted.

For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term. It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.

Maybe I misunderstand, but I thought Jakt was part of SerenityOS, not Ladybird. From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).

> From what I can tell they're pretty laser focused on making a browser

I agree with you. I also agree that this decision is an example of that.

SerenityOS had an "everything from scratch in one giant mono-repo" rule. It was, explicitly a hobby project and one rooted in enjoyment and 'idealism from the get go. It was founded by a man looking for something productive to focus on instead of drugs. It was therapy. Hence the name.

Ladybird, as an independent project, was founded with the goal of being the only truly independent web browser (independent from corporate control generally and Google specifically).

They have been very focussed on that, have not had any sacred cows, and have shed A LOT of the home-grown infrastructure they inherited from being part of SerenityOS. Sometimes that saddens me a little but there is no denying that it has sped them up.

Their progress has been incredible. This comment is being written in Ladybird. I have managed GitHub projects in Ladybird. I have sent Gmail messages in Ladybird. It is not "ready" but it blows my mind how close it is.

I think Ladybid will be a "usable" browser before we enter 2027. That is just plain amazing.

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

#185

Post by raw_anon_1111 »

VerifiedReports wrote: post #180
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…

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

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

This is the same way that C# works and C and C++ why is this a surprise?

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

#186

Post by dismalaf »

pbohun wrote: post #80
dismalaf wrote: post #53

Earlier quoted context omitted.

That's why there's nothing that comes close to LLVM and MLIR, right? If he's such a horrible engineer then we should have lots of LLVM replacements, right?

QBE is a tiny project, but I think illustrates a better intermediate language design. https://c9x.me/compile/

Except performance isn't great and it covers far fewer platforms. It aims for 70% performance but the few benchmarks I've seen show more like 30-50% performance.

It's a cool project and I'd consider it for a toy language but it's far from an LLVM replacement.

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

#187

Post by ckcheng »

mlinksva wrote: post #49
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.

https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822239138038382684 "In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop."

> In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop

Why not D?

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

#188

Post by dismalaf »

levodelellis wrote: post #172
dismalaf wrote: post #53

Earlier quoted context omitted.

That's why there's nothing that comes close to LLVM and MLIR, right? If he's such a horrible engineer then we should have lots of LLVM replacements, right?

Many compilers including my own uses C89

You'll still need a C compiler...

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

#189

Post by anonymars »

9rx wrote: post #175
zozbot234 wrote: post #174

Earlier quoted context omitted.

You just need to define a trait, then you can use dynamic dispatch.

You can, but then you don't get any of what OOP actually offers. Message passing isn't the same thing as dynamic dispatch. OOP is a very different paradigm.

I think you are both unknowingly talking past each other: my understanding is that Smalltalk-style "object-oriented programming" ("everything is a message!") is quite distinct from C++/C#/Java/Rust "object-oriented programming" ("my structs have methods!")

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

#190

Post by LeFantome »

amluto wrote: post #11
drnick1 wrote: post #4

Not too surprising. Swift is too tied to Apple and it's not really clear what the benefit would be relative to a subset of C++ written with contemporary memory safety practices. It's a battle tested choice and pretty much every browser actually in use is written in C++.

> a subset of C++ written with contemporary memory safety practices What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)

> What is this mythical subset of C++

Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST: https://github.com/SerenityOS/serenity/blob/master/Documenta...

You see this reflected all the way back to the main function. Here is the main entry function for the entire browser:

ErrorOr ladybird_main(Main::Arguments arguments).

https://github.com/LadybirdBrowser/ladybird/blob/master/UI/Q...

If Ladybird is successful, I would not be surprised to see its standard library take off with other projects. Again, it is really the SerenityOS standard library but the SerenityOS founder left the project to focus on Ladybird. So, that is where this stuff evolves now.

Post reply on HN