[zozbot234]

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

[9rx]

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

[three_burgers]

I’m pretty sure when the Ladybird team said “Swift has strictly better OOP support”, they were not referring to ObjC style message passing, so it’s not even relevant.

[9rx]

I'm pretty sure your guessing is silly. I assume you are trying to be here in good faith, so make your case. Since it is not support for message passing, what else makes Swift have "strictly better OOP support"?

[refulgentis]

That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP.

(source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who originally said "because of dynamic dispatch", I understand why you're frustrated but I have 0 idea why you think dynamic dispatch in Swift would matter, much less say it makes Swift much better at OOP than Rust. It's impolite to say "utterly baffling engineering decision" in public, so there's subtext in the conversation. Namely that both claims made 0 sense if you had practical familiarity with either)

[9rx]

> That's the thing man, there isn't anything.

But that's the thing, there is: It supports message passing.

Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (statically-typed, performance-minded).

Realistically, nobody would consider Swift an OOP language either. However, on the spectrum, it is unquestionably closer to being an OOP language. It at least gets an honourable mention in the short list of OOP languages. It is undeniable that Swift has "better" OOP support; not to be confused with good OOP support.

> He did not mean dynamic dispatch

Of course not. Dynamic dispatch is for function calling. OOP doesn't use dynamic dispatch. That's literally why we call it object-oriented rather than function-oriented (or functional, as the kids say). This is also why Objective-C, quite brilliantly, uses [foo bar] syntax (hint: it kind of looks like an ASCII-art envelope for a reason): To make it clear that conceptually you are not calling a function.

> I understand why you're frustrated

I don't. Fill us in.

[refulgentis]

Ok, I've now read through the rest of this thread and I think I understand where you're coming from, but I also think you're making my point for me.

You're using a definition of OOP where only Smalltalk-style message passing counts. By that definition, you're right: Swift is closer, because `@objc` exists. But by that definition, neither Swift nor Rust is an OOP language in any meaningful sense, and the delta between them is mass-of-the-electron tiny. Swift's message passing support is an annotation that is a compatibility shim for a 40-year-old runtime, not a design philosophy.

So when you say Swift has "better OO support"... sure, in the same way that my car has better submarine support than yours because I left the windows cracked and water could theoretically get in. Technically true! Not useful!

The Ladybird team are C++ developers evaluating languages for a browser engine. When C++ developers say "OOP" they mean classes, inheritance hierarchies, virtual methods. The DOM is a giant inheritance tree. That's the context. You can tell them they're using the word wrong, but that doesn't change what they meant, and what they meant is the only thing that matters for understanding whether the claim made sense.

And under their definition-which is also the definition used by mass, essentially every working programmer and every university curriculum for the last 30 years-Swift and Rust are actually pretty close, which was my original point. Swift has `class` with inheritance, Rust has traits and composition. Neither is Smalltalk. The claim that Swift is "strictly better" was weird no matter which definition you pick.

(Also, and I say this respectfully: characterizing C++/Java/Rust as "functional programming" because they encapsulate data with functions is... a take. I get the logic chain you're following but that is not a definition that will help anyone communicate with anyone else, which is presumably the point of definitions.)

[zozbot234]

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

[9rx]

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.

[anonymars]

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!")

[9rx]

Right, the former is what OOP is. The latter, encapsulating data in "objects", is functional programming.

[anonymars]

They are both OOP, just as a "football" can be either spherical or oblong.

Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)

[rvz]

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.

[tomjakubowski]

Until just a couple years ago, Servo had been a pure research project with no goal of ever releasing a full browser (and it was abandoned by Mozilla in 2020).

Igalia had five engineers working full time who turned that science project into v0.0.1 in less than two years.

[josephg]

> Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++.

So long as you don't mind a 2-4x performance & memory usage cost.

[satvikpendem]

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

[cztomsik]

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?

[tvshtr]

The RUST ecosystem barely just started getting into shape on the GUI toolkits frontend... So perhaps save your criticisms for something that wasn't born out of the vacuum.

[bigyabai]

> Fil-C likely can do the job

> Job done.

Seems like you forgot a few stops in your train of thought, Speed Racer.

[johnofthesea]

This comment needs another 'EDIT'.