Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

211–220 of 332 posts

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

#211

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

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.

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

#212

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.

What OO features are you thinking of that Rust doesn't have?

Traits give you the ability to model typical GUI OO hierarchies, e.g.:

    trait Widget {
        fn layout(&mut self, constraints: Constraints);
        fn paint(&self, ctx: &mut PaintCtx);
        fn handle_event(&mut self, event: Event);
    }

    struct Button { ... }
    struct Label { ... }

    impl Widget for Button { ... }
    impl Widget for Label { ... }

    let mut widgets: Vec> = Vec::new();
Implementation inheritance can be achieved with good old shared functions that take trait arguments, like this:

    fn paint_if_visible(widget: &W, ctx: &mut PaintCtx)
    where
        W: HasBounds + HasVisibility,
    {
        if widget.is_visible() {
            ctx.paint_rect(widget.bounds());
        }
    }
You can also define default methods at the trait level.

This all ends up being much more precise, clear, and strongly typed than the typical OO inheritance model, while still following a similar overall structure.

You can see real world examples of this kind of thing in the various GUI toolkits for Rust, like Iced, gpui, egui, Dioxus, etc.

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

#214
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 != GC

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

#215

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

Some more context here too:

https://github.com/LadybirdBrowser/ladybird/issues/933

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

#216

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

Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness. You can also look at the source code for the language if any it’s confusing. It’s very readable.

You're re-stating his exact problem while trying to refute him.

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

#217

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

A web browser that explicitly does its own thing regardless of web standards is the last browser in the world I would consider using.

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

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

I’m not even sure he was at Apple when Swift came out. WebKit integration is very recent.

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

#220
post #77
post #43

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.

People are correct I didn't explain my position. LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture…

> LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.

I suggest you ask around to see what the consensus is for which compiler is actually mature. Hint: for all its warts, nobody is writing a seriously optimized language in any of the options you listed besides LLVM.

Post reply on HN