29 ms·

Closing this as we are no longer pursuing Swift adoption

• polliog 8mo ago
  [flagged]
  • tomcam 8mo ago
    This reads like an AI response to me. Would you elaborate? I can see no reason to believe it would achieve stability based on many of the statements in this issue.
    • polliog 8mo ago
      [flagged]
      • tomovo 8mo ago
        Sunk cost fallacy. It didn't work out, the decision was made, they move on. I like that.
      • dumah 8mo ago
        > so why throw away all that time? https://en.wikipedia.org/wiki/Sunk_cost https://en.wikipedia.org/wiki/Sunk_cost
      • manbash 8mo ago
        Chiming in: indeed, the response is very dry, and raises suspicion. It states the obvious facts and then makes a boring statement, lacking any nuance of the conversation. It is not argumentative in the very least. Time has been spend, yes. But the topic at hand is after so much time the conclusion to abandon this path is justified.
    • _zagj 8mo ago
      Their entire comment history reads like AI to me.
• WCSTombs 8mo ago
  That's interesting, what happened? They don't explain it there. For the record, I don't have a dog in this fight. As long as it runs on Linux, I'm willing to test drive it when it's ready.
  • guywithahat 8mo ago
    It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it. It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
    • jarjoura 8mo ago
      Looking at their integration, with cmake, they definitely took the hardmode approach to adoption.
      • manbash 8mo ago
        The list of issues does not seem to stem from whether they had used this build tool (CMake) nor others (nor official build environments).
• drnick1 8mo ago
  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++.
  • ahartmetz 8mo ago
    Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).
    • fdefitte 8mo ago
      [dead]
      • ahartmetz 8mo ago
        It wasn't the reason why it was removed, but, well we agree, it would have been a problem if used indiscriminately. I didn't do any additional research, but what I read in public was simply "Ladybird is going to use Swift".
    • jabwd 8mo ago
      Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
  • jsheard 8mo ago
    > It's a battle tested choice and pretty much every browser actually in use is written in C++. Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability. IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
• incognitojam 8mo ago
  The commit removing Swift has a little bit more detail: Everywhere: Abandon Swift adoption After making no progress on this for a very long time, let's acknowledge it's not going anywhere and remove it from the codebase. https://github.com/LadybirdBrowser/ladybird/commit/e87f889e31afbb5fa32c910603c7f5e781c97afd https://github.com/LadybirdBrowser/ladybird/commit/e87f889e3...
  • IMcD23 8mo ago
    Some more context here too: https://github.com/LadybirdBrowser/ladybird/issues/933 https://github.com/LadybirdBrowser/ladybird/issues/933
• losvedir 8mo ago
  Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?
  • refulgentis 8mo ago
    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.
    • bbkane 8mo ago
      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).
      • robryan 8mo ago
        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.
      • LeFantome 8mo ago
        > 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.
• upmind 8mo ago
  When does the migration to Rust start? /s
  • weedhopper 7mo ago
    Rust bros already on their way to vibecode a rustbrowser, get their rust stars on rusthub, insult anyone to point out it doesn’t work, and call it a rustday.
  • densh 7mo ago
    It seems like today. https://news.ycombinator.com/item?id=47120899 https://news.ycombinator.com/item?id=47120899
• stephc_int13 8mo ago
  I remember mocking the switch to Swift back then. Swift is a poorly designed language, slow to compile, visibly not on path to be major system language, and they had no expert on the team. I am glad they are cutting their losses.
  • isodev 8mo ago
    Swift never felt truly open source either. That people can propose evolution points doesn’t change the fact that Apple still holds all the keys and pushes whatever priorities they need, even if they’re not a good idea (e.g. Concurrency, Swift Testing etc) Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.
    • stephc_int13 8mo ago
      The fact that Swift is an Apple baby should indeed be considered a red flag. I know there are some Objective-C lovers out there but I think it is an abomination. Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.
      • isodev 8mo ago
        Some refer to the “Tim Cook doctrine” as a reason for Swift’s existence. It’s not meant to be good, just to fulfill the purpose of controlling that part of their products, so they don’t have to rely on someone else’s tooling.
        • deleted 8mo ago
          [deleted]
        • SirFatty 8mo ago
          That sounds like Microsoft's doctrine!
        • stockresearcher 8mo ago
          That doesn’t really make sense though. I thought that they hired Lattner to work on LLVM/clang so they could have a non-gpl compiler and to make whatever extensions they wanted to C/Obj-C. Remember when they added (essentially) closures to C to serve their internal purposes? So they already got what they wanted without inventing a new language. There must be some other reason.
• xannabxlle 8mo ago
  Great, some languages do not need to be hack into a project.
• pbohun 8mo ago
  There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything. Edit: I explained my position better below.
  • refulgentis 8mo ago
    > Everything Chris Lattner has done has been a "successful mess". I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean". Why is it wrong? LLVM is great. Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today. Swift is a fun language to write, hence, why they shoehorned it in, in the first place. Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.
    • carefree-bob 8mo ago
      Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.
      • refulgentis 8mo ago
        He had 0 to do with the TPU. I was hired around Google around the same time, but not nearly as famous :) AFAICouldT it was a "hire first, figure out what to do later", and it ended up being Swift for TensorFlow. That went ~nowhere, and he left within 2 years. That's fine and doesn't reflect on him, in general, that's Google for ya. At least that era of Google.
        • carefree-bob 8mo ago
          Ahh, thanks for the info. Yeah, I heard Google was a bit messy from colleagues who went there.
  • 8mo ago
• meisel 8mo ago
  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.
  • mlinksva 8mo ago
    https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822239138038382684 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."
    • refulgentis 8mo ago
      > 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 downvotes, -3 is a little wild, given current replies don't raise any issues.
      • zozbot234 8mo ago
        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.)
        • rvz 8mo ago
          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 progressing at a slow pace it clearly shows that Ladybird authors do not want something like that to happen to the project.
• noobermin 8mo ago
  I hate to be the one to point this out but really, in 10 years, how many rust ports will face the same fate?
  • tvshtr 8mo ago
    none
  • hu3 8mo ago
    some? It can happen with any language.
• nylonstrung 8mo ago
  Hard to feel excited for this project when it feels so handwavey and when basic technical decisions have never been nailed down. What are other projects trying something similar that deserve attention?
  • tredre3 8mo ago
    > when it feels so handwavey Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...
  • LeFantome 8mo ago
    What projects are trying something similar to Ladybird? Well, mobody really. But Servo is pretty close though they are not writing their own Javascript engine or anything. But you should perhaps give your attention to Servo. They were founded as a project to write a modern browser in Rust. So, no hand-waving there. No hand-waving on the Ladybird team either in my opinion. They have very strong technical leadership. The idea that building a massive application designed to process untrusted user input at scale might need a better language than C++ seems like a pretty solid technical suggestion. Making incedible progress month after month using the language you started with seems pretty good too. And deciding, given the progress buidling and the lack of progress exploring the new language, that perhaps it would be best to formally abandon the idea of a language switch...well, that seems like a pretty solid decision as well. At least, that is my view. Oh, and I was a massive Servo fan before the Ladybird project even began. But, given how much further Ladybird has gotten than Servo has, despite being at it for less time and taking on a larger scope...well, I am giving my attention to Ladybird these days. This comment was written in Ladybird.
• drnick1 8mo ago
  Regardless of the language it is written in, one thing that I hope Ladybird will focus on when the time comes is a user-respecting Javascript implementation. Regardless of what the Web standards say, it is unacceptable that websites can (ab)use JS against the users for things such as monitoring presence/activity, disabling paste, and extracting device information beyond what is strictly necessary for an acceptably formatted website. One approach could be to report standardized (spoofed) values across the user base so that Ladybird users are essentially indistinguishable from each other (beyond the originating IP). This is more or less the approach taken by Tor, and where a project like Ladybird could make a real difference.
  • diath 8mo ago
    There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.
    • drnick1 8mo ago
      If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. That being said, I find that most of the Web works just fine on Tor, so it's certainly possible. Most of the issues seem related to the (known) the exit IP being overused or identified as Tor.
      • diath 8mo ago
        > 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.
        • roughly 8mo ago
• qewartysuc 8mo ago
  [flagged]
• kittbuilds 8mo ago
  [dead]
• WoodenChair 8mo ago
  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/AppKit/Interface https://github.com/LadybirdBrowser/ladybird/tree/master/UI/A...
  • trflynn89 7mo ago
    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 :)
• miffy900 8mo ago
  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.
  • belmont_sup 8mo ago
    Not to mention how heated my laptop gets when I try to compile a new vapor template. On an m1.
  • VerifiedReports 8mo ago
    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." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts. A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.
• KingMob 8mo ago
  [flagged]
• gethly 8mo ago
  [flagged]
  • saagarjha 8mo ago
    Bringing up Rust as an obvious alternative is not toxic.
    • ifwinterco 8mo ago
      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 people off
      • nottorp 7mo ago
        It's probably the same people who were proselitysing blockchain and now are proselytising "AI"?
        • ifwinterco 7mo ago
          I think that's more of a financial grift in a lot of cases (how many pie-eyed AI evangelists turn out to be running some "AI startup" or otherwise have skin in the game). The rust thing is more like actual religious evangelism, like having Jehovah's Witnesses knocking on the door. They have seen the light and you haven't
    • hu3 7mo ago
      it's toxic because of how it sometimes materializes: - predictable - incessant - with belittling/reductionist/arrogant/elitist/combative phrasings - handwaving rust shortcomings and tradeoffs
  • ifwinterco 8mo ago
    It is a genuinely strange social phenomenon. What is it about Rust specifically that attracts these people?
• alper 8mo ago
  Swift is Apple's toy language and they cannot and will not allow it to be anything more than that.